Re: [TLS] Next protocol negotiation

Adam Langley <agl@google.com> Fri, 22 January 2010 11:03 UTC

Return-Path: <agl@google.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 6DC303A687C for <tls@core3.amsl.com>; Fri, 22 Jan 2010 03:03:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.834
X-Spam-Level:
X-Spam-Status: No, score=-103.834 tagged_above=-999 required=5 tests=[AWL=-1.857, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, USER_IN_WHITELIST=-100]
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 itshveRmgvV2 for <tls@core3.amsl.com>; Fri, 22 Jan 2010 03:03:37 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 017793A6868 for <tls@ietf.org>; Fri, 22 Jan 2010 03:03:36 -0800 (PST)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id o0MB3WsD013098 for <tls@ietf.org>; Fri, 22 Jan 2010 03:03:32 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1264158212; bh=mK1Cw5/EDlZ1eCubORfBtWJwh9c=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=MY71hVc72eAi5XQxKjHMG9Rb2FoW9lBtbNFLNOyrCg1rGlzr+qxdusZVL2W7igvkn X0mgSL9b2j99Hu2aVIvOQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=Zn63juplB+zPYRvt/UY4USx+7bnD0NbiT3hPd6PZvO2DwPFaYkXbG7bYvQLVRzP1B VzaaVfw/2ahK/xj9I5QGA==
Received: from pwi8 (pwi8.prod.google.com [10.241.219.8]) by wpaz29.hot.corp.google.com with ESMTP id o0MB3Kd9010453 for <tls@ietf.org>; Fri, 22 Jan 2010 03:03:31 -0800
Received: by pwi8 with SMTP id 8so788518pwi.31 for <tls@ietf.org>; Fri, 22 Jan 2010 03:03:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.9.10 with SMTP id 10mr1915854wfi.177.1264158210806; Fri, 22 Jan 2010 03:03:30 -0800 (PST)
In-Reply-To: <Pine.LNX.4.44.1001211635200.531-100000@citation2.av8.net>
References: <a84d7bc61001211140r24388501l644b47cb4868cae0@mail.gmail.com> <Pine.LNX.4.44.1001211635200.531-100000@citation2.av8.net>
Date: Fri, 22 Jan 2010 03:03:30 -0800
Message-ID: <a84d7bc61001220303t18bc3cfbk5739eb5d356add83@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Dean Anderson <dean@av8.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] Next protocol negotiation
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: Fri, 22 Jan 2010 11:03:38 -0000

On Thu, Jan 21, 2010 at 1:51 PM, Dean Anderson <dean@av8.com>; wrote:
> I don't think so. As CPU's speed up improving encryption/decryption
> times, so does cracking improve, resulting in deployment of more
> difficult ciphers, leaving time to encrypt roughly unchanged.  So I
> don't think encryption gets "easier" or less time-consuming in the
> future. Again, an impression, but consider that the RSA-768 key was just
> cracked, and so we recommend getting rid of 1024 bit keys.

Clients get the easy side of the RSA operations of course. If we take
four different hosts from the ECRYPT benchmarks[1] we can get the
number of cycles required to perform an RSA encryption of a given bit
size:

1024    203820  171138  79404   302432
1536    317448  260392  117587  519928
2048    470556  386199  157766  779696
3072    866280  704583  271095  1604108
4096    1396896 1067935 387822  2423856

(CPUs are, in order, Atom (molecule), Core2 (nmui0247), A64 X2 (mace),
Power5 (nmi0154))

Normalising each of these so that the time taken for 1024 is 1:

1024    1       1       1       1
1536    1.557   1.522   1.481   1.719
2048    2.309   2.257   1.987   2.578
3072    4.250   4.117   3.414   5.304
4096    6.854   6.240   4.884   8.015

However, from the 768-bit factoring paper[2] they suggest that a
1024-bit key is 5x harder to factor than a 768-bit key, for only a
1.3x increase in the number of bits. So it appears the that defender
has the advantage as processor speeds increase (modulo quantum
factoring, should it ever be tractable).

[1] http://bench.cr.yp.to/results-encrypt.html
[2] http://eprint.iacr.org/2010/006.pdf

> And e.g some
> interesting results were published for AES-256, suggesting it will be
> easier to crack than originally anticipated, meaning it will be obsolete
> sooner.

You can repeat the procedure above for stream ciphers too. Again, the
defenders appear to have the advantage over time.


AGL