Re: [TLS] Safe ECC usage

Manuel Pégourié-Gonnard <mpg@elzevir.fr> Tue, 01 October 2013 17:29 UTC

Return-Path: <mpg@elzevir.fr>
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 D234A21E8085 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 10:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 NFNdcBCoMjD4 for <tls@ietfa.amsl.com>; Tue, 1 Oct 2013 10:29:15 -0700 (PDT)
Received: from mordell.elzevir.fr (mordell.elzevir.fr [IPv6:2001:4b98:dc0:41:216:3eff:feeb:c406]) by ietfa.amsl.com (Postfix) with ESMTP id 4439B21E81B9 for <tls@ietf.org>; Tue, 1 Oct 2013 10:29:14 -0700 (PDT)
Received: from thue.elzevir.fr (unknown [IPv6:2a01:e35:8a5d:80b0:be5f:f4ff:fe2c:95bc]) by mordell.elzevir.fr (Postfix) with ESMTPS id 72298160E7 for <tls@ietf.org>; Tue, 1 Oct 2013 19:29:12 +0200 (CEST)
Received: from [192.168.0.124] (unknown [192.168.0.254]) by thue.elzevir.fr (Postfix) with ESMTPSA id 5BD6529956 for <tls@ietf.org>; Tue, 1 Oct 2013 19:29:11 +0200 (CEST)
Message-ID: <524B05E0.10103@elzevir.fr>
Date: Tue, 01 Oct 2013 19:26:56 +0200
From: Manuel Pégourié-Gonnard <mpg@elzevir.fr>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5
MIME-Version: 1.0
To: tls@ietf.org
References: <20131001133819.CAE281A9CB@ld9781.wdf.sap.corp> <524AF6AF.1070503@secunet.com>
In-Reply-To: <524AF6AF.1070503@secunet.com>
X-Enigmail-Version: 1.5.2
OpenPGP: id=98EED379; url=https://elzevir.fr/gpg/mpg.asc
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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:29:15 -0000

On 01/10/2013 18:22, Johannes Merkle wrote:
>>> Other than certificate size and the speed of making those
>>> calculations?  Really, try "openssl speed rsa2048 ecdsap256" on any
>>> Linux or Mac machine.
>>
>> openssl 1.0.1c x86_64 tells me ecdsap256 is 10x faster than rsa2048
>> for signing and 10x slower than rsa2048 for verifying.
> 
> RSA is much faster for signing than for verifying, while for ECDSA the
> time for these operations are quite similar.
> 
> So lets assume, ECDSA singing or verifying takes 1/10 s, then RSA
> signing takes 1 s and verifying 1/100 sec. Makes 0.2 s for ECDSA based
> handshake (one signing and one verifying operation) and 1.01 s for
> RSA. That is a huge difference.
>
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.

Manuel.