RE: AES draft query
"John Harleman" <jharleman@certicom.com> Sat, 18 March 2000 01:13 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA26868; Fri, 17 Mar 2000 17:13:36 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08870 Fri, 17 Mar 2000 18:50:39 -0500 (EST)
X-Lotus-FromDomain: CERTICOM
From: John Harleman <jharleman@certicom.com>
To: Hilarie Orman <HORMAN@novell.com>
cc: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com
Message-ID: <852568A5.0083390E.00@smtpmail.certicom.com>
Date: Fri, 17 Mar 2000 15:54:20 -0800
Subject: RE: AES draft query
Mime-Version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-Disposition: inline
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
absolutely correct. but there is also 2 key 3des. as schneier and whiting recently pointed out: http://www.counterpane.com/aes-comparison.html key size is increased at the cost of performance with all AES canidates. So why would one use larger strength AES algorithms without using the corresponding strength with public-key? cheers - john "Hilarie Orman" <HORMAN@novell.com> on 17.03.2000 15:45:20 To: John Harleman/Certicom@Certicom cc: jesse.walker@intel.com, ipsec@lists.tislabs.com, jlinn@rsasecurity.com Subject: 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 > >
- AES draft query Walker, Jesse
- RE: AES draft query Linn, John
- Re: AES draft query Francois Rousseau
- RE: AES draft query Hilarie Orman
- RE: AES draft query Hilarie Orman
- RE: AES draft query John Harleman
- RE: AES draft query Hilarie Orman
- RE: AES draft query John Harleman
- RE: AES draft query Paul Hoffman
- Re: AES draft query EKR
- Re: AES draft query Paul Hoffman
- Re: AES draft query Scott G. Kelly
- Re: AES draft query John Harleman
- Re: AES draft query Hugo Krawczyk
- RE: AES draft query Paul Koning
- RE: AES draft query Andrew Krywaniuk
- RE: AES draft query Paul Hoffman
- RE: AES draft query Linn, John