[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: AES draft query
Note that 3DES key length has only a loose relation to the strength
of the algorithm and the strength requirement of users. The key
length is what it is because 3*56 = 168.
It's often the case that you can get a cipher that has a long
key length and is fast. In that case, you don't worry about
whether or not the key has more strength than you need.
To date that luxury does not exist for scalable key exchange
algorithms - each bit of strength costs a lot in computation
cost. Thus, the desire to adjust the key exchange strength
to minimum system requirement (or the maximum tolerable
computation effort).
Hilarie
>>> "John Harleman" <jharleman@certicom.com> 03/17/00 04:34PM >>>
I fully appreciate the security that 128-bit symmetric brings. Key sizes such as
this for AES or 112-bit symmetric for 2-key 3DES are understandable since they
are the next logical jump in size above 80-bit symmetric (160-bit ECC and 1,024
RSA). However, 192-bit AES or 256-AES coupled with lesser strength public-key is
misleading since the security of the system is only as strong as the weakest
link. So my question would be why would anybody implement AES at key strengths
above 128-bits or 3DES at 168-bits without using the correspondingly strong
public-key size? cheers - john
"Hilarie Orman" <HORMAN@novell.com> on 17.03.2000 14:42:32
To: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com
cc: (bcc: John Harleman/Certicom)
Subject: RE: AES draft query
These issues are discussed in
draft-orman-public-key-lengths-00.txt
on which commentary is solicited.
Hilarie
>>> "Linn, John" <jlinn@rsasecurity.com> 03/16/00 11:17AM >>>
Jesse,
Good points. While the incremental cost of additional symmetric key bits
beyond the anticipated state of the art is "almost free", this is very much
not true for increasing the number of asymmetric key bits used to transport
those symmetric keys. An RSA Laboratories paper with further analysis on
key size issues is now being finalized for web publication, probably within
the next couple of weeks; I'll post a citation when it's available.
--jl
> -----Original Message-----
> From: Walker, Jesse [mailto:jesse.walker@intel.com]
> Sent: Thursday, March 16, 2000 9:29 AM
> To: ipsec@lists.tislabs.com
> Subject: AES draft query
>
>
> Page 9 of the draft recommends 3240-bit Diffie-Hellmans for
> 128-bit AES,
> 7945-bit Diffie-Hellmans for 192-bit AES, and 15430-bit
> Diffie-Hellmans for
> 256-bit AES. It is worth discussing whether these
> requirements address a
> real perceived threat or are at best theoretical in nature.
> While the defers
> the discussion on how they were derived to a reference, it is
> easy enough to
> guess how they were obtained: select the Diffie-Hellman
> modulus size at the
> point where computing the discrete logarithm becomes just as
> expensive as
> attacking the symmetric key directly. However, unlike
> symmetric algorithms,
> public key operations like Diffie-Hellmans have a real cost,
> so this may not
> be the best way to set the requirement, even if it is
> theoretically the
> "right" way to do the job. Even if you believe Moore's law
> will remain true
> for the forseeable future, 8K and 15K still represent about 9
> and 11 more
> generations of processors, respectively, before you get
> performance most
> users will tolerate. The most credible study I've seen estimating key
> strengths is Lenstra and Verheul's "Selecting Cryptographic
> Key Sizes",
> November 15, 1999. They estimate that 4K modular
> exponentiations will still
> be secure from any reasonable attacks for the next 50 years.
> So why should
> there be a requirement for anything above about 4K
> Diffie-Hellmans at this
> time? On the point of Diffie-Hellman modulus sizes, the draft's
> requirements seem to be way out of line both in regard to the state of
> technology and in regard to the nature of the perceived
> possible threats in
> the time frames when the draft will be applicable. What am I missing?
>
> -- Jesse Walker
>
>