Re: [TLS] Safe ECC usage

[Yoav Nir <[e-mail]>]

On Oct 1, 2013, at 8:26 PM, Manuel Pégourié-Gonnard <[e-mail]> 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