RE: IPS security draft: SRP groups

[[e-mail]]

MANY THANKS -- Tom's earned his promised 30
minutes of fame ... although those 30 minutes may come at
the ipr BOF in Yokohama on Friday :-) :-).  

For the security draft, specifying one of the acceptable
generators from Tom's lists for each of the IKE groups and
noting that the primes from the SRP distribution were
probabilistically generated should be sufficient ...
but there's still 30 minute of fame available for someone
who tackles proving that the SRP primes are prime, as there
is significant IETF interest in SRP outside of iSCSI - any takers?

Thanks,  --David

> -----Original Message-----
> From: Tom Wu [mailto:[e-mail]]
> Sent: Monday, July 08, 2002 12:23 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: IPS security draft: SRP groups
> 
> 
> David,
> 
> I'll tackle the SRP generator issue:
> 
> For the Oakley Group 2 (1024 bit prime) defined in RFC2412:
> Primitive roots (acceptable as SRP generators):
> 5,11,13,19,29,31
> Subgroup generators (NOT acceptable):
> 2,3,7,17,23
> 
> (MODP moduli taken from draft-ietf-ipsec-ike-modp-groups-04.txt)
> For the 1536-bit MODP group:
> Acceptable generators:
> 31
> NOT acceptable generators:
> 2,3,5,7,11,13,17,19,23,29
> 
> For the 2048-bit MODP group:
> Acceptable generators:
> 11,13,17,23,29,31
> NOT acceptable generators:
> 2,3,5,7,19
> 
> For the 3072-bit MODP group:
> Acceptable generators:
> 5,7,17,23,31
> NOT acceptable generators:
> 2,3,11,13,19,29
> 
> For the 4096-bit MODP group:
> Acceptable generators:
> 5,13,29,31
> NOT acceptable generators:
> 2,3,7,11,17,19,23
> 
> For the 6144-bit MODP group:
> Acceptable generators:
> 5,11,13,17,23,29
> NOT acceptable generators:
> 2,3,7,19,31
> 
> For the 8192-bit MODP group:
> Acceptable generators:
> 19,23,29,31
> NOT acceptable generators:
> 2,3,5,7,11,13,17
> 
> All the above generators are in base 10 (decimal).
> 
> As far as proving the primality of the SRP moduli, that 
> should be done 
> by someone with more expertise in the area.  I should point out that 
> those moduli are also "safe primes", i.e. both N and (N-1)/2 
> are prime, 
> so it is easy to find generators for them, and I chose 
> numbers that had 
> 2 as safe SRP generators.
> 
> Tom
> 
> [e-mail] wrote:
> > Missed this earlier, sorry ...
> > 
> > 
> >>Ok.  I didn't know that but I probably would have learned 
> it if I had
> >>done the necessary reading about groups and generators.  
> But the point
> >>of my question wasn't "is it possible to compute g" but rather "how
> >>about supplying g in the spec" (since the g=2 from IKE is not
> >>appropriate).   It seems a bit redundant for everyone to repeat the
> >>search for a suitable g...
> >>
> >>So what's the story about unlisted groups?  Is an 
> implementation that
> >>accepts only the groups listed in appendix A, but not any "locally
> >>generated" ones, a compliant implementation?
> >>
> > 
> > Yes - accepting those groups and only those groups is the minimum
> > (MUST) requirement.  If the IKE groups are to remain allowed, we
> > need to specify generators for their use with SRP - please consider
> > this to be a serious *PLEA* for someone to volunteer to do the
> > crpto-theoretic number crunching needed to find SRP generators for
> > those groups and/or prove the primality of the SRP primes.  Lack of
> > progress here has the potential to hold up the security draft on
> > which *all* of our protocol drafts depend (normative references).
> > We can promise at least 30 minutes of fame (*twice* the proverbial
> > 15 ;-) ) to those who resolve this issue ...
> > 
> > Thanks,
> > --David
> > ---------------------------------------------------
> > David L. Black, Senior Technologist
> > EMC Corporation, 42 South St., Hopkinton, MA  01748
> > [phone]            FAX: [phone]
> > [e-mail]       Mobile: [phone]
> > ---------------------------------------------------
> 
> 
> -- 
> Tom Wu
> Principal Software Engineer
> Arcot Systems
> [phone]
> "The Borg?  Sounds Swedish..."
>