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

Re: speaking of keys



Steve:

I support your recommendation.  In fact, I was going to make the same 
recommendation, but for a different reason.  I few weeks ago, we had a long 
thread discussing mandatory to implement signature algorithms.  We decided 
that RSA with 1024-bit keys will be mandatory to implement.  So, if 1024 
bits is adequate for the signature, it seems like 1024 should also be 
adequate for the key agreement algorithm.

Russ

At 11:05 AM 12/6/2002 -0500, Stephen Kent wrote:
>Since we've been discussing the details of key derivation, the amount of 
>entropy we get from a 1204 bit DH exchange, and how that aligns nicely 
>with the 160-bit hash output from SHA-1, I want to raise a related issue.
>
>Consistent with our efforts to simplify IPsec in general, I suggest that 
>we mandate support for just one DH group (of 1024-bit size) and require 
>that products provide a management interface to allow users/administrators 
>to specify other groups as needed.
>
>Althouhg I am not a cryptographer, it seems that the 160-bits we get from 
>a 1024-bit DH exchange is reasonable for use with 128-bit AES. I believe 
>that NIST suggests that 1024-it DH should be good until at least 2015, 
>although I forget what parameters they use in this analysis.
>
>Yes, I know we generate at least 2 and more often 4 keys from each DH 
>exchange (one each for encryption and integrity in each direction), so the 
>128-bit key size and 160-bit entropy measures are not so easily comparable.
>
>I also worry that if we insist that all IPsec (IKE) implementations 
>support 1536-bit DH, that too many folks will decide to select that 
>option, under the "bigger is better" theme.  However, the added 
>performance hit for 1536-bit DH is significant and might have the 
>unintended effect of causing folks to decide that the IPsec performance 
>hits is too big and thus choose not to employ IPsec at all.
>
>If we mandate support for locally selected DH parameters, then we do 
>permit more sophisticated user communities to select bigger groups, with 
>different parameters, if they really need to. I have received feedback 
>from some DoD clients that they want to use IPsec for protecting 
>unclassified data, but feel the need to use groups selected by their 
>crypto advisors (it's a union thing, I guess). it seem that many IKE 
>implementations do not provide a facility for configuring other groups, 
>and this poses problems for these folks. Hence my suggestion to adopt just 
>one MUST group, at the 1024-bit size, but also mandate support for a 
>management interface that allows user communities to support "custom" 
>groups. We could impose some requirements on the max size groups that MUSt 
>be supported via the management interface (to ensure interoperability), 
>without specifying these other, bigger groups.
>
>What do people think about this suggestion?
>
>Steve