home *** CD-ROM | disk | FTP | other *** search
/ linuxmafia.com 2016 / linuxmafia.com.tar / linuxmafia.com / pub / linux / security / pgp50-why-not.txt < prev    next >
Text File  |  2000-05-22  |  14KB  |  287 lines
  1. http://www.shub-internet.org/why_not_pgp_5.html
  2.  
  3.  
  4. ----------------------------------------------------------------------------
  5.  
  6.                               Why Not PGP 5.0?
  7.  
  8. ----------------------------------------------------------------------------
  9.  
  10. Last Changed: Tue Aug 26 19:37:01 EST 1997
  11.  
  12. Since writing this web page, my views have been changed somewhat. I now take
  13. the stance that we should work to get as much strong crypto into as many
  14. hands as quickly as possible, but that we need to be careful how we do it,
  15. lest we cause more problems than we are trying to solve. For a peek at my
  16. current views, see my PGP 5 Tips page, 
  17. http://www.shub-internet.org/pgp_5_tips.html.
  18.  
  19. Nevertheless, many of the issues I raised in this page are still with us
  20. today, and still need to be addressed. I'm just not focussing on fixing them
  21. at the moment, but instead trying to create an atmosphere in which they are
  22. largely avoided by design in the way the tools are used. That doesn't mean
  23. that these problems don't still need to be fixed, however.
  24.  
  25. ----------------------------------------------------------------------------
  26.  
  27. Thirty-Seven Reasons (So Far) Why You Should Wait To Upgrade to, or Use, PGP
  28. 5.0:
  29.  
  30.   1. The freeware version is intentionally crippled -- it can't generate RSA
  31.      keys, only Diffie-Hellman/El Gamal keys:
  32.  
  33.        2. To sign with an RSA key, you have to import an old secret keyring
  34.           with one or more RSA secret keys on it.
  35.  
  36.        3. If you're going to import an RSA key pair and the public key has
  37.           signatures on it other than your own, you should import they
  38.           public key part first, re-assign trust models to it, and then
  39.           import the secret key part. Talk about a PITA.
  40.  
  41.           (See reason #20 as to the reason behind this).
  42.  
  43.        4. If you want a version that can generate RSA keys, you have to pay
  44.           for it and download it separately.
  45.  
  46.        5. Unless you generate your RSA key elsewhere and import it, PGP 5.0
  47.           can't create signatures that are verifiable by older versions of
  48.           PGP.
  49.  
  50.        6. If you use Diffie-Hellman/El Gamal keys, PGP 5.0 puts in a
  51.           "Hash: SHA-1" right after the "---- BEGIN PGP SIGNED MESSAGE ----"
  52.           text that really screws up older versions of PGP.
  53.  
  54.   7. Most MUAs simply check the return code of PGP to see whether the
  55.      message was "decoded" successfully. If PGP gets an error in attempting
  56.      to verify the signature (beyond being unable to find the key), the
  57.      whole message is likely to be considered "undisplayable" by the MUA,
  58.      even if it's just plain ASCII text that has been clearsigned.
  59.  
  60.      You get to go in with some sort of text editor to see if you can read
  61.      the message in question.
  62.  
  63.   8. Support for Unix is minimal/non-existant (completely ignoring the fact
  64.      that virtually all keyservers are running a copy of the software at
  65.      BAL's keyserver, http://pgp5.ai.mit.edu, under Unix):
  66.  
  67.        9. There is no non-beta Unix version of PGP 5.0 yet (source or
  68.           binary).
  69.  
  70.       10. The only Unix version (beta or not) of PGP 5.0 (US version)
  71.           available so far is a Linux/Intel binary version (Beta 11, expires
  72.           September 23, 1997).
  73.  
  74.       11. The only source-code available for Unix is the PGP 5.0i Beta 8
  75.           (international) version, which is not legal for use in the US
  76.           unless you link it with the RSAREF libraries (non-exportable; only
  77.           method approved by the holder of the patent, which is enforcable
  78.           only in the US).
  79.  
  80.           Of course, virtually no one will link PGP 5.0i with RSAREF, so it
  81.           would then be illegal to use in the US.
  82.  
  83.       12. Worse, this source code only seems to compile under Linux/Intel
  84.           and *BSD for Intel.
  85.  
  86.           Fixes for known bugs under PGP 5.0ib8 have been posted at
  87.           http://www.ifi.uio.no/pgp/bugs50i.shtml, but I haven't been able
  88.           to confirm that these patches actually work. Other fixes have been
  89.           reported to me privately that appear to also make the code work
  90.           under certain OSes, but none of these patches appear to have been
  91.           incorporated back into a new distribution.
  92.  
  93.           Apparently, on some platforms, the code will compile with
  94.           platform-native compilers from the respective vendor, but not with
  95.           gcc. If PGP 5.0ib8 won't compile on many platforms with gcc,
  96.           there's something fundamentally wrong, since gcc is basically the
  97.           Internet de-facto standard C compiler these days.
  98.  
  99.  13. It really screws up the keyservers (e.g., BAL's keyserver at MIT has
  100.      had no end of heartburn ever since it came out).
  101.  
  102.  14. Key management with PGP 5.0 is a PITA. There's no way to get mass
  103.      quantities of known keys from the keyservers, including "get me all the
  104.      unknown keys that have signed this key".
  105.  
  106.       15. If you do formulate a query that results in a number of keys being
  107.           matched, you can only download so many of them -- PGP 5.0 will
  108.           refuse to download more than a certain number.
  109.  
  110.       16. They had to design their own protocol to handle querying for and
  111.           retrieving keys (HKP -- Horowitz Key Protocol). Why couldn't they
  112.           have just used a minimal version of HTTP? Now there's yet another
  113.           port (11371) we've got to secure on our firewalls....
  114.  
  115.       17. After having selected all keys and performed some operation on
  116.           them, there's no way to deselect all highlighted keys, short of
  117.           expanding one key then collapsing it.
  118.  
  119.       18. Being unable to get more than one key at a time also means that
  120.           you can't update multiple known keys.
  121.  
  122.       19. You can't have both primary and alternate keyrings (at least, you
  123.           can't have two keyrings on the Macintosh product, although it's
  124.           not yet clear as to whether this is possible under Windows 95, for
  125.           example).
  126.  
  127.       20. Exporting/importing an entire keyring loses trust relationships.
  128.  
  129.  21. There doesn't appear to be any way to set portable default
  130.      configuration options, as was possible with PGP 2.6.2 and CONFIG.TXT.
  131.  
  132.  22. From what I can tell, the names of programs you run and the options you
  133.      give them have changed pretty radically (e.g., all key management is
  134.      done with the pgpk program). This makes it much harder to integrate
  135.      with MUAs that already work with PGP 2.6.2.
  136.  
  137.  23. When installed under Linux/Intel, PGP 5.0 appears to cause problems
  138.      verifying the PGP signature of rpm's that have been signed by your
  139.      vendor with PGP 2.6.x, even though the vendor's key is on your keyring.
  140.  
  141.  24. PGP 5.0 appears to be incompatible with Microsoft Outlook. It seems to
  142.      chop off the tail-ends of some messages.
  143.  
  144.  25. PGP 5.0 appears to be generating keys without requiring any input from
  145.      the keyboard. How do you generate any amount of valid "randomness"
  146.      without requiring input from the keyboard, and measuring the small
  147.      amount of time differences between each keypress?!?
  148.  
  149.           Apparently, on the Mac (and presumably on Win95), PGP 5.0 is using
  150.           mouse timings instead of keyboard timings as random input for
  151.           generating keys. Under Linux, it's supposedly using /dev/random,
  152.           which takes it's input from keyboard timings, mouse timings,
  153.           interrupt timings, and block request timings.
  154.  
  155.           If/when I can confirm these statements with someone whom I know
  156.           can speak authoritatively (e.g., Phil Zimmerman, Staale
  157.           Schumacher, etc...), this item will be removed.
  158.  
  159.  26. There is serious question (in my mind, at least) as to whether PGP 5.0
  160.      is as secure as older versions. Specifically, Diffie-Hellman is known
  161.      to have weaknesses in the initial key exchange, which may not be
  162.      addressed by the El Gamal variant.
  163.  
  164.      See http://www.rsa.com/rsalabs/newfaq/q29.html for some more
  165.      information on El Gamal and http://www.rsa.com/rsalabs/newfaq/q24.html
  166.      for more information on Diffie-Hellman (yes, I know, RSA Labs probably
  167.      isn't a very impartial observer to be commenting on the weaknesses in
  168.      El Gamal and Diffie-Hellman).
  169.  
  170.      However, when PGP, Inc. replaced RSA with Diffie-Hellman/El Gamal, they
  171.      also replaced the signature method from older versions of PGP with DSS.
  172.      Only Ghu (or the US federal government) knows why.
  173.  
  174.      They also replaced the MD5 hashing scheme with SHA-1. In and of itself,
  175.      this is a win, because MD5 has recently been proven to have serious
  176.      weakness of it's own (see RSA Security Bulletin 4, in Adobe Acrobat
  177.      format, ftp://ftp.rsa.com/pub/pdfs/bulletn4.pdf). However, they don't 
  178.      incorporate SHA-1 in a method that is compatible with older versions 
  179.      of PGP.
  180.  
  181.  27. When using PGP 5.0 to send a message that is signed and/or encrypted to
  182.      recipients, some of which have PGP 5.0 and some of which who don't, you
  183.      have to send the message in two parts -- using RSA only for those
  184.      recipients using the older version, and Diffie-Hellman/El Gamal or RSA
  185.      as appropriate for those who have PGP 5.0.
  186.  
  187.      Otherwise, the non-PGP 5.0 recipients get a message they can't verify
  188.      (or read, if it was encrypted), because they'll get the error:
  189.  
  190.           Unsupported packet format - you need a newer version of PGP for
  191.           this file.
  192.  
  193.  28. They left out a couple of options that many people used frequently:
  194.  
  195.         o No conventional encryption (pgp -c)
  196.         o No wipe option (pgp -w)
  197.  
  198.  29. You can't change the number of marginally trusted keys that have signed
  199.      another key, in order for you to consider it "trusted".
  200.  
  201.      Speaking for myself, no one is fully trusted. Those that I trust, I
  202.      trust them marginally (even my best friends), and even then I boost the
  203.      number of marginals needed before I'll consider a key trusted.
  204.  
  205.  30. The "PGPMenu" application appears to conflict with MacOS 8. So, if
  206.      you've got any friends that would need to upgrade to PGP 5.0 to talk to
  207.      you, and they're using Macintoshes with MacOS 8 installed, they can't
  208.      do that.
  209.  
  210.  31. When verifying signatures, if the key isn't on your keyring, PGP 5.0
  211.      will simply tell you the operation "failed", and not give you
  212.      additional information like what keyid it was that it couldn't find,
  213.      etc....
  214.  
  215.      Therefore, you're probably going to be stuck -- unable to verify the
  216.      message because you don't have the necessary public key, but unable to
  217.      go get the public key you need because PGP 5.0 won't tell you which key
  218.      it couldn't find.
  219.  
  220.  32. When you buy PGP 5.0 online, the only manual you get is in Adobe
  221.      Acrobat (.PDF) form. This makes it a major pain in the tuccus to read,
  222.      search, etc.... Why not give us a ASCII text version as well? It's not
  223.      like the distribution isn't already about ten times as large as the
  224.      previous one.... See reason #37.
  225.  
  226.  33. PGP 5.0 is not available for MS-DOS or Microsoft Windows platforms.
  227.  
  228.      This isn't a problem, unless you want to send a PGP signed and/or
  229.      encrypted message to someone using one of the millions of PCs that are
  230.      out there (but who hasn't upgraded to Windows 95), and you're using PGP
  231.      5.0.
  232.  
  233.      Alternatively, if you have only MS-DOS or Microsoft Windows and you
  234.      want to upgrade to PGP 5.0, you can't. Given the various compatibility
  235.      problems with PGP 5.0 and older versions, the obvious solution of "give
  236.      everyone PGP 5.0" simply doesn't work.
  237.  
  238.  34. PGP 5.0 can't export secret keys from the GUI. If you have command-line
  239.      access to PGP 5.0 (currently, this only seems to be true for PGP 5.0
  240.      for Unix), you can make use of an undocumented command-line option.
  241.  
  242.  35. When you use PGP/MIME with PGP 5.0, it waits until the time you
  243.      actually go to transmit the message, before it processes it through PGP
  244.      5.0 and signs and/or encrypts it.
  245.  
  246.      Although a good option to have, this can waste your time online and
  247.      perhaps cause your connection to time-out (as you wait for PGP 5.0 to
  248.      get done signing/encrypting the next message before you can actually
  249.      transmit it), and it is a security risk -- do you want
  250.      unsigned/unencrypted versions of some of your messages just sitting
  251.      around until it's time to actually send them?
  252.  
  253.      Why not sign/ecnrypt at the time you are done with the message and you
  254.      queue it for later delivery? Unfortunately, your only option to do it
  255.      this way with PGP 5.0 is to "manually" sign/encrypt the message, then
  256.      pull that into your MUA. This kind of defeats the purpose of PGP 5.0,
  257.      doesn't it?!?
  258.  
  259.  36. PGP/MIME is a Good Thing[Image], but it's not yet a well-supported
  260.      standard, and there are some known protocol fragilities with trailing
  261.      whitespace, which frequently gets stripped by common mailing list
  262.      manager software (e.g., Listserv, unless you've got "Translate=No" set
  263.      for the particular list in question), legacy SMTP MTAs and gateways,
  264.      etc..., which would cause the signature/encryption to be corrupted.
  265.  
  266.      I'm not convinced that PGP 5.0 should default to using PGP/MIME.
  267.  
  268.  37. PGP 5.0 is huge. The distribution is easily ten times the size of the
  269.      PGP 2.6.x distribution, and the code itself is likewise huge (something
  270.      like 3MB combined for pgpk and pgpe put together), versus 200-400KB for
  271.      PGP 2.6.x (depending on your hardware/OS).
  272.  
  273.      You're not going to convince me that this order of magnitude increase
  274.      in the size of the binary and distribution is necessary. PGP, Inc has
  275.      been unfavourably compared as being worse than the combination of both
  276.      Microsoft and Netscape, when it comes to bloatware.
  277.  
  278. Many thanks to the posters of comp.security.pgp.discuss for some of the
  279. above items.
  280.  
  281. I'll do my best to keep this list accurate and up-to-date, but I need
  282. feedback and input from other folks to help do that.
  283.  
  284. ----------------------------------------------------------------------------
  285.                 If you have any comments, please email me at
  286.                                 brad@his.com
  287.