RE: AES draft query

"John Harleman" <jharleman@certicom.com> Sat, 18 March 2000 01:16 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 RAA26947; Fri, 17 Mar 2000 17:16:01 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA08789 Fri, 17 Mar 2000 18:31: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.008178CD.00@smtpmail.certicom.com>
Date: Fri, 17 Mar 2000 15:34:30 -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

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
>
>