PGP 2.5: Mini-review

[schirado@lab.cc.wmich.edu (Schirado)]

Having not seen any activity on the list for the last week or so (I hope
everyone's busy writing code!), I figured I'd simultaneously check to see
if the list still existed, and share some interesting excerpts from
NEWFOR25.DOC, from the PGP 2.5 MIT-legit package.

PGP 2.5 is apparently still written by Phil Zimmermann - at least, it
purports to be - which in itself is a considerable relief to those of us
who had no idea who was responsible. The source code is also available,
as before, and I'm sure programmers the world over are even now poring
through it in minute detail, looking for backdoors and such. I also
expect we'll be hearing from them relatively soon, to tell us of the
presence or absence of any suspicious code.

Not being a programmer myself, I can only comment on a few aspects.
First, there is this:

[...]

>[An] RSAREF limitation is that it cannot cope with keys longer than
>1024 bits.  PGP now prints a reasonably polite error message in such a
>case.

I recall someone mentioning at one point that increasing the size of a
key beyond 1024 bits did not justify the increased computing time, but I
do not recall the reason why. I believe the reasoning was not that it
offered no additional security, but rather, that it was already difficult
enough to crack 1K keys, and if you're really that worried about security,
you should be tightening up in other areas, such as deciding who to trust
and who not to, deciding what information to enter into the computer and
what to keep in your head, or maybe making a homemade TEMPEST shield. :)
I'd still like to see the math explained a little better, though.

Also, has anyone found those references to elliptic-curve crypto? The
original article is _An Implementation of Elliptic Curve Cryptosystems
Over F-2-155_ , IEEE Journal on Selected Areas in Communications, Vol.
11, #5, June 1993 (page 804). (Schneier mentions that Next Computer's
Fast Elliptic Encryption, FEE, uses elliptic curves, and is patented by
R E Crandell, USP# 5,159,632,27 October 1992.) Also, look for works by
Neal Koblitz.



>Printed keyIDs have been incresed to 32 bits, as there were enough keys
>out there that 24-bit keyIDs were no longer sufficiently unique.  The
>previous 24-bit keyID is the LAST 6 digits of an 8-digit 32-bit keyID.
>For example, what was printed as A966DD now appears as C7A966DD.

So even though the keyservers only have 5,000 or so registered users,
there are enough people out there using PGP and NOT registering their
keys with the servers that this extra bit of coding was necessary? Hmm.
24 bits gives us 16,777,216 unique ID's. 32 bits gives us 4,294,967,296.
Are there really over 17 million PGP'ers out there, or is my math-impaired
brain missing something painfully obvious?


>PGP now enables clearsig by default.  If you sign and ascii-armor a
>text file, and do not encrypt it, it is clearsigned unless you ask
>for this not to be done.

Which would seem to indicate that PGP is mainly being used for e-mail!
Goody!


>[...]
>
>PGP now wipes temp files (and files wiped with pgp -w) with pseudo-random
>data in an attempt to force disk compressors to overwrite as much data as
>possible.
>
>[...]
>
>The normal help files (pgp -h) are pgp.hlp or <language>.hlp, such as
>fr.hlp.  Now, there is a separate help file for pgp -k, called pgpkey.hlp,
>or <language>key.hlp.  No file is provided by default; PGP will use
>its one-page internal help by default, but you can create such a file
>at your site.
>
>PGP used to get confused if you had a keyring containing signatures from
>you, but not your public key.  (PGP can't use the signatures in this case.
>Only signatures from keys in the keyring are counted.) PGP still can't use
>the signatures, but prints better warning messages. Also, adding a key on
>your secret key ring to your public keyring now asks if the key should be
>considered ultimately-trusted. Prviously, you had to run pgp -ke to force
>this check, which was non-obvious.
>
>[...]
>
>On Unix, PGP now figures out the resolution of the system clock at run
>time for the purpose of computing the amount of entropy in keystroke
>timings.  This means that on many Unix machines, less typing should be
>required to generate keys.  (SunOS and Linux especially.)
>
>The small prime table used in generating keys has been enlarged, which
>should speed up key generation somewhat.
>
>There was a bug in PGP 2.3a (and, in fact in 2.4 and dating back to 1.0!)
>when generating primes 2 bits over a multiple of the unit size (16 bits
>on PC's, 32 bits on most larger computers), if the processor doesn't deal
>with expressions like "1<<32" by producing a result of 1.  In practice,
>that corresponds to a key size of 64*x+4 bits.
>
>Code changes:
>
>At the request of Windows programmers, the PSTR() macro used to translate
>string has been renamed to LANG().
>
>The random-number code has been *thoroughly* cleaned up.  So has the
>IDEA code and the MD5 code.  The MD5 code was developed from scratch and
>is available for public use.


So, all in all, PGP 2.5 would seem to be more than just a possible
conspiracy by MIT/RSA/et. al., and more than just minor bug fixes that
most people wouldn't care about. With the possible exceptions of the size
limitations on keys, and whatever arcane pieces have been hacked out of
the RSA code to comply with whatever demands they may have made, PGP 2.5
appears to be a legitimate upgrade, with more than a few bugfixes, both
major and minor, as well as the all-important improved security (as far
as can be seen).

Comments?


--
schirado@lab.cc.wmich.edu          [O|o]bjectivist, Evil Capitalist(tm;-),
 s..O).... You hit the smurf! --More--         male, lesbian, polyamorous,
 @.../.".. You destroy the smurf! --More--    reader, atheist, Discordian,
 $$*...].. You feel cynical!         free and natural sovereign individual
the Frog Farm: e-mail frog-farm-request@blizzard.lcs.mit.edu (PGP available)