Re: [TLS] Comparative cipher suite strengths
"Blumenthal, Uri" <uri@ll.mit.edu> Thu, 23 April 2009 12:02 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 B4FB63A71E3 for <tls@core3.amsl.com>; Thu, 23 Apr 2009 05:02:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.339
X-Spam-Level:
X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 KOoMmR689XmM for <tls@core3.amsl.com>; Thu, 23 Apr 2009 05:02:05 -0700 (PDT)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id C84773A71F1 for <tls@ietf.org>; Thu, 23 Apr 2009 05:02:04 -0700 (PDT)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3NC3Dl0021196 for <tls@ietf.org>; Thu, 23 Apr 2009 08:03:13 -0400 (EDT)
Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAA0XaqmA; Thu Apr 23 07:58:01 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Thu, 23 Apr 2009 07:58:01 -0400
From: "Blumenthal, Uri" <uri@ll.mit.edu>
To: "tls@ietf.org" <tls@ietf.org>
Date: Thu, 23 Apr 2009 07:57:58 -0400
Thread-Topic: [TLS] Comparative cipher suite strengths
Thread-Index: AcnD4hmhdd/C4p5aTS+nqbcAVdTcjgAKKTG3
Message-ID: <C615D006.41DE%uri@ll.mit.edu>
In-Reply-To: <E1Lwt0c-0006jy-La@wintermute01.cs.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C615D00641DEurillmitedu_"
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: Thu, 23 Apr 2009 12:02:10 -0000
How about this: US Government (yes, the one you seem to like rather less than the other governments) has declared that AES-128 can be used to protect information up to SECRET level, and for TOP SECRET one must use AES-256. Apparently they weren't aware of Eric's views regarding the unnecessariness of 256 bits when you have a perfectly good 128-bit key-space, and can't truly-really guarantee the algorithm strength anyway. They did not mandate (nor even define) AES-397 or 398 as of yet, obviously because crypto scientists who work for them are not as smart or sarcastic as we are here. So the optimal approach here would be to find out the real need of the customer - for what purpose he's trying to go to a higher-level encryption standard - and address it in practical matter (i.e. 15K RSA keys, while theoretically matching, are hardly usable in practice - so something bigger than 1K or 2K, but still wield-able; or follow Suite B and use ECC - in that case you can achieve the ballpark key size match between the algorithms). Though where that customer is going to get a reasonably bug-free implementation is beyond me. I concede this point. You can also point out to your customer that AES-128 is indeed considered "good enough" for most of the "normal" applications. But if he's already set his encryption policy, you probably won't get very far. -- Regards, Uri <Disclaimer> On 4/23/09 03:06 , "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote: carlyoung@keycomm.co.uk writes: >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]. They're not getting any sense of security at all. They initially wanted a cipher with 128-bit encryption, because everyone knows that you have to have 128 bits to be Good. AES encryption has the required 128 thingies, so they went with that. Then someone pointed out that there's a version of AES with 256 thingies instead of 128, and if 128 is Good then 256 must be even Gooder. So the requirement was changed to use AES with 256 thingies. If there was an AES with 397 thingies they'd go with that instead, because it's obvious that that one's ever Gooderer than the one with 256 thingies. >So, I would want to recommend to the customer that if they want a more secure >TLS session, They don't want a more secure TLS session, they want bigger numbers after their algorithm name. So the optimal approach here would be to write a draft for a new TLS cipher suite using the McEliece cryptosystem, because then you can use numbers bigger than anyone else. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- 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