Subject: Re: [TLS] Safe ECC usage

From: [email-masked] (Martin Rex)
Date: Tue, 1 Oct 2013 15:38:19 +0200 (CEST)

Yoav Nir wrote:
> 
> Martin Rex <[email-masked]> wrote:
> > 
> > I currently do not see any benefit from using EC for digital signatures,
> 
> 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.

So there would be a penalty for EC signatures on certificate chains,
CRLs, OCSP and whathaveyou.

ECDH with curve25519 could be made a small code change, local to TLS,
and affecting _NONE_ of the stuff that deals with X.509 certificates.
And you need only one server certificate (RSA-2048) for everything.

> 
> > but instead a huge amount of code, complexity and IPR issues (did you
> > look at the CertiCom idea how to charge?).
> 
> Yes, I have: "If the standard is adopted, Patent Holder will not assert
> any claims of any patents owned or controlled by the Patent Holder
> against any party for making, using, selling importing or offering
> for sale a product that implements the Standard?"
> (weird capitalization theirs, not mine)

They want to charge EC cert issuers (CAs) for issuing EC certs.
The use of ECDHE with parameters authenticated by RSA certs would be
royalty free.

> 
> Also, there's RFC 6090 on how you can do all the ECC operations
> with 1994 technology.

Our current crypto codebase as well as the PKIX codebase is EC-free,
and FIPS 140-2 certified.

The amount of code necessary to implement EC (crypto, PKIX, rfc4492)
is significant, and without any substantial benefits, the lid of that
can is probably not going to be reopened soon (~3-5 years).

> 
> IANAL and neither are you. What makes you think that the IPR issues
> apply to P-256 more than they do to Curve25519?

CertiCom intends to charge for X.509 certs.
Don't use it for signing.

> 
> > i.e.
> > a small number of new cipher suites and an additional ClientKeyExchange
> > and ServerKeyExchange variant specifically tailord for curve25519, so
> > that there are real benefits to a full-blown and generic rfc4492 TLS EC
> > crypto.
> 
> ECDHE_RSA is slower than plain RSA. ECDHE_ECDSA is faster.

What openssl-1.0.1c says, ECDHE_DSA is about par.

Maybe there should be a middle-ground between RSA and ECDHE_RSA.
Why is it OK for the RSA ciphersuites to perform a time-based validation
of the Server certificate, but not OK to perform a time-based validation
of the signature on the (EC)DH parameters?

>From the performance perspective, the ration of TLS session resumes
vs TLS full handshakes on a server should be 10:1 or better, otherwise
something is going terribly wrong with either the servers session cache
or the client's session caching strategy.

>
> Once you've dipped your toe in the ECC pool, there's no reason
> not to have it in the signature as well.

We haven't dipped our toe yet, and the complexity around it is certainly
no motivator to consider adding this through software maintenance.

-Martin

---

From: Johannes Merkle <[email-masked]>
Date: Tue, 01 Oct 2013 18:22:07 +0200

> 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.

Johannes

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Tue, 01 Oct 2013 19:26:56 +0200

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.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Oct 2013 17:43:16 +0000

> 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