Ah, thanks. You helped me tremedously there with the size-of-group vs
strength-of-group distinction.

Very much appreciated.

--
Ricky Charlet 
rchar...@nortel.com
USA 408-495-5726 

> -----Original Message-----
> From: Scott Fluhrer [mailto:sfluh...@cisco.com] 
> Sent: Wednesday, May 27, 2009 1:54 PM
> To: Charlet, Ricky (SC100:0000); ipsec@ietf.org; 
> kivi...@ssh.fi; mika.k...@helsinki.fi; 
> hila...@purplestreak.com; paul.hoff...@vpnc.org
> Subject: RE: [IPsec] Question on exponent size as discussed 
> in RFC 3526
> 
> 
>  
> 
> > -----Original Message-----
> > From: Ricky Charlet [mailto:rchar...@nortel.com] 
> > Sent: Wednesday, May 27, 2009 2:58 PM
> > To: Scott Fluhrer; ipsec@ietf.org; kivi...@ssh.fi; 
> > mika.k...@helsinki.fi; hila...@purplestreak.com; 
> paul.hoff...@vpnc.org
> > Subject: RE: [IPsec] Question on exponent size as discussed 
> > in RFC 3526
> > 
> > Hi Scott,
> >     Thanks for your reply. Unfortunatly, your reply 
> > continues my exact same confusion. Should e be twice the size 
> > of the key you need or twice the size of the dh group in use? 
> 
> Twice the size of the key you need.
> 
> > 
> > You state that 
> > 
> > > the reason that the examples seem to indicate a correlation 
> > with the 
> > > symmetric key sizes is because there is a correlation with the 
> > > symmetric key sizes.
> > 
> > And
> > > On the other hand, for picking exponent length, what we 
> > want to do is 
> > > make sure that it isn't the weakest part of the system; if 
> > we pick a 
> > > length that's double the symmetric key size, then we know 
> that the 
> > > attack based on exponent length will take about as long as 
> > attacking 
> > > the symmetric key directly.
> > 
> > And
> > > Double the size of the symmetric key.  BTW: double the size 
> > > of p would be
> > > silly; it turns out that:
> > 
> > These statements combine into a very forceful endorcement 
> of the idea
> > that the exponent should be double the size of the key you need to
> > generate. 
> > 
> > Yet in your last statement you also said:
> > > Actually, it's closer to "twice the size of the strength of 
> > > the group".  The
> > > "strength of the group" is its resistance to the attack #3 I 
> > > have listed
> > > (NFS).
> > 
> > That really threw me. I have been taking the term "group" 
> to mean the
> > size of the modp group in bits (which is basically the size 
> of p). In
> > the context of the introdution section of RFC 3526, I'm 
> > pretty sure this
> > is what was meant: definition group = dh group. But you 
> seem to have a
> > different defintion of 'group'?
> 
> No; the distinction you appear to be missing is that 'size of 
> the group' !=
> 'strength of the group'.
> 
> 'The size of the group' is, basically, p (well, actually, 
> it's (p-1)/2,
> because we're working in a subgroup of that size; that's only 
> one bit less,
> and so we can ignore it).
> 
> 'The strength of the group' is how much effort it is to solve 
> the discrete
> log problem in that group.  This is considerably less than 
> the size of the
> group.
> 
> Now, for most symmetric ciphers, there's really no such 
> distinction; an 128
> bit AES key has a size of 128 bits and (to the best of our 
> knowledge) it
> takes about 2**128 trial decryptions to recover the key, and 
> so it has a
> strength of 128 bits.   Counterexample: 3DES, which has a key 
> size of either
> 168 or 192 bits (depending on whether you count the ignored bits), and
> appears to have a strength of about 112 bits (assuming you 
> have access to a
> huge amount of memory).
> 
> However, this isn't true for DH; the group size and the 
> strength differ
> widely.  For example, take DH group 14; that has a group size 
> of 2048 bits;
> however, using NFS, it is believed that you can recover a 
> private exponent
> after between 2**110 and 2**160 operations (and, yes, that's 
> a large range;
> no one is quite sure how NFS scales with a modulus that size), and so
> appears to have a strength of between 110 and 160 bits.
> 
> 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to