Re: [TLS] Safe ECC usage

Yoav Nir <ynir@checkpoint.com> Tue, 01 October 2013 17:43 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626EF21F9DFA for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 10:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.238
X-Spam-Level:
X-Spam-Status: No, score=-10.238 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nus6-5NDF85I for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 10:43:28 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6B621F9E00 for <tls@ietf.org>; Tue, 1 Oct 2013 10:43:24 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r91HhGAb015783; Tue, 1 Oct 2013 20:43:16 +0300
X-CheckPoint: {524B09B4-18-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 20:43:16 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: =?iso-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <mpg@elzevir.fr>
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0om0uHYDyqy0CSy5O2MDQzFJncJGEAgAKSogCAAGtCAIAAjNCAgAAtxICAABIcAIAABKEA
Date: Tue, 1 Oct 2013 17:43:16 +0000
Message-ID: <4B2F58FD-9668-481A-B03F-72CFE910B4CC@checkpoint.com>
References: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> <524AF6AF.1070503@secunet.com> <524B05E0.10103@elzevir.fr>
In-Reply-To: <524B05E0.10103@elzevir.fr>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.31.20.231]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9142635286EDF541996A6C7F3EB4649F@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 01 Oct 2013 17:43:38 -0000

On Oct 1, 2013, at 8:26 PM, Manuel Pégourié-Gonnard <mpg@elzevir.fr>; wrote:
>> 
> Let's do the math, using openssl speed's results (1.0.1e on x86_64 linux,
> slightly edited for clarity):
> 
>                              sign    verify
> rsa 2048 bits            0.001558s 0.000048s
> 256 bit ecdsa (nistp256)   0.0001s   0.0003s
> 
> Now assuming the peer's certificate is signed by an intermediate CA,
> itself signed by a root CA, we have 1 sign, 1 verify for the KeyExchange
> or CertificateVerify message, 2 verify-s (signature by CA + crl) for the
> peer's certificate, same for the intermediate CA, a total of 1 sign + 5
> verify-s:
> 
> rsa 2048 bits:  1.8 ms
> ecdsa 256 bits: 1.6 ms
> 
> So the two are mostly equivalent (with the NIST curve, a brainpool curve
> would probably be slower, and a modern curve such a Ed25519 faster). ECDSA has
> an advantage as soon as the certificate chain is shorter, up to a factor 4 for a
> 0-length certificate chain.
> 
> (Also, this is assuming the same key size and type for all certificates.
> Certainly the best case for overall handshake speed is when the end-entity
> certificate uses ECDSA while CA certificates use RSA.)
> 
> However, in a context where servers need to handle more handshakes per
> second than clients and most handshakes don't use client auth, ecdsa is
> interesting since it transfers some load from the server to the client,
> probably a good news for server operators.

It's particularly good news coming after the hit that 2048-bit RSA caused (note that "sign" and "RSA decrypt" have about the same speed):
 
                  sign    verify    sign/s verify/s
rsa 1024 bits 0.000732s 0.000046s   1365.2  21720.1
rsa 2048 bits 0.004701s 0.000147s    212.7   6810.6

Yoav