Re: Photuris Primality verification needed

>I don't know.  Maybe the right thing to do is require conforming
>implementations to support a large modulus but include recommended
>smaller moduli.  Then Alice can always force Bob to use the large
>modulus but, if both agree, they can use something smaller from the
>standard or even their own home-grown modulus.

Thanks. That's pretty much what we are doing -- requiring a particular
1024-bit modulus but recommending several others as options. There's a
2048 bit optional modulus and may even be a 4096-bit option if I can
find one in reasonable time. There was going to be a 512-bit optional
modulus but the group has reacted so strongly to it that I'm willing to
withdraw it.

Phil

You might want to offer a number of strong moduli in the 1024-1500 bit
range.  Having multiple strong moduli in the same size (speed) range
reduces the value of going after a particular one.  We all know how
security software tends to stay deployed longer than it really should.

Adam

Phil Karn wrote:

| Thanks. That's pretty much what we are doing -- requiring a particular
| 1024-bit modulus but recommending several others as options. There's a
| 2048 bit optional modulus and may even be a 4096-bit option if I can
| find one in reasonable time. There was going to be a 512-bit optional
| modulus but the group has reacted so strongly to it that I'm willing to
| withdraw it.

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume

>You might want to offer a number of strong moduli in the 1024-1500 bit
>range.  Having multiple strong moduli in the same size (speed) range

We already have a secondary 1024-bit modulus in the spec. The question is
whether the problem is better solved by allowing parties to use private
moduli rather than by filling up the spec with additional moduli. Remember
that the original reason for specifying a particular modulus as "required"
is to guarantee some minimum degree of interoperability, not to meet every
possible threat.

Phil

Phil Karn writes:
> >I don't know.  Maybe the right thing to do is require conforming
> >implementations to support a large modulus but include recommended
> >smaller moduli.  Then Alice can always force Bob to use the large
> >modulus but, if both agree, they can use something smaller from the
> >standard or even their own home-grown modulus.
> 
> Thanks. That's pretty much what we are doing -- requiring a particular
> 1024-bit modulus but recommending several others as options.

I think Brian is also suggesting that it would be good if people could
negotiate new and previously unheard of modulii if they wanted to.

Perry

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Phil" == Phil Karn <karn@qualcomm.com> writes:

    Phil> as options. There's a 2048 bit optional modulus and may even
    Phil> be a 4096-bit option if I can find one in reasonable
    Phil> time. There was going to be a 512-bit optional modulus but

I'd like to see the 4096 bit modulus. Let me know if I can help you by
donating computation power. We have a SGI Onyx with 4 processors and
several smaller SGI computers.

Andreas


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBMKIUdEyjTSyISdw9AQGEawP9FUG9X5t8n/w0BRcWVTPv6LeERgY78WHc
mBNG4ScvbRZK6o4ZoQuEr10v4eDqKQtHD3lkdV5HJO2+oBrNkLOLKyVR8sr0Yh+3
wKyOeF8BUKqwILteJGT8UQnznFnHha0m9HxlHOIUrx6SOGIMc6t6N4DFCRzOis0h
dc0pgYN2S/Y=
=QKwE
-----END PGP SIGNATURE-----