Re: [TLS] Comparative cipher suite strengths
"Steven M. Bellovin" <smb@cs.columbia.edu> Wed, 22 April 2009 11:37 UTC
Return-Path: <smb@cs.columbia.edu>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DCAF3A6D13 for <tls@core3.amsl.com>; Wed, 22 Apr 2009 04:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.47
X-Spam-Level:
X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DmRTfo3c+tu for <tls@core3.amsl.com>; Wed, 22 Apr 2009 04:37:01 -0700 (PDT)
Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 30B093A6926 for <tls@ietf.org>; Wed, 22 Apr 2009 04:37:01 -0700 (PDT)
Received: by machshav.com (Postfix, from userid 512) id 0BE083286B1; Wed, 22 Apr 2009 11:38:16 +0000 (GMT)
Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41BCA3286AD; Wed, 22 Apr 2009 11:38:14 +0000 (GMT)
Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id D3713298403; Wed, 22 Apr 2009 07:38:10 -0400 (EDT)
Date: Wed, 22 Apr 2009 07:38:10 -0400
From: "Steven M. Bellovin" <smb@cs.columbia.edu>
To: carlyoung@keycomm.co.uk
Message-ID: <20090422073810.5ab7248e@cs.columbia.edu>
In-Reply-To: <51912.1240398992@keycomm.co.uk>
References: <51912.1240398992@keycomm.co.uk>
Organization: Columbia University
X-Mailer: Claws Mail 3.7.0 (GTK+ 2.16.0; x86_64--netbsd)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Cc: TLS <tls@ietf.org>
Subject: Re: [TLS] Comparative cipher suite strengths
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Apr 2009 11:37:02 -0000
On Wed, 22 Apr 2009 12:16:32 +0100 carlyoung@keycomm.co.uk wrote: > > >>On Wed 22/04/09 11:35 AM , Simon Josefsson simon@josefsson.org sent: > >>> The "key strength" would be limited by the weakest link in the > >>> suite though wouldn't it, which, in this case, is the RSA keys? > >>> Or are you saying that the additional security of the PRF, key > >>> derivation mechanisms, and the entropy in the random data > >>> overcomes this? > >> > >> No, I'm saying that talking about trying to match anything to > >> AES-256 doesn't make sense. We don't know of any situation in > >> which even AES-128 can be attacked. > > > >What we can always do, though, is to compare the amount of work > >needed to break AES-256 with the amount of work needed to break > >RSA-y using state-of-the-art attacks. It's possible that this imply > >y=15360. > > > >However, I agree that this is looking at things the wrong way. The > >exercise should not have any practical consequences on what key sizes > >you use. One should focus on selecting appropriate security level for > >each algorithm. Today AES-128 and RSA-2048 will probably make > >implementation bugs the weakest link for the majority of users. > > Thanks for all the responses. I think the following text is a better > way of describing what I meant and why I was asking: > > We have a customer that mandated that we utilize AES-256 for the > symmetric encryption keys used on our TLS sessions, so we have > complied, and this works fine. Looking at implementation details from > the customer, I found that they are using static X.509v3 certificates > (CA issued), where the public key size is only 1024 bits. > > Therefore, in my mind, they are getting a false sense of security > from using AES-256 as the underlying strength of the whole TLS > session is determined by the weakest point - in this case the 1024 > bit RSA keys, which NIST state to be equivalent to "80-bits" [when > compared to a symmetric cipher I guess]. > > So, I would want to recommend to the customer that if they want a > more secure TLS session, then they need to increase the RSA key sizes > to "match" the symmetric key strength, as the overall security > 'strength' of their TLS sessions comes down to their RSA key size [as > it's lower comparably to AES-256]. > > Does this seem reasonable and make more sense than my original > question? > Yes -- see RFC 3766. NIST also has some recommendations, but I don't happen to know the publication number offhand. --Steve Bellovin, http://www.cs.columbia.edu/~smb
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- [TLS] Comparative cipher suite strengths Carl Young
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths carlyoung
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Simon Josefsson
- Re: [TLS] Comparative cipher suite strengths carlyoung
- Re: [TLS] Comparative cipher suite strengths Steven M. Bellovin
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Steven M. Bellovin
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Steven M. Bellovin
- Re: [TLS] Comparative cipher suite strengths Michael.G.Williams
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Daniel Brown
- Re: [TLS] Comparative cipher suite strengths Nicolas Williams
- Re: [TLS] Comparative cipher suite strengths Peter Gutmann
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Daniel Brown
- Re: [TLS] Comparative cipher suite strengths Paul Hoffman
- Re: [TLS] Comparative cipher suite strengths Daniel Brown
- Re: [TLS] Comparative cipher suite strengths Paul Hoffman
- Re: [TLS] Comparative cipher suite strengths Steven M. Bellovin
- Re: [TLS] Comparative cipher suite strengths Nicolas Williams
- Re: [TLS] Comparative cipher suite strengths Dean Anderson
- Re: [TLS] Comparative cipher suite strengths Martin Rex
- Re: [TLS] Comparative cipher suite strengths Dean Anderson
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Michael D'Errico
- Re: [TLS] Comparative cipher suite strengths carlyoung
- Re: [TLS] Comparative cipher suite strengths Florian Weimer
- Re: [TLS] Comparative cipher suite strengths Peter Gutmann
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Vipul Gupta
- Re: [TLS] Comparative cipher suite strengths Nicolas Williams
- Re: [TLS] Comparative cipher suite strengths Robert Relyea
- Re: [TLS] Comparative cipher suite strengths Peter Gutmann
- Re: [TLS] Comparative cipher suite strengths Bill Frantz
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Peter Gutmann
- Re: [TLS] Comparative cipher suite strengths Blumenthal, Uri
- Re: [TLS] Comparative cipher suite strengths Jeffrey A. Williams
- Re: [TLS] Comparative cipher suite strengths Martin Rex
- Re: [TLS] Comparative cipher suite strengths Eric Rescorla
- Re: [TLS] Comparative cipher suite strengths Peter Gutmann
- Re: [TLS] Comparative cipher suite strengths Dean Anderson
- Re: [TLS] Comparative cipher suite strengths Steven M. Bellovin