// COMPLETE THREAD

RE: WARNING!

4 expanded posts ยท every known parent and child

NODE 4caa2cc4RE: WARNING!
+++++++++++++++++++++++++++++++++

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?

++++++++++++++++++++++
NODE a54fd675Re: WARNING!
-----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-----
NODE 09026700Re: WARNING!
"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.
NODE 0ddf3d18Re: WARNING!
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