Re: [TLS] Comparative cipher suite strengths

"Blumenthal, Uri" <uri@ll.mit.edu> Wed, 22 April 2009 15:12 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 3D1073A67BD for <tls@core3.amsl.com>; Wed, 22 Apr 2009 08:12:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.274
X-Spam-Level:
X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.323, 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 lIaEZ+CZHUkn for <tls@core3.amsl.com>; Wed, 22 Apr 2009 08:12:19 -0700 (PDT)
Received: from ll.mit.edu (LLMAIL1.LL.MIT.EDU [129.55.12.41]) by core3.amsl.com (Postfix) with ESMTP id B69EE3A6921 for <tls@ietf.org>; Wed, 22 Apr 2009 08:12:19 -0700 (PDT)
Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id n3MFDZAJ026435 for <tls@ietf.org>; Wed, 22 Apr 2009 11:13:35 -0400 (EDT)
Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdBAAPJay0f; Wed Apr 22 10:58:20 2009
Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Wed, 22 Apr 2009 10:58:14 -0400
From: "Blumenthal, Uri" <uri@ll.mit.edu>
To: "tls@ietf.org" <tls@ietf.org>
Date: Wed, 22 Apr 2009 10:58:07 -0400
Thread-Topic: [TLS] Comparative cipher suite strengths
Thread-Index: AcnDUHdFJ2LSLZX5Scqa3uDCJK5DYQACkdlB
Message-ID: <C614A8BF.418A%uri@ll.mit.edu>
In-Reply-To: <20090422134627.C58A718852A@kilo.networkresonance.com>
Accept-Language: en-US
Content-Language: en
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C614A8BF418Aurillmitedu_"
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 15:12:26 -0000

>> I disagree. You're mixing together two orthogonal issues: security
>> of algorithms and security of implementation.
>>
>> NIST recommends that algorithms in a cipher suite are of comparable
>> strength. That includes relative key length.
>
> I appreciate that NIST recommends this. I think it's silly.
> It doesn't get any less silly because it's typeset in cool
> FIPS formatting.

And  I think it makes a perfect sense. It lowers the likelihood of people building tents with steel doors.

We both are entitled to our opinions - but the way cryptographers in all the places (academy, industry, etc) go suggests more weight on my side of the argument. (I know you're going to say that in my analogy the implementation quality is that tent - so see below.)

>> The fact that despite of using secure algorithms your implementation
>> still can have exploitable bugs (that nullify the benefits of
>> cryptography) is 100% irrelevant to the issue of selecting
>> algorithms and their parameters.
>
> I don't agree that that's true, but in any case it's not what I'm saying.

>From cryptography point of view it is true to a very large extent. The fact that there are attacks directed against implementations (DFA, etc) does not reduce the importance of "pure math" algorithm study. But see below.

> The amount of computational power required to break a 128-bit AES
> key with current is so outlandishly large that there is no plausible
> scenario that such a key will be broken by brute force. The
> only plausible situations in which 128-bit AES keys are breakable,
> then, are non-brute-force attacks such as attacks on the implementation
> or an analytic attack.

Yes, so? Until we learned about differential cryptanalysis we assumed that DES was 2^56 strong. Once we learned of that attack, we dropped our estimated strength to 2^47, then to 2^42... And then 2^56 became breakable by brute force. So...? For now AES-128 is 2^128 strong - feel free to prove otherwise.

> In neither case does 2^{128} represent
> an accurate estimate of the security of the algorithm, nor is
> there any reason to believe that AES-256 is 2^{128} times more
> secure under such attacks. Thus, the inference that one ought to
> use an RSA key that is 2^{128} times stronger with AES-256 than
> AES-128 also does not follow.

The above is cryptographically incorrect. True, we can't know for sure that AES-128 has 2^128 strength against analytical attack, though at this time it appears so (as implementation attacks are out of scope for this discussion). We don't know for sure that AES-256 is 2^128 stronger than AES-128 either. It is simply impossible to prove (given the current state of the science), as you well know. (Needless to say you can't prove at this time that it is less strong either.)

But until there are tangible reasons to assume otherwise - we go by the existing evidence that suggests 2^128 strength for AES-128, and 2^256 for AES-256 correspondingly. So the inference follows directly that we use equivalent (ballpark!) key strength for RSA and ECC.

The practical question becomes - what peer algorithms to choose for the suite based on AES-256. I say use NIST guidelines - and at the very least you won't get sued for negligence (in that area :-).

Also, keep in mind that there is no exact matching of the key strength - only the ballpark.
--
Regards,
Uri
<Disclaimer>