+++++++++++++++++++++++++++++++++ dcosenza@netcom.com wrote:
I spoke with Phil Zimmermann today at some length, and he has informed me that users who decide to use the jumo keys generated by the hack of 2.6ui will be running a risk of incompatibility on down the line with future releases he has planned. You have been warned!
Ever forward,
Doesn't part of "ever forward" sometimes involve something "non-standard" and "running the risk of incompatibility"? Unless there's something flawed with the implementation of longer keys, why shouldn't the first to implement them become the de-facto standard? If a leter release turns out to be incompatible with an older one, but it's cryptographically superior, then it's time to switch, even if it means generating and distributing new keys. Anyone concerned enough about security to want the "latest and greatest" crypto package, with longer/stronger keys or whatever, should already be practicing good key management and generating new keys periodically, anyway. 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. 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? ++++++++++++++++++++++
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
-----BEGIN PGP SIGNED MESSAGE-----
them become the de-facto standard? If a leter release turns out to be incompatible with an older one, but it's cryptographically superior, then it's time to switch, even if it means generating and distributing new keys.
And it is superior indeed... But what are we talking about here. A 1024 bits key should be save for at least the next 10000 years so who cares if a 5000 bits key could be save for maybe a 1000000 years!!! If the big keys are going to be used PGP will be taken away from user that not can use very fast machines... ... If you outlaw Privacy, only Outlaws will have Privacy! Eelco Cramer <crame001@hio.tem.nhl.nl> ------ - -------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: 2.6 iQCVAgUBLgqd64DAdPKe9hHLAQHtPQP9FERBDECwHTeexO3IL1hwTh4qeG+aKnpw +HjGBq2H2C/2ypk0FvRWayOUn75uR/zIHXz33+0a3HzDgu/tlY6luL2L4joKPQHu muA7qmHVN9KjHYR31GEEsneM2Q/QGJ9yv/yIxz4A5Xe5JIiZ3FCrMmzRFTrTjZrX LlE8eSS2r7c= =xBxZ -----END PGP SIGNATURE-----
"ER CRAMER" wrote:
them become the de-facto standard? If a leter release turns out to be incompatible with an older one, but it's cryptographically superior, then it's time to switch, even if it means generating and distributing new keys.
And it is superior indeed... But what are we talking about here. A 1024 bits key should be save for at least the next 10000 years so who cares if a 5000 bits key could be save for maybe a 1000000 years!!!
And if a near polynomial time method is developed for factoring or breaking RSA (or any other PKCS you care to mention), super large keys aren't going to matter a hoot. Anyway, it's a subjective choice if you decide to use super large keys, I don't think people should be flamed for making that choice. Sure, point out to them the fact that it doesn't really give any extra security, but it makes some people _feel_ secure, so let them be. Some people waste money protecting themselves against things that are statistically less likely to happen than things they don't protect themselves against, but it makes them happy. If people want to choose large key sizes that aren't supported by software, then they're the ones that suffer the most, by way of decreased audience. If enough people use super large keys, then maybe software developers will come around to supporting them -- market forces and all that. It's kind of funny to see bickering over bigger keys, I thought cypherpunks would be happy with people demanding or wanting bigger keys :-). What's important is that people are deciding not to use smaller keys and they're realising the need and requirements for strong crypto through bigger keys. Big is good, Bigger is good, Smaller is doubleplus ungood :-) cheers, Matthew. -- Matthew Gream <M.Gream@uts.edu.au> -- Consent Technologies, (02) 821-2043 Disclaimer: I'm only a student at UTS, and don't represent them.
participants (4)
-
ER CRAMER -
Hal -
mgream＠acacia.itd.uts.edu.au -
nobody＠ds1.wu-wien.ac.at