Re: [TLS] Comparative cipher suite strengths

Daniel Brown <dbrown@certicom.com> Thu, 23 April 2009 17:18 UTC

Return-Path: <dbrown@certicom.com>
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 1D84428C751 for <tls@core3.amsl.com>; Thu, 23 Apr 2009 10:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level:
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74]
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 dhuUvMy2ifNu for <tls@core3.amsl.com>; Thu, 23 Apr 2009 10:18:52 -0700 (PDT)
Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id 5070D28C754 for <tls@ietf.org>; Thu, 23 Apr 2009 10:12:11 -0700 (PDT)
Received: from ex13-n01.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n3NHD13j011541; Thu, 23 Apr 2009 13:13:25 -0400
Received: from EX41.exchserver.com ([10.7.40.62]) by ex13-n01.exchserver.com ([192.168.162.160]) with mapi; Thu, 23 Apr 2009 13:13:16 -0400
From: Daniel Brown <dbrown@certicom.com>
To: Eric Rescorla <ekr@networkresonance.com>
Date: Thu, 23 Apr 2009 13:13:13 -0400
Thread-Topic: [TLS] Comparative cipher suite strengths
Thread-Index: AcnEGxMXdbGYn/VCT12hted6osobGgAFUaFQ
Message-ID: <DB0308E9CFAFAE4FB19F9C151B957F4145684D52EC@EX41.exchserver.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <DB0308E9CFAFAE4FB19F9C151B957F4145684D4F72@EX41.exchserver.com> <20090423135638.E17DF188780@kilo.networkresonance.com>
In-Reply-To: <20090423135638.E17DF188780@kilo.networkresonance.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CRXEFW-Info: Please contact Ceryx for more information
X-CRXEFW-Virus: Clean
X-CRXEFW-From: dbrown@certicom.com
Cc: "'tls@ietf.org'" <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: Thu, 23 Apr 2009 17:18:53 -0000

NIST SP 800-57, Table 2, provides a list of comparable strengths, and Table 4, provides a list of algorithm security lifetimes, which I liberally interpret as saying 2^80 computations may be feasible for a concerted adversary, in 2010 and perhaps 2^112 operations may be feasible by 2030.  

Note that Table 4 does not differentiate the lifetimes 128, 192, or 256 security, in loose agreement with, and perhaps for similar reasons to, Eric's argument that searching 2^128 keys will never be feasible.

Furthermore, adapting Eric's calculations below, to brute force 112-bit keys, assuming 80-bit keys are brute forcible today (let's just say with massive distributed computing for the sake of example), feature sizes would need to shrink to 50 * 10^{-9} * 2^{-32} =~ 1.16 * 10^{-17}, still smaller than a Hydrogen atom, but perhaps NIST was accounting for the possibility of some future technical developments leading to continued or even accelerated increase in processing power, or perhaps NIST was also accounting for some degradation in the security of the TDEA aglorithm below that of a generic block cipher, or perhaps NIST is just encouraging migration to AES. 

That all said, personally, I'm still much more reluctant to predict a decrease in the growth of processing power that has been going fairly steady (?) for some time.  Therefore, data needing long term protection, say medical information, is worth encrypting at a potentially higher security level, assuming one has the processing power and a well-established encryption algorithm to do so.  If Moore's law (liberally applied to processing power, not just feature size) stops soon enough, then using the larger keys was at worst a waste of processing power, or at best, insurance.

Best regards,

	Dan

-----Original Message-----
From: Eric Rescorla [mailto:ekr@networkresonance.com] 
Sent: Thursday, April 23, 2009 9:57 AM
To: Daniel Brown
Cc: Eric Rescorla; Blumenthal, Uri; 'tls@ietf.org'
Subject: Re: [TLS] Comparative cipher suite strengths

At Wed, 22 Apr 2009 11:51:10 -0400,
Daniel Brown wrote:
> 
> Eric,
> 
> Are you saying that 2^128 computations will never be feasible, and
> therefore, that Moore's law will stop?

I wasn't aware that that was a particularly controversial observation.

Current computers, with feature sizes of about 50 nm (50 * 10^{-9} m)
are just about fast enough to brute force a 64-bit key. So, in order
for Moore's law (which, remember, is about feature size) to get us to
128-bit keys, the feature sizes would need to shrink to 50 * 10^{-9} *
2^{-64} ~= 50 * 10^{-28}. Given that hydrogen atoms are on the order
of 10^{-10} m large, I don't think it's particularly safe to do a
straight line extrapolation of Moore's law through 18 more orders of
magnitude. Obviously, it's possible we'll learn how to construct
computers with some entirely different technology (quarks!), but
it's not like it's just a matter of giving Intel more money.

-Ekr