[I sent this out before I learned of the Great List Crash, so I'm resending it now.] 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)