Slashdot Mirror
GPG vs. PGP?
OctaneZ asks: "What are the relative merits and drawbacks of using Gnu Privacy Guard vs. Network Associates' PGP. I am not referring to the fact that GPG doesn't use any restricted implemtations or algorithems; or that GPG was not affected by the recent PGP hole; but other more everyday issues. How is interoperability between the two. As well as integration into common applications such as Eudora in windows and others, possibly PINE, in LINUX. Could this be deployed such that the learning curve of transitioning users from PGP to GPG is not too steep? I am a strong beleiver in encryption, and have used PGP for a very long time, however I would prefer to use an OpenSource/Non-restricted program; however the usefullness of said program, as well as the security takes precidence, at least in my book."
If you're in a windows environment, there's really no choice -- pgp is by far the more integrated and useful solution. If you're using a Windows mail reader, then go for PGP for Windows.
In a unix environment, you'll find either to be roughly equivalent. Some minor differences I've noticed since making the migration to gnupg:
- gnupg has a nifty feature that makes it automatically grab a key off the keyserver if I read a signed email by someone whose key I don't have. This is nifty.
- gnupg apparantly doesn't have a way to retrieve a key from the keyservers by email. This is a real pain in the ass. With pgp, you can just import the key for "nugget@slacker.com" and if there are keys on the server for that email, they'll be imported. gnupg requires you to know the key ID (like E43C5FC3).
- The pgp command line syntax and commands are cryptic and obtuse
- The gnupg command line syntax and commands are unnecessarily verbose and will push you over the edge with your carpal tunnel if you're doing much manual work
- PGP has the edge for application integration, but this is rapidly changing. gnupg works fine with mutt, which is the mail reader you want to be using anyway, so it's a moot point.
:)
- gnupg's key management is vastly superior to pgp's in both conveying key-management information as well as allowing access to key-management functions.
Plus, there's a nifty GUI for gnupg that's usable but which is called GPA (It's inIf you're already using pgp, the differences aren't enough to justify conversion, but if you're just starting out -- gnupg seems to be the most viable option. And, of course, mutt is too good to believe.
The learning curve for either is the same, mainly just getting past public key crypto concepts and mechanisms. Wrapping your brain around "public key" and "private key" and the difference between "signing" and "encrypting" is well over half the battle.
"Central clearinghouse" PKI is what SSL uses. SSL certificates are signed by Certificate Authorities (CAs), such as VeriSign. CAs are trusted entities who verify an applicant's identity before issuing them a certificate. A certificate is the same as a public key except that it has more information about the owner - usually the x.509 Distinguished Name which consists of a "common name" (CN), "organizational unit" (OU), "organization" (O), "locality" (L), "state" (S), "country" (C), and sometimes email. For instance, Microsoft's DN is CN=www.microsoft.com/OU=mscom/O=Microsoft/L=Redmon d/S=Washington/C=US. How do you know which CAs to trust? Web browsers typically have a built-in list. Anyone can act as a CA, but when someone views a website which is using one of that CA's certificates, the user's web browser should (and most do) display a warning. Go to Fortify's SSL test page and my HTTPS website. Fortify's certificate was issued by Thawte (who I believe is now owned by VeriSign), a widely-known CA whose certificate is in most/all browsers. My certificate is signed by the "Zevils CA", which doesn't really exist. Your browser should display a warning when accessing the zevils site but not when accessing the Fortify site.
The other popular method of PKI is known as the "web of trust." This is what PGP and GPG use. If you know someone in real life, you have proof of their identity (such as a driver's license), and you both have GPG/PGP keys, you should sign each other's public keys and upload the signed keys to the keyserver. Here's how the web of trust works (with help from the GNU Privacy Guard Handbook):
Alice knows Bob in real life. They both use GPG. Alice knows with absolute certainty that a certain key is Bob's key, and that Bob is who he says he is, so she signs Bob's key with her key. Alice and Bob discuss PKI every day at lunch and Alice knows that Bob has excellent judgement on when to sign a key, so she tells GPG that she trusts Bob's signature on a key as much as her own (she can also give Bob marginal trust or no trust - see GPG documentation for details.) Bob has signed Charlie's key. Thus, Alice trusts Charlie's key. The web of trust, at least in the GPG implementation, is quite flexible and does extend to a depth of more than one. See the GPG handbook for more information.
Of course, PKI is not a magical security fairy that sprinkles security dust on your keys while you're asleep at night. Bruce Schneier and Carl Ellison have written an excellent paper, Ten Risks of PKI (Computer Security Journal, v 16, n 1, 2000, pp. 1-7)
Mainly, PGP rolls off the tongue better than GPG does.
My big gripe is that there's no integration between GPG and Netscape (what I use for email), but that's not the fault of GPG... :-(
--
Your Servant, B. Baggins
Now, for some reasons not to use GPG:
To finish, I'll mention some software that can use GPG:
Hope that helps, in some way or another.
Why are people signing their e-mail with PGP/GPG?
When I was young, the advice from grown ups was "do not sign anything you don't have to, be it a contract, a letter, a memo, anything. If you sign it it means that you meant it, if you don't is just idle chatter".
So, /.ers out there: how about it, why do you sign your e-mail letters?
You're still missing the point. Certificate authorities don't really solve much of anything, if anything at all.
Let's say that I go to Trusted Certificates, Inc., "Where We Make Even Our Mother Show Six Forms of ID". I register my key, and lo and behold, I have "verified identity". Anyone who wants to can check my signature with the CA and discover it's valid.
Guess what? That's still not enough.
Let's say that I want to steal $10,000 from the bank. First, I need a conspirator--I hand over my keys, then go on vacation in Aruba. While I'm in Aruba, sipping mai-tais on the beach, my conspirator is posting innocuous messages, as me, to newsgroups.
I come home and send an email to the bank, asking it to transfer $10,000 from my account to the First Bank of Never-Say-Anything. The bank checks out my keys with the CA, and lo and behold, it checks out. Since they've "verified" that it's really me, they make the transfer. (In reality, they haven't verified anything--only that someone who knows a specific string of bits asked for a transfer.)
At that point, I raise holy hell and scream "What the hell is going on here? I didn't authorize anything!" The bank can't get the money back from the First Bank of Never-Say-Anything, and so they're stuck trying to prove that it really was me who sent the authorization.
At that point I just have to point out the various postings to alt.sex.hamsters, which were signed with my key. "Look! I was in Aruba, sitting on the beach drinking mai-tais! Someone compromised my keys!"
... and at that point, the only way, the only way, for the bank to show that I'm lying is to find my conspirator. And in the meantime, I get to repudiate every single message that bears my signature ever since the compromise date. The $10,000 transfer? I didn't do that. Sending incriminating emails to government officials? Wasn't me. This, that and the other? Unh-uh.
Compare this to a real signature, which--by its very physical nature--possesses forensic value. It isn't just a string of bits; it's evidence, and oftentimes is enough to get convictions in court. Real signatures are also not wholly invalidated simply by the appearance of forgeries, as opposed to digital signatures. If I send a paper letter to my bank authorizing the $10,000 transfer, they'll have a handwriting expert compare the signature to the signature on file. They'll compare everything from the shape of letters to the inks used in the paper. And even then, they won't trust it--they'll have a bank teller who knows me well give me a call and ask me, "Do you really want to do this?" If the bank teller recognizes my voice, then the transfer goes through.
We have extremely robust identification and verification mechanisms in real life which are composed of interlocking parts. We don't have anything like it in electronic life yet. We have things that bear a strong resemblence, but the devil is in the details.
Digital signatures are not real signatures. They're different beasts which serve a different purpose. As long as all parties involved are committed to using digital signatures honestly, digital signatures work.
The instant someone realizes that there's money to be made by false repudiation, things change.
Yes, you can interoperate PGP and GPG in that GPG can be made to use PGP-compatible DH/DSS keys. But, there is a lack of support for PGP RSA keys which is a fatal flaw at this point. From what I've read, I think there are unofficial and still-buggy source code patches available from Europe for RSA compatibility--though I may be wrong--but overall the only way to maintain near-100% compatibility with most PGP users is to make RSA keys.
The only versions of PGP which don't support RSA keys are early and now-defunct versions of PGP Freeware 5.x. Other than those--which can easily be replaced by a later international version or later freeware version--all PGP incarnations can use RSA keys. This is important because many of the more privacy-conscious people are still using good ole version 2.6.x, which cannot use any keys but RSA.
This especially comes into play if you ever want to use the Cypherpunk remailer system--there have always been some cypherpunk remailers who don't have support for DH/DSS keys, but now almost all of the remailer operators who used to support DH as well as RSA have revoked their DH/DSS keys and switched to solely having RSA Type 3 keys produced by PGP 2.6.x and thus invulnerable to any ADK issues.
So, PGP is a necessity for compatibility with Type 1 (Cypherpunk) remailers. More than that, the most privacy conscious individuals are still using PGP 2.6.x for their own private correspondence, so you won't be able to communicate with those stalwarts via GPG.
That being said, now that RSA is unencumbered I'm sure GPG will be incorporating full RSA key support. But until then, it's frankly unusable unless all the other people you privately correspond with aren't using RSA, and forget about remailers unless you stick with Type 2 Mixmasters only--which are vulnerable to the NSA thanks to their short key sizes, according to one of the Mixmaster developers Lance Cottrel.
And BTW, the new version of PGP which supposedly solves the ADK issue really doesn't--it won't decrypt to the ADK if present, but it also won't notify you of the presence of an ADK--so you'd never know if someone tried to bug the key in question. That sucks.
"The more corrupt the state, the more numerous the laws."--Tacitus, *The Annals*
As a person who has written a couple Perl modules to handle both PGP and GnuPG, most recently GnuPG::Interface, I can honestly say GnuPG is a much, much more well-designed program for those who want to interact with it on a higher level.
GnuPG has a great system of interaction via pipes, which are the means to to pass in the passphrase, get status output, interact with terminal-ish interfaces, and much more. To know more about these, look up status-fd, passphrase-fd, and several others in the GnuPG manpage.
GnuPG also has a well-thought-out syntax for interaction. Each option has a long, useful name, and the more-used ones have useful shortcuts. Also, GnuPG uses cool things like command-completion, so that you don't have to type all of --list-keys; you can just type --list and it will work fine.
PGP, on the other hand, has commands like -a meaning armor, and -ka meaning add-key, which is confusing, if you are used to bundled parameters.
Well, I think the scenario you describe could be done the same way with physical signatures. You could teach someone to forge your signature convincingly, especially if you have a loose scribble of a signature like many do. I really think you're overestimating the forensic value of a paper signature; they're only rarely used in court to convict. It's not hard to forge a signature convincingly, and further a person's signature can look very different depending on their mood, their writing angle, distractions, etc. Have you ever signed something and looked at it thinking, "that doesn't look like my signature!" I know I have.
And yes, a given digital signature is rendered invalid if a forgery appears. So are physical signatures -- if you find out someone is forging your signature, you sure better tell everyone you know so they can verify that things came from you!
Fraud has always happened and always will happen. There are no plug-in solutions for fraud. Real signatures have failed miserably time and time again, and digital signatures won't solve it either. The only solution for fraud is constant examination of the facts. Why do you think your credit card company will call you if you make an odd random withdrawal from an ATM that you haven't used before?
Digital signatures are a tool, and used properly, they convey numerous advantages. Trusted blindly, they are a trap; just like paper signatures, trusted blindly, are a trap. Certificate authorities do not solve this; neither does having your signature written on the back of your credit card. The purpose of digital signatures is to make forgery more difficult in a world where every letter comes printed with the same kind of printer and on the same kind of paper. Just like real signatures.
I have seen the future, and it is inconvenient.
GPG plays nice with email to/from my coworkers who are mostly PGP for Windows users (using everything from Eudora to Outlook). And I've been able to use my old keys generated via PGP 5.x (on a Windows box).
GPG, pgpenvelope, and Pine make an excellent combination.
Umm...you might want to read the documentation that comes with mutt. There is a macro in /usr/local/doc/mutt/PGP-Notes.txt that allows old-style clear-text PGP signatures.
.muttrc or wherever (could require some fiddling, I don't use these clear-text signatures myself):
.muttrc files, which is where these came from. Good luck.
For gpg, try this in your
set pgp_clearsign_command="gpg --no-verbose --batch -o - --passphrase-fd 0 --arm
or --textmode --clearsign %?a?-u %a? %f"
Check out mutt.org for more details. There is a section linking to users'
If everyone were in the habit of signing their documents, forging an E-Mail from someone would be a lot harder. Recent fraudulent stock market manipulations would have been a lot more difficult (What's this? A press release saying that 4th quarter earnings are going to tank? It's not signed... they ALWAYS sign their press releases. I'll call them before I do anything...) Several companies would not be having to recover from having their stocks tank now. If only for that reason, it'd be a good thing.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
They interoperate seamlessly with the exception that I couldn't import my ultra-huge GPG secret key into PGP. Since the department wanted one department wide secret key, this was a bit of a problem, but taking a key from PGP to GPG worked fine, so we just did that.
As far as mailers go, VM for Xemacs is the obvious choice in UNIX. mailcrypt adds a menu entry which is handy for those lesser used functions and people not yet familiar with its keystrokes. It handles mime, has a really cool citing engine (Supercite, or you can write your own) and BBDB is really ultra-cool for address book handling. AND it does xface, which is just ultra-spiffy.
Given all that, if you're doing Windows it's probably worth paying for PGP. Outlook integrates with it well (I hate myself for knowing that) and the extra polish is worth the money. You're used to paying for software anyway.
If you're doing UNIX, GPG is probably the way to go. The UNIX PGP doesn't have all that extra polish anyway and is nastilly encumbered, even without the RSA patent. GPG avoids all that and integrates as well as possible with most mailers (And exceptionally well with vm.)
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
It seems to me that the encryption could be much more transparents over IM as well. You have a central place to store keys for one thing. I really wish that ICQ would stick pgp or something similar in with the download.
There are a number of scripts available to integrate both PGP and GPG into Pine; among them are pgpenvelope and pinepgp. There's also a little wrapper script out there called pgpgpg that allows you to use pgp syntax with gpg - I'm sure this would do wonders for the learning curve. IMO, though, if you want a really good MUA with great GPG support, mutt is the way to go.
Mike Markley - *NIX Sysadmin and all-around geek - finger for PGP key
Well, it can use PGP 5.0+ keys, giving decent interoperability (most people have pgp 5+ now as it offers significantly more secure encryption).
As well, according to the GnuPG website gnupg.org:
GnuPG is not vulnerable to the faked ARR (aka ADK) attack as PGP 5 and 6 is. The reason for this is that GnuPG does intentionally not handle those "additional recipients requests". BTW, those Big Brother packets are not defined in the OpenPGP standard - they are a proprietary PGP extension.
Also according to gnupg.org, these are the GPG features:
Full replacement of PGP.
Does not use any patented algorithms.
GPLed, written from scratch.
Can be used as a filter program.
Full OpenPGP implementation.
Better functionality than PGP and some security enhancements over PGP 2.
Decrypts and verifies PGP 5.x messages.
Supports ElGamal (signature and encryption), DSA, 3DES, Blowfish, Twofish, CAST5, MD5, SHA-1, RIPE-MD-160 and TIGER.
Easy implementation of new algorithms using extension modules.
User ID is forced to be in a standard format.
Supports key and signature expiration dates.
English, Danish, Dutch, Esperanto, French, German, Japanese, Italian, Polish, Portuguese (Brazilian), Portuguese (Portuguese), Russian, Spanish and Swedish language support.
Online help system.
Optional anonymous message receivers.
Integrated support for HKP keyservers (wwwkeys.pgp.net).
Yeah. That's it. There's decent integration with GNOME, so try it out.
Now, I can appreciate the desire to do things Right. And I applaud the developer's dedication to a standar that, apparently, he was involved in creating. But by forcing this format, it made Mutt incompatible with my environment. Mutt went. I was sad to see it go.
Maybe I was missing a finer point in configuration? Or does the newer Mutt releases allow ditching the PGP/MIME format? Or perhapse Mutt's primary users tend to not communicate with Windows users. :)
Any insight is apprecated.
The GPG developers wisely chose to reject this feature, so if you use GPG or another non-ADK-supporting variant on PGP to encrypt a message to somebody who has an ADK stuck on their key, it will not encrypt the message to the ADK. This is good, but it's not enough - it only protects your outgoing messages, not incoming messages encrypted to you.
The recently discovered ADK attack found that if a Bad Guy attaches an ADK to somebody's key, it doesn't invalidate the signatures on their key, and doesn't require their signature, so the Bad Guy can distribute that bugged key, and anybody who uses a pre-6.5.8 version of PGP that supports ADKs and uses the bugged key will encrypt to the Bad Guy as well. If you use GPG to encrypt all your PGP messages, you won't accidentally encrypt to the Bad Guy's ADK, which is good. BUT, if you use GPG or other safe PGP version to create a Diffie-Hellman key, and some Bad Guy adds an ADK to the your public key and distributes it, people who send messages to you using unsafe versions of PGP will still encrypt to the Bad Guy's ADK if it's on their keyring.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Straight off the Mutt Index Page... but I'll refrain from editorializing:
Using Mutt with PGP/GPG
--
No--a paper signature is meaningful because verification is simultaneous with signing.
Let's say that I want to buy a new car. I go to the car dealership and ask about the rate I'll get from GMAC. The dealer and I quibble, he drafts up a loan agreement, and I sign it as Mordecai McWhirters.
At this point, the car dealer asks me for identification--a lot of identification. If any of these forms of identification fail, then the car dealer is within rights to say "no, you're not really that person; I'm not going to enter into this contract with you". And since my name isn't Moredecai McWhirters and I don't have the technical skills required to forge a passport and driver's license, well... my ID isn't going to check out.
Compare this to a letter that arrives in the emailbox PGP-signed. The return address on the email is billc@whitehouse.gov. You check the key database, and lo and behold, there's a key there for billc@whitehouse.gov. Does that mean you really received an email from Bill Clinton?
No--it means someone signed the email, and you have no idea who. This is why so-called "digital signature laws" scare the bejeezus out of me. Under most of them, if I want to take all the money from your bank account--legally--I just have to register a key in your name, write an email to the bank that's signed with this key authorizing a wire transfer of $10,000 to the First Bank of the Caymans, and then laugh all the way to Aruba. People mistakenly think that digital signatures are a verification of identity: they're not, and that's the biggest difference between digital signatures and real signatures.
Verification of identity is not a part of the current public-key infrastructure. Every single scheme which has been devised to give verification of identity to digital "signatures" is a dismal failure--certificates aren't a good solution, far less the CA+RA model which seems so common nowadays.
Signatures are forgeable, yes... but there's a good reason why people use them to enter legal agreements.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
I use Windows, MacOS, and Unix most every day and I can use PGP with all three so that's what I use. I'd go for GPG if their was a Mac version but last time I checked there wasn't (I can't code so I can't port).
-Fyre
- Apple Computer......proudly going out of business for over twenty years.
Better, but your argument is still asymetrical. Let's do the symmetry work here:
Point 2, inverted: "Let's say I get a letter in my postal mailbox. The printed return address is 'Bill Clinton, White House, Washington D.C.' and the cancel stamp is DC. It's got a signature that looks exactly like the President's." Obviously the signature is not relevant and therefore this is a completed cancellation of point 2, Q E D.
Point 1 is so weak that it doesn't even have to be inverted, since obviously your signature has nothing to do with the authentication process of checking id's, etc. Incidentally this is why important signed documents are always notarized and witnessed.
BTW, your standing point to date reads "signatures are not really signatures", where the first "signatures" means "spewed chunks of unverified identification data" and the second "signatures" means "verified, binding authentication". Note that both meanings of the word can easily be attained with any signature, cryptographic or plaindata.
so we have "spewed chunks of unverified authentication data isn't really a verified authentication" which I can agree with. There is a lesson to be learned here but it has nothing to do with digits or cryptography.
I have seen the future, and it is inconvenient.
GPG looks very cool, but it has one major problem, at least for me - a lack of implementations for us *other* OS users - you know, MacOS? (i guess Windows too, but that doesn't bother _me_ as much :) That may change with OSX, as it might be fudged to compile, but i find it rather annoying that no-one has bothered to write a non-*nix client. So i stick with the less-secure and fewered-features, but at least i get a GUI that works :)
:)
:)
Then again, you don't see me writing any code, so i can't complain too much
-me