Can GnuPG Deliver? 286
jso888 writes "After Network Associates decided to halt further development of PGP, I'm sure that many users like myself who use non-CLI platforms most of the time, wondered "what next?" (PGP Freeware is not an option, since it's tied into the Network Associates product). Salon today has a nice article on GnuPG, the Open PGP/GNU alternative. The article highlights one of the problems with Open Source software today: its "by the geek, for the geek" nature, which by and large places barriers to mass adoption of OSS, especially important capabilities like personal encryption. One of the nice things about NAI PGP was its ease of use and commercial polish. It was easy to install and use, and integrated nicely with Windows software like Eudora and ICQ. GnuPG, admittedly, isn't quite there yet, the article concludes. That's too bad; given the privacy-hostile world we live in, the last thing we need is another barrier to widespread cryptography adoption."
What's holding back security (Score:4, Insightful)
Encryption by itself is too difficult and esoteric for normal users. If you want to see it spread, make it easy to use and easy to understand.
Re:What's holding back security (Score:4, Insightful)
It's dam easy to set up and free to get a key (and a nice button on Outlook).
No, the reason people don't use it is there is little point, not even my BANK recomends sending emails with personal data encripted!
(alas not all email clients or mail servers support S/MIME yet)
Outlook, and outlook alone (Score:5, Informative)
I don't remember the details, but it's been discussed on the OpenSSL lists recently. Outlook has totally dropped the ball on multi-part S/MIME messages. Because they're the 800-pound special-ed gorilla their incompetence means that few people are interested in using correctly working multi-part S/MIME tools that can't interoperate with the majority of people, while the coders understand how much damage is being done by the broken Outlook implementation and refuse to be involved in any effort that gives it credence.
I'm rarely see black hats hiding in shadows, but this is one of those exceptions. It's too easy to imagine some spook taking advantage of the fact that MS can kill the market for secure communications, while ensuring that the tools are still available for their users.
Re:What's holding back security (Score:2)
In short none of these options makes it easy to get a key. And even assuming you want one, they'll ask for your life history and passport/social security/credit card numbers before they'll hand one over. That's too bad for anyone under 18 or in a repressive country.
And in a years time your certificate expires. And your certificate is not signed in any meaningful sense (Verisign et al disavow any knowledge of your actions) so the signature means nothing at all.
Aside from that, SMIME is just too damned slow compared to PGP/GPG which use mostly symmetric encryption and are therefore much faster than asymmetric SMIME.
So no, Outlook Express doesn't make it damned easy and SMIME just stinks anyway.
Easy to me means having something akin to PGP's Key Generation Wizard built into the mail software. When I sign and send a message without a key it should launch the wizard ask me a few simple questions, ask for a password, generate the key, ask me if I want to publish it and that is it. Mail is signed and sent. If I receive messages containing an X-pgp-ID header, my email software should be able to look up and retrieve their public key from the server.
Now that would be easy.
Re:What's holding back security (Score:2)
Re:What's holding back security (Score:2)
Encryption by itself is too difficult and esoteric for normal users. If you want to see it spread, make it easy to use and easy to understand.
That's why I'm developing Herbivore [demon.co.uk], a zero-effort mail encryption system.
Re:What's holding back security (Score:4, Insightful)
Hash: SHA1
I don't mean to sound elitist (ok, maybe I do) but....
The problem is that PKI is not easy. Key exchange is relatively easy, sure - just have the application upload and download from a keyserver. But what about key signing, and the web of trust? How do you make that part easy? To maintain security, users must understand exactly how the process works. Signing a key is a multi-step process and each step must be done with regard to absolute security. I can't imagine how you could wrap the web of trust into a slick GUI without completely negating the point.
And what about key revocation? Do you really think that when an office worker moves from one department to another, and gets a new computer, that he will think to copy his private key to a floppy and delete it from his original computer? Or, failing that, will he issue a revocation certificate when he realises that someone else now has access to the private key? For that matter, will he encrypt the private key so that he has to type a passphrase every time he accesses it?
These are not things you can easily abstract away. The user must understand the whole process, or he will never get it right. In turn, not getting it right would dilute the web of trust. And remember, the users we're talking about are the same ones who fail to understand why you don't just launch untrusted applications out of your e-mail, and why your password really needs to be at least five characters long. Does anyone think the average corporate user will have any grasp at all on how and why to use PKI in the way it was designed (i.e. securely)?
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oxyBXk7sIRPQRh0RAm/RAKC1wm0wzc/WH+vyRrC5d
WjQJECmQ2hIL5axm0jo0lOU=
=CuR1
-----END PGP SIGNATURE-----
Re:What's holding back security (Score:2)
Yes, with a digital signature, you get proof of identity, and along with it, non-repudiation, date stamping, window of validity, revocation lists and a TON of 'useful' stuff that you don't get with an ink signature.
But if you CAN'T make it as EASY as an ink signature, you're not going to get much adoption.
Re:What's holding back security (Score:3, Insightful)
Hash: SHA1
One point: usually when you buy these expensive items, there are independent ways used to verify your identity. For buying cars and real estate (at least in Kansas), you have to have the title notarized, which of course implies that the notary, who is licensed by the state, is supposed to check your ID.
This sort of thing doesn't really scale to e-commerce easily. On the Internet, it is much more difficult to verify someone's identity than it is in the Real World. Thus, digital signatures are trying to solve a much harder problem, in the common case, than ink signatures are. Unfortunately the hard problems don't go away by throwing technology and GUI interfaces at them. A command-line switch for "trust this signature even though we have no way of knowing if the owner is who he says he is" is just as bad as a GUI check-box saying the same thing.
One might say that certificate authorities and KDCs are the digital equivalent of a notary public. The web of trust is the digital equivalent of a bank asking you for ID when you open an account, and keeping your signature on file for later comparison.
Nonsense - most of these features can only be implemented if there is a trusted third party, aka certificate authority (CA). How is this different from a notary public? In the Real World you can get every single signature notarized, providing the same non-repudiation, date stamping, and so forth. People don't usually do this because it represents a lot of time and money.
And then there's the issue of whether you trust the notary, or the CA. The notary is licensed by the State, the CA isn't really licensed by anyone but gets credibility from the number of people who recognise it (rather like the value of paper currency). In both cases, how do you know for sure that it can be trusted? You don't, you can only assume.
As I've said, if you want the real benefits of PKI and digital signatures, you either need an extensive web of trust (hard to achieve) or a trusted third party (CA). This isn't something you can just hand-wave away with better interfaces. I really don't see how the ease-of-use problem can be solved. It's easy to get people to use SSL with https: web sites. It's hard to ensure that their e-commerce transactions are actually secure against MITM attacks and various sorts of spoofing. Without identity verification (in both directions (sure, the web site has a CA-issued certificate, but do you?), the great benefits of PKI and digital signatures are largely a myth.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8o0tbXk7sIRPQRh0RAuBYAJ9DVmv2jxgv2jC6EeihX
B/PfLLMNGphv+UzaKcUZmaE=
=8uVU
-----END PGP SIGNATURE-----
secrets and PGP (Score:3, Interesting)
Re:secrets and PGP (Score:2)
Re:secrets and PGP (Score:4, Informative)
So, yes, in a way I check them all the time.
Re:secrets and PGP (Score:2)
Every time I get an email with a sig - and my email is always signed
Re:secrets and PGP (Score:3, Interesting)
And I don't understand the concept of PGP Sigs either.. How does that prove anything? What's to prevent me from smacking a PGP Sig on my email? Does anybody verify those?
I use KMail; it has very nice GnuPG integration, the only missing feature is for *it* to go through and encrypt my attachments instead of making me do it. At any rate, any email with a PGP sig is automatically checked and since I have the colour bar enabled signed messages with keys I trust (and that pass) are in a green border. Good sigs with keys I don't know/trust are in a yellow border and bad signs are in a red border. Very eye-catching and very nice.
I generally sign messages (not encrypt) if I want to give the person on the other end a way of verifiying that what I sent didn't get altered. I encrypt when I don't want anyone else reading it. It's perhaps a subtle difference, but I use it quite often.
KMAIL improvements (Score:2)
> the only missing feature is for *it* to go through
> and encrypt my attachments instead of making me do it.
I use kmail, too and this lack of total encryption has bothered me, too. kmail ATM only signs the text of the mail itself.
BUT, thanks to the German sponsored project AEGYPTEN, the next version of kmail will have openpgp specified mime multipart encryption and also full S/MIME support. [And also LDAP support and so on, mutt will get S/MIME support out of this.]
By the next version I mean KDE3.1, which will be there end of summer.
You can already check out the AEGYPTEN branch of kdenetwork:
http://www.gnupg.org/aegypten/develo
http://www.gnupg.org/aegypten/devel
ftp://ftp.gnupg.org/gcrypt/alpha/a
Re:secrets and PGP (Score:2, Funny)
So what is this "PGP sig"? Is it a witty quip, or is it just some spam message you can't remove unless you upgrade from the free version?
I'd rather use a product that lets me write my own sig.
Re:secrets and PGP (Score:2)
A while later, A meets C, both sign their keys.
Now B can trust C, because B trusts A.
When a PGP sign is not trusted, pgp or gpg will always tell you about it.
Signing at the very least means subsequent mails can't be forged. If you trust somebody who sends you a signed message, you can trust all mail signed by his signature is his.
A one-time message with an untrusted key means exactly nothing.
Personally I check all signatures automatically because I use mutt and gpg. gpg automatically fetches keys from a keyserver.
Re:secrets and PGP (Score:4, Insightful)
One day someone receives an email from his parents, asking for urgent money transfer because of some disaster; the bank account is provided. The guy goes to the bank and transfers almost all he has.
A week later this person might be very upset that he did not demand a digital signature on the email because his parents never sent him any requests for money, are in perfect health and have no idea whose bank account it was...
Re:secrets and PGP (Score:5, Insightful)
The other point is that it's better to use encryption because you can. It's like always using ssh, instead of "just when you don't want someone to snoop your connection". Use encryption all the time, because protecting your privacy is always a good thing.
-il cylic
Re:secrets and PGP (Score:2)
Re:secrets and PGP (Score:2)
Re:secrets and PGP (Score:2)
Hash: SHA1
There is - it's called a keyserver, and there are lots of them (which synchronise their keys periodically). You can upload your key to one, and set your software to automatically download a key when needed (to verify a signature).
The keyserver itself it not secure - the security lies in a so-called "web of trust". In essence, you can sign someone else's key once you have verified its veracity by face-to-face meeting or phone call (assuming you trust your ability to recognise his/her voice on the phone). If enough people sign each other's keys, you can trace a path of key signatures (no pun intended) from you to an arbitrary key you downloaded, and you know there is some assurance that the key is genuine. Of course, this relies on everyone in the chain being very careful only to sign keys they know for sure they can trust. (That is not something you can build into a software product - you can only document how the process works, and the user has to take responsibility to get it right.)
The advantage of the web of trust is that it is free and decentralised. The alternative is to use certificate authorities (CAs) who are centralised and well-known. This is how SSL web sites usually work. The process is similar, except that the web is very shallow in that everybody implicitly trusts those few CAs. And CAs generally don't sign your keys for free - it's a service they sell. As such, it is quite practical for e-commerce, but in my opinion not at all practical for individuals.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oyFcXk7sIRPQRh0RAmvRAJkBb304Qw9HbF/obB+ny
lZI4CNAroR8RxG3ZmGkFf30=
=32AC
-----END PGP SIGNATURE-----
Re:secrets and PGP (Score:2, Informative)
Do you use secure websites to order online, or do you use sites with no encryption?
Do you email your bank account information to family members using PGP, or in plain text?
Re:secrets and PGP (Score:2)
But the SSL/TLS uses the same ciphers and the same technologies, only in a different "wrapper".
Re:secrets and PGP (Score:2)
Hash: SHA1
Some of the same ciphers and some of the same technologies. Notable differences:
- key exchange: in PGP you exchange keys out-of-band,
usually by means of a keyserver, or mundane means such as
having your public key on a web page or Slashdot user
profile. With SSL you use a Diffie-Hellman exchange,
in-band (i.e. you negotiate a temporary pair of keys for
each transaction).
- identity verification: in PGP it is the web of trust,
tied to the public keys themselves. You sign people's keys
which you have personally verified as genuine, and they in
turn sign other keys, until there is an entire network of
"trust relationships". With SSL each party can be certified
by a Certificate Authority, which is a similar process
except that the web of trust only goes one level deep:
everyone implicitly trusts the CA. This is much more like
the Kerberos model. Also, CAs cost money so individuals
don't usually use them. Thus, in most SSL transactions, the
web surfer can verify the web site, but not vice versa.
Also, the CA model relies on a separate certificate which is
not part of the key used for actual data transfer,
but is passed as in-band data.
-----BEGIN PGP SIGNATURE-----Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8oyStXk7sIRPQRh0RAj7xAJ9mjZCbQmFz+aj5PWY1Z
v2d4FQ9bqUhJRXFCcR8NbNA=
=8qbj
-----END PGP SIGNATURE-----
Re:secrets and PGP (Score:2)
Re:secrets and PGP (Score:2)
All of us. I do not consider the information on my accounst, short term and long term debt to be a matter for the public domain
My bank uses PGP (Nationwide in the UK, one of the 5 largest banks here). For all customer related communications. All email is signed (no exemption) and encrypted if needed. You should expect no less from your bank. If it does not I suggest you change it. To a bank with a clue. I know it may be problematic in some countries suffering from acute terrorism paranoia. Problematic, but not impossible.
That is just one example. We can extend the list with personal health (yours or of family members abroad), internal business matters where you work, to be continued ad naseum.
Re:secrets and PGP (Score:2)
Privacy is worth protecting.
Re:secrets and PGP (Score:2, Informative)
Check out Trillian [trillian.cc], which claims to do this. Caveat: it's not open source, and I haven't looked to hard at its security features, but it does list encryption over ICQ and AIM as features. I use it more because it's a unified client that does ICQ, AIM, Yahoo!, MSN, and IRC all in one.
IM clients w/ encryption (Score:2)
Epicware's Fire [epicware.com] for Mac OS X has well integrated PGP support (via the GPGME Framework for Mac OS X [slashdot.org]). It supports the usuall slew of services (AIM, ICQ, etc). It's GPLed and works quite nicely (though, not quite as nice a client as Adium [www.adiumx], which unfortunately doesn't support encrypted communications yet...)
Re:secrets and PGP (Score:2)
Something to work on. (Score:3, Interesting)
Interfacing isn't that hard. What sort of "easy to use" features would be desired in a personal encryption suite?
A graphic display? PerlTK can do that. Simple means to keep track of new keys? I don't know what features would be wanted here. Lets figure it out and write it. Open Source is all about fixing problems you percieve.
-il cylic
I agree (Score:5, Insightful)
While some people characterize this as "by geeks for geeks" I don't think that is really the case. Having an extensible, scriptible component makes it REALLY EASY to build whatever frontend you want with whatever capabilities you want, and it also means that one can have the same capabilities available from a script.
Now, I agree that GPG is not yet ready for widespread adoption, but it is not the open source or UNIX mentalities that are broken. The tool just needs some time to mature.
Re:I agree (Score:5, Insightful)
I'm aware that I've just made a vague, sweeping generalization about just who would complain about Windows bloatware, and that I'm being slightly inflammatory. But bear with me.
My point is that both complaints really amount to criticizing the other side's mental model of How Software Should Work. Bloatware on the one hand, and having a gazillion command line switches on the other, are software developers' different approches to dealing with the same issue: meeting the needs of the user. It's just that the user they have in mind has a different profile in terms of how they expect computers should work. Strange that I should ever agree with Spolsky [joelonsoftware.com] 100% on this.
So I stand by my characterization of the "by geeks for geeks". Switch that phrase to "by lusers for lusers", and hey presto, you're criticizing Windblows.
And that's the problem I have with this vague non-declared goal of OSS taking over the desktkop, and it's why I think losing NAI PGP is such a big deal.
You -- the Slashdot crowd "you", not the "einhverfr" you -- extol the virtues of "anyone" being able to put together a front end on top of the actual encrypt/decrypt model. Well, that's not what Joe in accounting is willing or able to do. You -- again, the Slashdot crowd "you" -- talk about the importance of encryption evangelization. Well, Joe in accounting thinks it's a pretty good idea, but can't for the life of him figure out what he needs to do to sign his Eudora-sent email in the first place.
In the end, I don't think at all that the UNIX mentality is broken, nor is Winblows' (well, not fundamentally broken, anyway).
I do think that there's a huge userbase demanding (in the economics sense) a package that will fill the gap caused by the loss of NAI PGP, or a non-MS product, or what have you.
It's just a question of whether those with the so-called UNIX mentality are willing to approach the problem from the other point of view. I'm cautiously optimistic.
Re:I agree (Score:2, Insightful)
It strikes me as ironic that the Slashdot crowd complains about feature bloat on PC software, all the while extolling the virtues of having a gazillion switches for a single command line program.
But doesn't "bloatware" refer to Megs of memory required? No one's complaining about mega-options (in closed-arch. s/w). Whereas most closed-architecture providers throw features together, thus creating "bloatware", most hackers pride themselves in the fact that each added feature of their swiss-army-knife-ware cost little to add -- by design.
Even the GUI s/w (e.g. KDE, GNOME, et al) is built with carefully crafted pride. It may be somewhat more bloated than CLI code, but by comparison (to the crap that exists behind closed "architecture" apps.), it's good stuff.
Your complaint seem to be grounded more in impatience, not good logic. Good code takes time. I'd say that, not only is your observation about finger-pointing unfounded and illogical, it's also complementary to OSS hacks ;-)
I think we've been hearing this same sort of complaint a lot, lately. "Why does it take seven years for Wine to match the Win95 API?". To me, this means that people are hanging their hopes on OSS to save (or at least better) their future. But the waiting game is something we're not used to having to play, either.
A glacier is a good analogy for OSS progress as well as market impact. Moves really slow, but is absolutely unstoppable! (Oh, and it eventually destroys everything in its path, too.)
Re:I agree (Score:4, Insightful)
I think you're missing the distinction between flexibility and "bloatware". Software only becomes bloatware when all those additional feature impede the everyday use of the software. Command line switches don't cause this problem, regardless of whether of not it's a command line Unix program or a command line Windows (I know, I know). The reason being that most command line programs use few switches for normal operations. Bloatware is usually a GUI problem. When anything and everything is configurable in a GUI it's easy to design the interface poorly so that it's difficult to do common things without all of the different options getting in the way.
There's also the problem with poor performance in bloatware, but that's more of a problem with poor coding and programmers taking the crap they heard in school "hardware is cheap so you don't need to worry about performance" as scripture. That mentality can apply equally to any software regardless of platform.
Re:Something to work on. (Score:2)
It's already been done. It *is* a doddle to use. (Score:2)
I can now use GPG encryption with anything that can cut/paste.
There are similar frontends for Linux/Gnome/KDE etc.
Re:Something to work on. (Score:2)
So, not trusting the corporations with our security means we have to write our own crypto and make it easy to use? Heh, cool. We can do this.
GnuPG in Mozilla (Score:2, Insightful)
If you have an account at Mozilla's Bugzilla [mozilla.org], vote for this bug here [mozilla.org].
The Enigmail Plugin (Score:2)
GnuPG functionality is available for Mozilla through the Enigmail [mozdev.org] plugin. It finally made it out of development and is apparently ready for production use. You'll need Mozilla 0.9.9.
Re:The Enigmail Plugin (Score:2)
Oops, it's still in development... I misread, the announce. It isn't done, but it's useable:
Re:The Enigmail Plugin (Score:2)
Re:GnuPG in Mozilla (Score:2)
The whole point is getting GPG to "the masses." The masses don't use Mozilla. "By the geek, for the geek".
I used the PGP Eudora plug-in on the Mac and it was slick. Select Decrypt/Encrypt, done. No front-end, no copy and paste into a helper app, just a single menu selection.
Outlook plugin (Score:3, Interesting)
http://www3.gdata.de/gpg/download.html
Try the many front ends (Score:5, Informative)
WinPT is quite good.
http://www.winpt.org/
But I've only found one "free software" package which is up to scrach with it's windows counterparts (in easy to install etc), and thats Apache Tomcat, and that needs some work.
Ahh well, maybe one day.
Re:Try the many front ends (Score:2, Offtopic)
Who even knows what the fucking things correct name is? Is it Tomcat? Jakarta? Catalina?
What kind of server program depends on enviornment variables? I'll tell you, Apache Jakarta Tomcat freaking Catalina with Ant on the side.
Oh, and make sure you put the correct 500 lines of crap about "workers" in the apache config file.
Yeah, it's a breeze.
-Peter
Re:Try the many front ends (Score:2)
Uh oh. This world is in trouble. You know, kids these days are tought how to move a mouse, not speak the language of a command line. Environment variables and basic scripting should be compulsary education for students at the elementary school level. So many young minds lack logic skills and critical thinking, you'd think it was the greed of some evil corporation behind all of these "difficult to install" applications.
Those 500 lines of "crap" config file could be an worthwhile alternative to an often repeated lame 500 word essay on the social implications of World War III and people who have been long dead.
Re:Try the many front ends (Score:2)
I was not fortunate enough to be exposed to *NUX until about four years ago, but I did take Applesoft Basic in the eighth grade. And I happen to have just polished off a little bash script today. That's not the issue.
The issue is that I think it is a fundamentally bad idea to have a server service depend on a special environment variable. IMO it is too fragile a way of doing things. Think "This f-ing thing starts fine from the command line, but fails to start by the init script."
You are, of course, free to disagree with me, but I think your "these kids today" attitude reflects on you far more than it does on me.
Oh, and I was in high school by the time I had any sort of regular access to computer equipped with a mouse.
So, I stand behind my statement that Tomcat (actually, Jakarta as I understand it) was unnecessarily difficult to install at the time I first attempted it (about a year ago, it may be a snap now). I'm not saying that I need a "wizard" to wipe my backside during an install, but Jakarata was too far the other way IMO.
Just as a note for perspective, it took me about four hours and two Mt. Dews to install Apache with SSL and all the trimmings the first time. It took me the better part of three days and a case of the Dew to install Jakarta the first time.
Finally, maybe I am just a dumb kid, but the last paragraph of your reply didn't make any sense to me at all. I'd really like to know what you meant and I hope you will offer a bit of an explanation.
-Peter
Re:Try the many front ends (Score:2)
Everything with Java freaks me out for some reason. Every time I delve into something Java related I fell inundated with so much jargon that it is easier to just not use it.
Catalina:
Is that the _OLD_ version of Tomcat, or one of the componets, you know I really can't remember.
This is really funny. My point was that the Jakarta stuff has way to many shifting labels for a freaking servelet engine and your response is basically "no it doesn't, it's quite simple . . . now how the hell does it go again?" (BTW, I take it that it is the new new servelet container . . . whatever that means.)
Does lack of knollage mean lack of hillyness?
Why do you feel you need to resort to name calling?
Have I fallen prey to feeding a troll?
-Peter
Re:Try the many front ends (Score:2)
Yeah, it can't have been XML because it was full of impossible to follow comments surrounded by hashes. You know the kind:
##########
# comment #
##########
I had a better example, but the lamness filter wouldn't let it by. Anyway, it had these huge comment blocks that really didn't shed any light on things. I'm sure they were really meaningful to people who already knew what the stuff did, but that doesn't help me much, does it?
Anyway, I hope it is better now. Maybe a lot of guys like me kept harassing them and they made the install a little nicer.
I'm totally with you on the "one man's pleasure" thing. As I said in another post in this thread, Java stuff always gives me the heebie-jeebies, but I know lots of guys who are smarter than me who love it. Go figure.
-Peter
Re:Try the many front ends (Score:5, Insightful)
GnuPG doesn't support ADKs (additional decryption keys). A lot of people don't LIKE the whole idea of ADKs. But look at it calmly. I would NOT have an ADK in my personal PGP key under any circumstances. But the PGP key I use for work - that has a designated revoker (so if I'm sacked the key can be revoked without my cooperation), and an ADK that *requests* (it cannot enforce) that items encrypted to my work PGP key can be read by one of our Corporate PGP keys (whose use is very highly controlled - and is held split anyway).
I have encrypted disk partitions - but if I'm hit by a bus, the Corporate disk ADK can recover the data that belongs to the business.
GPG doesn't inherently support key splitting, or disk partition encryption. The key splitting allows proper auditable control over particularly powerful keys. For example, our Root Corporate Signing Key is split amongst 8 trustworthy people and at least 4 of those 8 must cooperate to bring that key together for use.
GPG is great, but it won't replace PGP in the Corporate setting (where it is used a lot more than you might expect...) even WITH a nice frontend until it can support such features. I look forwards to the time when it does!
A business cannot risk losing access to data which is encrypted, so these facilities are required.
Re:Try the many front ends (Score:3, Interesting)
If businesses want to use open source for something that the open source programmers don't feel like doing, then they will need to subsidize the development. That's the way it works. But if they do, then they get the options they want.
If they choose to go with a closed source product, then they get what the developer provides, until the developer decides to stop providing it. If it's open source, then they get it with no time limits, but if the project stops supporting it, and they want maintenance, then they will need to pay for it, in some way or other.
TANSTAAFL? Well, not really. But if your menu is the same as the other guys, then you can sure get a cheaper rate. And if you need a specially selected choice of wine with your dinner, then you pay extra.
OTOH, if you go closed source, you probably don't have any choice as to what will be provided on the major products (that's a result of what they call a monopoly). And for the lesser products, you still don't have much choice after you make your purchase.
Nothing's perfect. Open Source has it's flaws, and some of them are a bit excessive. But in my mind they pale in comparison to the flaws of closed source with a central monopoly.
Back to GPG and the need for added features. If businesses want the product that you describe they can:
1) write it from scratch or hire a consultant to do so
2) modify an existing open source program as permitted by the license. If they are modifying GPG, then the GPL determines their choices. Which includes keeping everything secret, but also include forking the GPG into (say) the GPGC and just adding the features that were missing. This would probably also make modifying the existing GUI shells relatively simple.
3) do without
4) do something illegal, and count on chance and their lawyers
5) do something I haven't thought of
The features that you mention all seem quite reasonable for a commercial group to want, but it is quite unreasonable to expect an agglomeration of individuals to be in favor of them. E.g., if I were to have an encrypted disk partition, then it would be to my benefit if nobody could read it without my permission. And if I quit in anger, or was fired, then I wouldn't want the company to be able to read my disk. It would (perhaps) be to their benefit to be able to do so, but it's not at all clear that it would be to my benefit.
This reasoning applies to all levels of the company from the secretary to the general manager. And this may in some measure explain why no significant effort is put into features of benefit to the company but not to the individuals. (Of course, computer techs will be most aware of this, but then they would also need to be the ones initiating the argument for funding the project.)
A closed source company would be more likely to provide these functions, but they would also be more likely to keep their code secret and unmaintained if they went out of business. Perhaps leaving you with disks they were unreadable (what is the most likely cause of their going out of business?).
Re:Try the many front ends (Score:2)
Re:Try the many front ends (Score:2)
check out this message. (Score:2)
Make it Seamless, Silly. (Score:5, Insightful)
I use gnupg. Not a lot, but with a few people who have it set up right I can just exchange PGP messages without really doing anything, which is the way it must be.
I have tried many, many products to do PGP, and they all have problems. Even GPG with my favorite mailer had some fairly big setup hurdles. Fortunately once I cleared them it was relatively easy. I can only imagine that grandma is never going to use it at the current state of integration.
PGP functionality needs to work perfectly with mailers. You enter a pass phrase, and it just works. Until that happens the masses are not going to use PGP. This is imporant. If it were that easy, 90% of e-mail could be PGP encrypted, by default no questions asked. You can get there now, but only if you know a lot about PGP, and communicate with people in the same boat.
Re:Make it Seamless, Silly. (Score:3, Informative)
Re:Make it Seamless, Silly. (Score:3, Insightful)
Until the plugins ship with the mailer, it is not seamless.
Re:Make it Seamless, Silly. (Score:3, Informative)
Re:Make it Seamless, Silly. (Score:3, Insightful)
No, it's not. Grandma installs a mailer. She
sends an e-mail to her grandchild. If it works,
she's happy, if not, she will do something else.
She's not going to install a plug in.
Plug ins are fine to make things upgradable,
and flexable. But let's face it, web browers
ship with plug ins because they know 99%
of the people want them. If everyone was moving
PGP e-mail, that would be true of mailers too.
I don't care if it's an RPM, a FreeBSD Port,
or a package to download. It must auto-install
the plug in. It can come with the mailer, or
be installed as a dependancy, but until it's
automatic on all platforms it won't be
used by the masses.
Re:Make it Seamless, Silly. (Score:3, Funny)
GPA [slashdot.org] features a GUI and is very straightforward to use. I'm an encryption retard and I figured it out.
Re:Make it Seamless, Silly. (Score:2, Interesting)
This has seemless GPG integration. You select the key you want to use, enter your pass phrase on startup and it's ready to work.
Key exchange is managed from within the chat windows. There is an option to send your public key to your "buddy" and it automatically inserts the key into their keychain.
This is as seemless a use of encryption tech that I've seen in software and would make a good model of how to integrate into other applications.
BTW. I've had some experience in using PGP in a commercial environment being responsible for adding mandatory PGP signing to the UK domain registry in 1996.
There's plenty of alternatives! (Score:2)
Niche market. (Score:2)
As much as I like GPG, I don't use it for personal emails, however. I believe that S/MIME is a better system for encrypting personal emails, simply because support is already built into the major email clients (Netscape, Outlook Express) already. When there is a button built right into my friends email client, I have a much greater chance of getting them to use that feature, as opposed to having them download a new, seperate piece of software. Now if Evolution would just support S/MIME (they've been teasing me with that grayed out S/MIME panel), I'd be all set.
Get PGP encryption into Mozilla (Score:5, Interesting)
http://bugzilla.mozilla.org/show_bug.cgi?id=22687 [mozilla.org] and vote for what is probably the singles most popular bug there is. They need a framework which allows folks to plug in something like GPG at will. Plenty of work went into trying to get somewhere without any luck.
Re:Get PGP encryption into Mozilla (Score:2, Funny)
Not quite accurate.. (Score:2, Informative)
Re:Not quite accurate.. (Score:2)
Re:Not quite accurate.. (Score:2)
I am a heavy user of PGPdisk, having probably 15 - 20 gig of data stored both on disk and CD. Until GNUpgp gets PGPdisk compatibility, it simply is not an option for me.
There was also the "PGP hosed my TCP/IP stack" problem that a number of people experienced prior to 7.0something.
Why did they drop it in the first place... (Score:4, Insightful)
Went on their website
It was so weirdly organized, I mean you could get a "single user" license, okay cool, "i need 10 of that" wrote down the price... sent an email to get a PO
Went back a few days after, couldn't find that product, felt on the desktop security thing for buisness, ok, 5x more, wrote down the price, went to get approval, came back a day or two later, price/license switch again... couldn't find the exact same thing that I saw the day before...I just dropped it (I don't have time to waste an hour or even minutes on a badly designed website that will make me swear and kill the next person asking me for support
That's ineffective E-Commerce, and I thought it was sometime hard to find a specific download or older bulletin on microsoft's web site (and google helping more than most websites's own search engine), but this was ridiculous, not to mention all the license type and so on. If I dropped it, a lot of people probably did the same. My question is, why the heck not having something CLEAR and a decent price list, why putting things in 5+ click deep or changing stuff left and right just so the bookmarks don't work anymore and have a nightmare to find that specific thing again?
They can blame the lack of sales, but they are to blame. I mean, when I go and buy a systemworks license (to name an example), I know the price for 1, I know the price for a 5 pack, it's clear, it's constant and they don't have a gazilion difference licensing of the same thing doing the same function exept worded differently thus giving you a different result at every searches if you change a space somewhere.
All this said, it's a shame that there are not many alternatives, the freeware version does the job but the problem is "it's not legit for buisness to run this", I wonder what will happen if the product isn't sold anymore... does it make it obsolete and unavailable thus legit to use the freeware version? it does the job on the windows platform at least.
Don't you mean... (Score:2, Insightful)
The article highlights one of the problems with Open Source software today[...]
I can finish that sentence: "just because the writers at large popular online magazines can download something for free (and for Free), they feel that it's ok for them to bitch about how Open Source software isn't up to snuff, and yet they never try to make things better."
I'd bet he hasn't entered one "enhancement" bug report, reported one request to the mailing list, or done anything else to make gnupg better.
I work for a company whose product is open source. We have only so many developer hours to devote to feature enhancements. Guess which things get priority first? Either suggestions from support customers, or requests for features on our discussion list. If no one asks for it, it doesn't show up on our list of things to do.
Just because you can't code doesn't mean you can't contribute. Make docs, try to find bugs, make feature requests. Shut up or put your money where your mouth is.
Open Source, power users vs. The Masses (Score:2)
Sig: What Happened To The Censorware Project (censorware.org) [sethf.com]
GPG has delivered for me (Score:3, Interesting)
And it's quite easy: gpg -c and -d
Decline of PGP. (Score:4, Insightful)
Now why the decline? Thanks to the widespread usage of SSL and now SSH we have convinced many of these old guard companies to go with real time data that is sent over SSL connection or through SSH tunnels (or even with scp). This is great! No more pesky FTP around. Easy key management. Easy to setup and watch. Sure the data isn't as secure in transit but really if it is secure enough to give this user the data, it is secure enough to transfer it with. Of course the best thing about realtime data is we can throw it away instantly meaning there is nothing laying around for the average village idiot script kiddie to pick up.
The only downside is we have some users that actually SCP PGP encrypted files over to us. It will be a shame when that type of security has to go away because they will dump PGP the second they can't purchase support for it.
PGPFreeware? So what? (Score:3, Insightful)
Re:PGPFreeware? So what? (Score:3, Informative)
About once or twice a year a bug of security significance is uncovered in PGP (e.g. the ADK bug, the RNG on UNIX bug, the keystorage bug etc) and this would render the latest 7.02 next to useless.
Why can't people amend the source code and recompiler themselves? They don't have access to the source code.
Also remember that PGP is now very (over-) complicated and includes various drivers and kernel hooks. Every new version of an MS operating system (Win2k, WinME, WinXP) breaks compatibility.
The best current hope is the CKT [ipgpp.com] builds of PGP, that are based on the 6.5.8 code. These have all known bugs fixed and still work on all Win32 operating systems. This is also the only version that is actively maintained!
"by the geek for the geek...." (Score:2, Redundant)
I will probably get moded down to -50 Troll or Flamebait for this but here it goes....
Open Source has many problems but "by the geek for the geek" is NOT one of them. For some reason people seem to think that Open Source exists to serve the greater of humanity, and end human strife, etc.....(Whatever noble cause you can think of) But Open Source software is not primarily "by the geek for the geek".
It is primarily "by the geek for him/herself". The reason that there are not a bunch of pretty GUI front-ends that really wow people is because the people who code them don't need/want a GUI front-end.
If people want pretty front-ends then they should code them themselves.... It is easy to stand back and lambast [dictionary.com] the Open Source community for not being more user friendly but I have a news flash for ya.
Most Open Source developers don't care.... Open Source is about coding: what you want. Build a front-end yourself.
OSS developers code for fun, for their own sense of accomplishment, and for personal use.
As far a "mass adoption", If people are too lazy to spend the time to work through and figure out a CLI then too bad for them. If your privacy is really that important to you then you will have to "tough it out" like the rest of the geeks.
My
this assumes you need to change (Score:2, Informative)
GPG user-friendliness is *essential* to security (Score:2)
GPG is different because, unlike most software, it's not something you use by yourself. Crypto is something you must use in concert with other people, and not just other geeks, but possibly your boss, clients, family, etc. This isn't just by-us-for-us: for once, it MATTERS what other people think of the software. Therefore, an easy-to-use interface is not just a matter of aesthetics, it's an essential feature -- and since it's the only way to facilitate widespread adoption of crypto, anything else is a security hole.
Cheers,
IT
Geeks & Interfaces (Score:5, Interesting)
Ech.
Some great concepts but still a cranky idiosyncratic bastard of a program. Trivial to use? Sure, after reading far too many poorly written manual pages. Easy to interact with? When it didn't hopelessly mangle what it was supposed to secure (we didn't want one-way!) Integrated - as long as you didn't do this or that or...
Look, you want a well integrated NAI program look at how NAV interacts with Outlook. Yeah it's a big pig and lots of folks hate it but to the user it's *not an issue*. It scans for nasties. It scans incoming & it scans outgoing. It can be configured with a few clicks in a clean interface written in simple language. It just works.
Personally I ask any ambitious developer to take the same strategy NAI does for NAV and don't try to build yourself into the apps and instead become a proxy. I'd love a local PGP proxy app that my mail could go through. The only interface I'd need would be a tiny plug-in to set a header on messages for the proxy to read and act on. That sort of plugin should be simple enough to write for all of the popular email apps, let the engine remain consistant across everything.
With how to talk to the engine simplified then the effort can be moved to making PGP as an installation easier, more intuitive, and less of a jerk. For one thing default to a minimal install, go the install-on-demand route if need be, but DON'T dump a half-dozen applications into a system by default. Firewalls and VPNs are lovely but make sure the customer knows what they're getting into first, leave it as a second phase install by default. Plug-ins? Drop folks to a web-page where plugs for each app can be listed. Include some default plugs in the install for the most common uses but still encourage the ambitious to check out the newer/more featureful/not-in-the-distrib versions.
Finally, why isn't there yet a standard for PGP-certifying and/or encoding web-pages?
Pmail, GPGP, COM Programming (Score:2)
http://community.wow.net/grt/qdgpg.html [wow.net]
http://community.wow.net/grt/nsdpgp.html [wow.net]
Encrypted email will arrive (Score:5, Insightful)
I sign nearly all of my outgoing emails, but seriously, encryption will remain a geek toy until AOL or another big player decides to provide public key infrastructure (PKI, keys signed by eidey trusted authorities, or sufficiently many people that are minimally seperated from you) for its users. There are plenty of GUI encryption email clients out there. I believe there's a GPG plugin for Eudora. However, finding your friend's public key is hte big problem right now. Once everyone's ISPs ste[ in and sign the user's keys and proide key servers, then signed and encrypted email will be the norm. After a short bit, you will be able to filter out SPAM by doing good checks on signatures, or prosecuting those spammers that actually sign their emails with valid and registered keys. Encryption will also greatly increase CPU demands for mass emailing. This is why ISPs will like crypto: it deters spam and reduces thier bandwidth requirements. The big question is: how long will it take for a major ISP to start providing PKI.
Key generation isn't hard. Once AOL starts signing all of their users' public keys, then it will be common practice for you email client to go the all of the recipients' ISPs, verify their Verisign certificate, and verify theirsignature on the user's public key, then encrypt everything at transmit time.
Key generation isn't all that tough. Nearly everyone trusts Verisign.
Unix way of doing things. (Score:2)
The thing is, good programs are extensible because they just provide the core of doing things the right way. So does gpg. In easiest form, it can create keys and it can en/decrypt data.
This is what it does and that it does well.
Now, if you want bell and whistles, go find a software that you like and ask nicely the authors to include support for gpg.
For example, ive used gpg for allmost a year now, since gpg support was first published in Evolution mailer. I created my keys (3 commands, i have 3 emails and i wanted to use different keys), and put the date into Evolution. Since that day, i havent invoked gpg directly at all. I have some gui tools to import/scan keyservers for keys that im missing and evolution itself does the rest. So, in my eyes, gpg is as good as it can get.
Outlook plugin (GPL'ed) available (Score:2, Informative)
http://www.gnupp.de/start.html
Roughly translated:
Security for e-mail, e-commerce and e-government. The goal of this project is to deliver free encryption software that's easy to use.
The fun thing is this:
http://www3.gdata.de/gpg/download.html
and if you don't understand those strange words, you can download here:
http://gdataspace.de/download/gpg/GDATA_plugin_
This is an Outlook-Plugin for GnuPG. Using this plugin GNUPG is easy as 1-2-3.
HTH
Jan Wildeboer
Re:Outlook plugin (GPL'ed) available (Score:2)
Nice. Do you know if it works with XP/Outlook 2002? I had the full commercial version of PGP and the Outlook plugin worked fine on Win2K/Outlook 2000 but was mysteriously broken on the XP versions (something about relying on a Service that didn't understand Fast User Switching).
There is a very good frontend available right now! (Score:3, Informative)
Non-geeks had trouble with NAI PGP (Score:3, Insightful)
Often people say that "GPG needs a frontend before non-geeks can use it". That point is probably true, but even though NAI PGP has had a "mature" GUI based front end for several revisions, normal users are still incapable of getting their head around creating keys, the difference between public and private keys, the difference between signing and encryption etc etc.
A usability study [cmu.edu] was undertaken by researchers at Carnegie Mellon in which they found that virtually 0 non geeks managed to use PGP successfully anyway.
Sure, OpenPGP based programs need to achieve better reach, but simply copying the NAI PGP design won't achieve this goal....
GPG and MacGPG (Score:3, Informative)
PGP is something I've played with over the years, like a lot of geeks, but never used religiously. But I decided a few months ago that it was something I should start using regularly, so I sought out a mail client with built-in PGP (or variant) support. I found a neat little (non-free) Windows e-mail client called The Bat! [ritlabs.com] (that's their exclamation point, not mine), which had not only built-in support, but you can configure it to use PGP, GnuPG, and even their own OpenPGP implementation. That and many other cool features persuaded me to buy that e-mail client, after which time I decided to throw the switch [cavaliers.org] and begin signing all e-mail that I send.
Along the way I discovered WinPT [winpt.org] (Windows Privacy Tray), which is a decent little frontend for GPG. Remember, GPG is a backend -- how you interface with it is up to you.
The came my Titanium PowerBook. I got it for all the reasons mentioned around Slashdot and elsewhere, but I didn't really expect to find cool things like a good GPG frontend, let alone e-mail with GPG support. Boy was I wrong! I went to the GPG site and found a link to the Mac GPG [sourceforge.net] site, which ports GPG to OS X. Not only the backend, but a frontend that integrates with the "Finder" (that's Mac-speak for the "Explorer" equivalent), right in the "Services" menu (which is much like the global right-click menu in Windows Exploror.
But that's not all! I saw further down on the same page that somebody else [sente.ch] has written an extension to the OS X default mail client (which ain't as bad as you might think) that provides very good GUI GPG support for mail.
So, even though switching over to the Mac isn't the easiest thing in the world (I say that as I sit here typing on my Windows machine for reasons I won't go into), I can say that GPG is among the least of my problems.
RP
One More Thing about OS X and GPG (Score:2)
There's also a great little instant messaging client available for OS X (called Fire [epicware.com]) that connects you to all the major services at once, and it has built-in GPG support. And very good support, too.
I'm not yet to the point that I feel I need to either sign or encrypt my instant messages, but that time may come, and it's nice to know that Fire is ready.
RP
GPG is delivering! (Score:2, Informative)
Timo Schultz's WinPT is an all-in-one encryption frontend which sits in the system tray and does EVERYTHING. Even safely wipes data from the drive. And for convenience, he has an Outlook Express plugin (which works!) and a Windows Explorer plugin (which I don't need and thus haven't tried yet).
Give it a try and see...
http://www.winpt.org
Re:what have YOU got to hide ? (Score:2)
I talk to my bank quite a bit, have they ever asked to encript email messages, NO! Should they YES.
Same reason we need encription on http.
Also if everyone SIGNED there message (which I USED to do, untill I moved Endure) email born viruses would not exist (to the degree they do now, your'll still get some fool who opens unsigned email or will type there password when they should not)
Re:what have YOU got to hide ? (Score:4, Interesting)
1: Financial information (bank acct transactions, credit card accounts, tax information, etc).
2: Information I need to get past the casual check (such as viruses I am analyzing for possible harm) so that my AV software or mailer won't balk at it.
3: Confidential business information.
Here is another application to Assymetric Encryption: Digital Signatures (basically encryption in reverse). I digitally sign all:
1: Confidential business information (also encrypted).
2: Security-related emails to people who depend on my security skills (and need to be able to trust that the email really came from me-- social engineering IS a real threat).
I also sign emails that contain attachments so that the reader knows that I knowingly sent them.
OK. So is this enough of a reason why Citizen Joe would need good strong public key encryption (note that symetric encryption like 3DES will NOT provide for digital signatures).
Re:i dont' think the "geek factor" is the real bar (Score:2, Insightful)
Uh, think 9/11. Think "encryption is only used for terrorism and illegal pornography." Think "there's a ph@t defense contract in it for you if you make that product go away."
write our own guis to interface with the command-line
While this is all well and good, it didn't seem to help in the face of Microsoft and Netscape going with S/MIME. Possible reasons for this choice are left as an exercise for the reader.
Re:i dont' think the "geek factor" is the real bar (Score:3, Insightful)
> Think "there's a ph@t defense contract in it for you if you make that product go away."
*Exactly*. This isn't the first, either--far more suspicious was the untimely death of the ZKS' Freedom Network, which the respected founder insisted was planned before 9/11, but which was never announced until a a short time after 9/11 and which left users with practically no advance notice. One suspects that either the founders of the Freedom network got a good talking to with some sticks and carrots, or they got worried that theyr network was or could be used by terrorists, and shut it down out of "conscience." A rebuttal was even posted here on
Encryption for the masses is exactly what the U.S. government doesn't want, because it would render their unbelievably involved Carnivore/Echelon/UKUSA electronic eavesdropping network useless if we all started seamlessly using PGP or encrypting all our traffic through Freedom servers.
It is, however, the only way we can guarantee our Constitutional rights to privacy and freedom of expression in the electronic aether. It will always be trivial to the dedicated criminal or terrorist to communicate covertly over the Net, no matter how many carnivorous hubs may be weeding through traffic. It's the little guys caught in the crossfire we have to worry about--the kind of guys who are posted about every couple of weeks on
Face it: governments *always* want more power, and when unchecked they take it. That's why our system was deliberately created with a lot of checks and balances to impose a sort of "gridlock" to prevent sudden sweeping changes to governmental authority. 9/11 removed those deliberate obstacles and got everyone working together to impinge our freedoms with USA/PATRIOT and the FBI's larger scope for its surveillance projects and busts. People really need to start considering getting encryption integrated into everything they can, seamlessly, before they're no longer allowed to. Don't think it couldn't happen--the likelihood of the Court allowing various limited encryption bans does have a correlation with the number of people using encryption...
Re:out with PGP (Score:2, Insightful)
Because encryption needs cooperation from both sender and receiver and is therefore subject to the 'critical mass' rule. People are going to be reluctant to move to new technologies because they won't be able to communicate with anyone until those people adopt too.
Re:understanding prerequisite for security (Score:2)
If people do not know what they are doing, they have no way of knowing that something should require encryption, such as a credit card transaction online, etc. Ignorance does not beget caution!
Re:Why is PGP Freeware not an option? (Score:3, Interesting)
I have actually just installed PGP 7 Freeware on my NT4/Win2000 box, and was a bit worried when I saw that qoute.. I want PGP 7 Freeware to be secure. Is it not so?
Can somebody please explain ?
Re:Why is PGP Freeware not an option? (Score:5, Interesting)
In fact, there are several unofficial forks. I myself use 6.0.2ckt Build 07 from http://www.ipgpp.com/ , which seems to be popular with a lot of folks. The real hardcore PGP zealots are still using 2.6.x branches. Personally, I have no idea what the submitter of the story was thinking when he used that phrase. Most PGP users will continue to use PGP, and if bugs are found they will be fixed, just as the unofficial 6.0.2ckt version has gone through 7 build releases as has 6.5.8ckt. If a bug is found, someone will fix it, no problem.
A library opens a pipe (Score:2)
We should be able to link that program in to mail readers, web browsers, databases, all kinds of things, but none of that is possible to do easily because it needs to run as a separate program.
What's wrong with creating a library that interacts with gnupg through a pipe or other method of IPC? That's what (e.g.) X11 does: apps talk to xlib, which marshals calls to the X server.