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:
- The freeware version is intentionally crippled -- it can't
generate RSA keys, only Diffie-Hellman/El Gamal keys:
- To sign with an RSA key, you have to import an old secret
keyring with one or more RSA secret keys on it.
- 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
(See reason #20 as to the reason behind this).
- If you want a version that can generate
RSA keys, you have to pay for it and download it
- 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.
- 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.
- 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.
- 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
- There is no non-beta Unix version of PGP 5.0 yet
(source or binary).
- 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).
- 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.
- 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
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.
- It really screws up the keyservers (e.g., BAL's keyserver at MIT
has had no end of heartburn ever since it came out).
- 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
- 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
- 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....
- 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.
- Being unable to get more than one key at a time also means
that you can't update multiple known keys.
- 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).
- Exporting/importing an entire keyring loses trust relationships.
- There doesn't appear to be any way to set portable default
configuration options, as was possible with PGP 2.6.2 and
- 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.
- 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.
- PGP 5.0 appears to be incompatible with Microsoft Outlook. It
seems to chop off the tail-ends of some messages.
- 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
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
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.
- 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
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.
- 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
Unsupported packet format - you need a newer version of PGP
for this file.
- They left out a couple of options that many people used
- No conventional encryption (pgp -c)
- No wipe option (pgp -w)
- You can't change the number of marginally trusted keys that
have signed another key, in order for you to consider it
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.
- 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.
- 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.
- 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.
- PGP 5.0 is not available for MS-DOS or Microsoft Windows
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.
- 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.
- 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,
- 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 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