Re: [TLS] Comparative cipher suite strengths

Daniel Brown <dbrown@certicom.com> Thu, 23 April 2009 18:38 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 9572428C133 for <tls@core3.amsl.com>; Thu, 23 Apr 2009 11:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level:
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599]
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 R7lh-uI-yn7S for <tls@core3.amsl.com>; Thu, 23 Apr 2009 11:38:02 -0700 (PDT)
Received: from cx295.800onemail.com (cx295.800onemail.com [209.171.54.152]) by core3.amsl.com (Postfix) with ESMTP id A4C193A6E09 for <tls@ietf.org>; Thu, 23 Apr 2009 11:38:02 -0700 (PDT)
Received: from ex13-n02.exchserver.com ([192.168.162.157]) by cx295.800onemail.com (8.13.1/8.13.1) with ESMTP id n3NIdCvg022496; Thu, 23 Apr 2009 14:39:13 -0400
Received: from EX41.exchserver.com ([10.7.40.62]) by ex13-n02.exchserver.com ([192.168.162.161]) with mapi; Thu, 23 Apr 2009 14:39:14 -0400
From: Daniel Brown <dbrown@certicom.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>, Eric Rescorla <ekr@networkresonance.com>
Date: Thu, 23 Apr 2009 14:39:12 -0400
Thread-Topic: [TLS] Comparative cipher suite strengths
Thread-Index: AcnEPYq8CgV3egfmTtSZ3bUkOZPxrQAAGb/g
Message-ID: <DB0308E9CFAFAE4FB19F9C151B957F4145684D536B@EX41.exchserver.com>
References: <90E934FC4BBC1946B3C27E673B4DB0E46A6136F31C@LLE2K7-BE01.mitll.ad.local> <20090422134627.C58A718852A@kilo.networkresonance.com> <DB0308E9CFAFAE4FB19F9C151B957F4145684D4F72@EX41.exchserver.com> <20090423135638.E17DF188780@kilo.networkresonance.com> <DB0308E9CFAFAE4FB19F9C151B957F4145684D52EC@EX41.exchserver.com> <p0624084bc6165b1aa04e@[10.20.30.158]>
In-Reply-To: <p0624084bc6165b1aa04e@[10.20.30.158]>
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 18:38:03 -0000

Paul,

Yes, I certainly ignored many parts of SP 800-57.  I'm sorry about that.

But I don't want to also ignore other parts of SP 800-57 (Revision, March 2007) such as Table 4 column heading: "Algorithm security lifetime", which also appears in the Glossary defined as "The estimated time period during which data protected by a specific algorithm remains secure".  Further on, SP 800-57 makes requirements based on Table 4, "Algorithms or key sizes not indicated for a given range of years shall not be used to protect information during that time period."  (My personal interpretation of this is that 2048-bit FFC is not to be used for data needing protection beyond 2030 under SP 800-56 compliance, but I could be completely wrong, and I have not found a more direct quote to support this.)

SP 800-57 does not provide rationale for this requirement, does it?  Is it unreasonable to speculate NIST's rationale, if only as a less dry way to discuss purely objective arguments, such as Eric's, about recommendations such as Table 4, and their wider applicability to TLS users and people not bound by SP 800-57 but who might appreciate following its guidance, especially given the question about incomparable algorithm security levels over which this thread began?

Best regards,

	Dan

-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] 
Sent: Thursday, April 23, 2009 2:00 PM
To: Daniel Brown; Eric Rescorla
Cc: 'tls@ietf.org'
Subject: Re: [TLS] Comparative cipher suite strengths

At 1:13 PM -0400 4/23/09, Daniel Brown wrote:
>Table 4, provides a list of algorithm security lifetimes,

That's your interpretation. NIST labels the table "Recommended algorithms and minimum key sizes", and precedes it with "Table 4 provides recommendations that may be used to select an appropriate suite of algorithms and key sizes for Federal Government unclassified applications." If you want to ignore that and call it "a list of algorithm security lifetimes", that's fine, but maybe don't attribute that interpretation to NIST without further backup.
>
>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.

See above.

>... but perhaps NIST was ... or perhaps NIST was ... or perhaps NIST is ...

Another possibility is to take NIST's words as what they intended to say.


--Paul Hoffman, Director
--VPN Consortium