SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    RE: IPS security draft: SRP groups



    Hi David,
    I can't prove so, but Mathematica from Wolfram certifies as prime (in a matter seconds) all five moduli specified in the iSCSI security draft for use in SRP! I used the PrimeQ built-in function. PrimeQ first tests for divisibility using small primes, then uses the Miller­Rabin strong pseudoprime test base 2 and base 3, and then uses a Lucas test. I have not explored the nature of these tests.
    Vince
    
    |-----Original Message-----
    |From: Black_David@emc.com [mailto:Black_David@emc.com]
    |Sent: Monday, July 08, 2002 7:34 AM
    |To: tom@arcot.com
    |Cc: ips@ece.cmu.edu
    |Subject: RE: IPS security draft: SRP groups
    |
    |
    |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:tom@arcot.com]
    |> Sent: Monday, July 08, 2002 12:23 AM
    |> To: Black_David@emc.com
    |> Cc: ips@ece.cmu.edu
    |> 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
    |> 
    |> Black_David@emc.com 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
    |> > +1 (508) 249-6449            FAX: +1 (508) 497-8018
    |> > black_david@emc.com       Mobile: +1 (978) 394-7754
    |> > ---------------------------------------------------
    |> 
    |> 
    |> -- 
    |> Tom Wu
    |> Principal Software Engineer
    |> Arcot Systems
    |> (408) 969-6124
    |> "The Borg?  Sounds Swedish..."
    |> 
    |
    


Home

Last updated: Fri Jul 12 11:18:52 2002
11299 messages in chronological order