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