Re: [TLS] Comparative cipher suite strengths

"Blumenthal, Uri" <uri@ll.mit.edu> Wed, 22 April 2009 12:16 UTC

Return-Path: <uri@ll.mit.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 0ACEE28C3E0 for <tls@core3.amsl.com>; Wed, 22 Apr 2009 05:16:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.275
X-Spam-Level:
X-Spam-Status: No, score=-6.275 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 rrmdlTGDIsRv for <tls@core3.amsl.com>; Wed, 22 Apr 2009 05:16:19 -0700 (PDT)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id 2A99E3A6CF3 for <tls@ietf.org>; Wed, 22 Apr 2009 05:15:47 -0700 (PDT)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MCGu8H029377; Wed, 22 Apr 2009 08:16:56 -0400 (EDT)
Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAllaOCT; Wed Apr 22 08:10:23 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 08:10:23 -0400
From: "Blumenthal, Uri" <uri@ll.mit.edu>
To: "'carlyoung@keycomm.co.uk'" <carlyoung@keycomm.co.uk>, "'tls@ietf.org'" <tls@ietf.org>
Date: Wed, 22 Apr 2009 08:10:22 -0400
Thread-Topic: [TLS] Comparative cipher suite strengths
Thread-Index: AcnDO+xatMKjGfzKSj6rOFK4ebAM7AAB2NgX
Message-ID: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31A@LLE2K7-BE01.mitll.ad.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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 12:16:20 -0000

Carl,

You are correct in your approach. It makes sense to suggest longer RSA keys to that customer of yours, based on the NIST specs (the exact reference eludes me at the time).


----- Original Message -----
From: tls-bounces@ietf.org <tls-bounces@ietf.org>
To: TLS <tls@ietf.org>
Sent: Wed Apr 22 07:16:32 2009
Subject: Re: [TLS] Comparative cipher suite strengths


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

Regards,

Carl


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls