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