Why Not PGP 5.0?

Last Changed: Tue Aug 26 19:37:01 EST 1997

Since writing this web page, my views have been changed somewhat. I now take the stance that we should work to get as much strong crypto into as many hands as quickly as possible, but that we need to be careful how we do it, lest we cause more problems than we are trying to solve. For a peek at my current views, see my PGP 5 Tips page.

Nevertheless, many of the issues I raised in this page are still with us today, and still need to be addressed. I'm just not focussing on fixing them at the moment, but instead trying to create an atmosphere in which they are largely avoided by design in the way the tools are used. That doesn't mean that these problems don't still need to be fixed, however.


Thirty-Seven Reasons (So Far) Why You Should Wait To Upgrade to, or Use, PGP 5.0:

  1. The freeware version is intentionally crippled -- it can't generate RSA keys, only Diffie-Hellman/El Gamal keys:

    1. To sign with an RSA key, you have to import an old secret keyring with one or more RSA secret keys on it.

    2. If you're going to import an RSA key pair and the public key has signatures on it other than your own, you should import they public key part first, re-assign trust models to it, and then import the secret key part. Talk about a PITA.

      (See reason #20 as to the reason behind this).

    3. If you want a version that can generate RSA keys, you have to pay for it and download it separately.

    4. Unless you generate your RSA key elsewhere and import it, PGP 5.0 can't create signatures that are verifiable by older versions of PGP.

    5. If you use Diffie-Hellman/El Gamal keys, PGP 5.0 puts in a "Hash: SHA-1" right after the "---- BEGIN PGP SIGNED MESSAGE ----" text that really screws up older versions of PGP.

  1. Most MUAs simply check the return code of PGP to see whether the message was "decoded" successfully. If PGP gets an error in attempting to verify the signature (beyond being unable to find the key), the whole message is likely to be considered "undisplayable" by the MUA, even if it's just plain ASCII text that has been clearsigned.

    You get to go in with some sort of text editor to see if you can read the message in question.

  2. Support for Unix is minimal/non-existant (completely ignoring the fact that virtually all keyservers are running a copy of the software at BAL's keyserver, under Unix):

    1. There is no non-beta Unix version of PGP 5.0 yet (source or binary).

    2. The only Unix version (beta or not) of PGP 5.0 (US version) available so far is a Linux/Intel binary version (Beta 11, expires September 23, 1997).

    3. The only source-code available for Unix is the PGP 5.0i Beta 8 (international) version, which is not legal for use in the US unless you link it with the RSAREF libraries (non-exportable; only method approved by the holder of the patent, which is enforcable only in the US).

      Of course, virtually no one will link PGP 5.0i with RSAREF, so it would then be illegal to use in the US.

    4. Worse, this source code only seems to compile under Linux/Intel and *BSD for Intel.

      Fixes for known bugs under PGP 5.0ib8 have been posted at http://www.ifi.uio.no/pgp/bugs50i.shtml, but I haven't been able to confirm that these patches actually work. Other fixes have been reported to me privately that appear to also make the code work under certain OSes, but none of these patches appear to have been incorporated back into a new distribution.

      Apparently, on some platforms, the code will compile with platform-native compilers from the respective vendor, but not with gcc. If PGP 5.0ib8 won't compile on many platforms with gcc, there's something fundamentally wrong, since gcc is basically the Internet de-facto standard C compiler these days.

  1. It really screws up the keyservers (e.g., BAL's keyserver at MIT has had no end of heartburn ever since it came out).

  2. Key management with PGP 5.0 is a PITA. There's no way to get mass quantities of known keys from the keyservers, including "get me all the unknown keys that have signed this key".

    1. If you do formulate a query that results in a number of keys being matched, you can only download so many of them -- PGP 5.0 will refuse to download more than a certain number.

    2. They had to design their own protocol to handle querying for and retrieving keys (HKP -- Horowitz Key Protocol). Why couldn't they have just used a minimal version of HTTP? Now there's yet another port (11371) we've got to secure on our firewalls....

    3. After having selected all keys and performed some operation on them, there's no way to deselect all highlighted keys, short of expanding one key then collapsing it.

    4. Being unable to get more than one key at a time also means that you can't update multiple known keys.

    5. You can't have both primary and alternate keyrings (at least, you can't have two keyrings on the Macintosh product, although it's not yet clear as to whether this is possible under Windows 95, for example).

    6. Exporting/importing an entire keyring loses trust relationships.

  1. There doesn't appear to be any way to set portable default configuration options, as was possible with PGP 2.6.2 and CONFIG.TXT.

  2. From what I can tell, the names of programs you run and the options you give them have changed pretty radically (e.g., all key management is done with the pgpk program). This makes it much harder to integrate with MUAs that already work with PGP 2.6.2.

  3. When installed under Linux/Intel, PGP 5.0 appears to cause problems verifying the PGP signature of rpm's that have been signed by your vendor with PGP 2.6.x, even though the vendor's key is on your keyring.

  4. PGP 5.0 appears to be incompatible with Microsoft Outlook. It seems to chop off the tail-ends of some messages.

  5. PGP 5.0 appears to be generating keys without requiring any input from the keyboard. How do you generate any amount of valid "randomness" without requiring input from the keyboard, and measuring the small amount of time differences between each keypress?!?

      Apparently, on the Mac (and presumably on Win95), PGP 5.0 is using mouse timings instead of keyboard timings as random input for generating keys. Under Linux, it's supposedly using /dev/random, which takes it's input from keyboard timings, mouse timings, interrupt timings, and block request timings.

      If/when I can confirm these statements with someone whom I know can speak authoritatively (e.g., Phil Zimmerman, Staale Schumacher, etc...), this item will be removed.

  6. There is serious question (in my mind, at least) as to whether PGP 5.0 is as secure as older versions. Specifically, Diffie-Hellman is known to have weaknesses in the initial key exchange, which may not be addressed by the El Gamal variant.

    See     http://www.rsa.com/rsalabs/newfaq/q29.html for some more information on El Gamal and http://www.rsa.com/rsalabs/newfaq/q24.html for more information on Diffie-Hellman (yes, I know, RSA Labs probably isn't a very impartial observer to be commenting on the weaknesses in El Gamal and Diffie-Hellman).

    However, when PGP, Inc. replaced RSA with Diffie-Hellman/El Gamal, they also replaced the signature method from older versions of PGP with DSS. Only Ghu (or the US federal government) knows why.

    They also replaced the MD5 hashing scheme with SHA-1. In and of itself, this is a win, because MD5 has recently been proven to have serious weakness of it's own (see RSA Security Bulletin 4, in Adobe Acrobat format). However, they don't incorporate SHA-1 in a method that is compatible with older versions of PGP.

  7. When using PGP 5.0 to send a message that is signed and/or encrypted to recipients, some of which have PGP 5.0 and some of which who don't, you have to send the message in two parts -- using RSA only for those recipients using the older version, and Diffie-Hellman/El Gamal or RSA as appropriate for those who have PGP 5.0.

    Otherwise, the non-PGP 5.0 recipients get a message they can't verify (or read, if it was encrypted), because they'll get the error:
  8. They left out a couple of options that many people used frequently:
  9. You can't change the number of marginally trusted keys that have signed another key, in order for you to consider it "trusted".

    Speaking for myself, no one is fully trusted. Those that I trust, I trust them marginally (even my best friends), and even then I boost the number of marginals needed before I'll consider a key trusted.

  10. The "PGPMenu" application appears to conflict with MacOS 8. So, if you've got any friends that would need to upgrade to PGP 5.0 to talk to you, and they're using Macintoshes with MacOS 8 installed, they can't do that.

  11. When verifying signatures, if the key isn't on your keyring, PGP 5.0 will simply tell you the operation "failed", and not give you additional information like what keyid it was that it couldn't find, etc....

    Therefore, you're probably going to be stuck -- unable to verify the message because you don't have the necessary public key, but unable to go get the public key you need because PGP 5.0 won't tell you which key it couldn't find.

  12. When you buy PGP 5.0 online, the only manual you get is in Adobe Acrobat (.PDF) form. This makes it a major pain in the tuccus to read, search, etc.... Why not give us a ASCII text version as well? It's not like the distribution isn't already about ten times as large as the previous one.... See reason #37.

  13. PGP 5.0 is not available for MS-DOS or Microsoft Windows platforms.

    This isn't a problem, unless you want to send a PGP signed and/or encrypted message to someone using one of the millions of PCs that are out there (but who hasn't upgraded to Windows 95), and you're using PGP 5.0.

    Alternatively, if you have only MS-DOS or Microsoft Windows and you want to upgrade to PGP 5.0, you can't. Given the various compatibility problems with PGP 5.0 and older versions, the obvious solution of "give everyone PGP 5.0" simply doesn't work.

  14. PGP 5.0 can't export secret keys from the GUI. If you have command-line access to PGP 5.0 (currently, this only seems to be true for PGP 5.0 for Unix), you can make use of an undocumented command-line option.

  15. When you use PGP/MIME with PGP 5.0, it waits until the time you actually go to transmit the message, before it processes it through PGP 5.0 and signs and/or encrypts it.

    Although a good option to have, this can waste your time online and perhaps cause your connection to time-out (as you wait for PGP 5.0 to get done signing/encrypting the next message before you can actually transmit it), and it is a security risk -- do you want unsigned/unencrypted versions of some of your messages just sitting around until it's time to actually send them?

    Why not sign/ecnrypt at the time you are done with the message and you queue it for later delivery? Unfortunately, your only option to do it this way with PGP 5.0 is to "manually" sign/encrypt the message, then pull that into your MUA. This kind of defeats the purpose of PGP 5.0, doesn't it?!?

  16. PGP/MIME is a Good Thing, but it's not yet a well-supported standard, and there are some known protocol fragilities with trailing whitespace, which frequently gets stripped by common mailing list manager software (e.g., Listserv, unless you've got "Translate=No" set for the particular list in question), legacy SMTP MTAs and gateways, etc..., which would cause the signature/encryption to be corrupted.

    I'm not convinced that PGP 5.0 should default to using PGP/MIME.

  17. PGP 5.0 is huge. The distribution is easily ten times the size of the PGP 2.6.x distribution, and the code itself is likewise huge (something like 3MB combined for pgpk and pgpe put together), versus 200-400KB for PGP 2.6.x (depending on your hardware/OS).

    You're not going to convince me that this order of magnitude increase in the size of the binary and distribution is necessary. PGP, Inc has been unfavourably compared as being worse than the combination of both Microsoft and Netscape, when it comes to bloatware.



Many thanks to the posters of comp.security.pgp.discuss for some of the above items.

I'll do my best to keep this list accurate and up-to-date, but I need feedback and input from other folks to help do that.

If you have any comments, please email me at
brad@his.com