Nobody writes:
My only concern would be whether the implementation of longer keys might possibly "push the envelope" of the math routines used, and thus introduce subtle, hidden weaknesses. Two examples might be an RNG that became non-random with larger numbers, or a primality tester that failed to detect larger non-primes. If you have evidence for any of those scenarios, I'd love to hear it. Personally, I'm staying with PGP 2.3a until the dust settles a bit. I've FTPed the RSAREF 2.6 release, and it remains in its zipped archive for now.
I'd like to see PGP eventually remove artifical constraints on key sizes. The MP package in PGP uses fixed-size buffers, but a more general approach using variable-sized buffers is used in other packages such as gmp. These do not force you to use compiled-in limits on sizes like this. The basic multi-precision integer data structure in PGP does have a limit of 64K bits but that is probably not worth changing. Remember that it is the owner of a long key who pays most of the price of using it. He is the one who has to wait through lengthy signs and decrypts. The signature-checking and encryption which other people do just involve a few multiplications and should be pretty fast even for sizable keys. So I don't see any reason PGP should take this decision out of people's hands.
Just as an aside, can some of the PGP-aware-anon-remailer operators comment on what they plan to do with respect to the various PGP versions?
I'm still running 2.3. I figure that when the time comes I'll hack it to accept 2.6 messages. Hal