http://www.shub-internet.org/why_not_pgp_5.html
----------------------------------------------------------------------------
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,
http://www.shub-internet.org/pgp_5_tips.html.
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:
2. To sign with an RSA key, you have to import an old secret keyring
with one or more RSA secret keys on it.
3. 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).
4. If you want a version that can generate RSA keys, you have to pay
for it and download it separately.
5. 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.
6. 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.
7. 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.
8. 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, http://pgp5.ai.mit.edu, under Unix):
9. There is no non-beta Unix version of PGP 5.0 yet (source or
binary).
10. 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).
11. 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.
12. 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.
13. It really screws up the keyservers (e.g., BAL's keyserver at MIT has
had no end of heartburn ever since it came out).
14. 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".
15. 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.
16. 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....
17. 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.
18. Being unable to get more than one key at a time also means that
you can't update multiple known keys.
19. 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).
20. Exporting/importing an entire keyring loses trust relationships.
21. 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.
22. 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.
23. 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.
24. PGP 5.0 appears to be incompatible with Microsoft Outlook. It seems to
chop off the tail-ends of some messages.
25. 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.
26. 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, ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf). However, they don't
incorporate SHA-1 in a method that is compatible with older versions
of PGP.
27. 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:
Unsupported packet format - you need a newer version of PGP for
this file.
28. They left out a couple of options that many people used frequently:
o No conventional encryption (pgp -c)
o No wipe option (pgp -w)
29. 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.
30. 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.
31. 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.
32. 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.
33. 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.
34. 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.
35. 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?!?
36. PGP/MIME is a Good Thing[Image], 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.
37. 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