4 ms·

Questions: - Do the graphs mean that the "sign" operation of OpenSSL when using ECDSA is many times faster and the "verify" operation is ~4 times slower (compa

Questions: - Do the graphs mean that the "sign" operation of OpenSSL when using ECDSA is many times faster and the "verify" operation is ~4 times slower (compared to RSA)? - I suppose that "sign" is linked to issuing certificates, while "verify" would be involved to checking certificates? (sorry, I'm not a pro with this stuff)

wbl 6y ago
You are exactly correct on both points!
toast0 6y ago
If it were just checking and issuing certificates, faster signing and slower verifying would be a bad tradeoff, since certificates are issued once and used many times; certificate size benefits notwithstanding. The really nice thing performance wise is that when sending a certificate via TLS, you need to sign the TLS exchange up to that point. Making that faster means you can support a lot more connection handshakes with the same server.
- zepearl 6y ago
  Interesting, thank you! (this would have been my next question, hehe)
pinjiz 6y ago
Yes, that is correct! It makes sense to use ECDSA for leaf certificates, because the TLS server can then handle more clients compared to a RSA based certificate of the same strength (the private key operation is much cheaper with ECDSA and is needed for every TLS handshake). The client of course, needs a few more cycles to verify the signature, but that is not noticeable most of the time. IMHO it does not really make sense to use a ECDSA root certificate unless you have a very constrained environment, where every byte counts. The root certificate will never be transferred to the client during a TLS handshake - so the size benefit is minimal (the intermediate certificate will be a bit smaller, because ECDSA signatures are smaller). But the signature validation will take more cycles on the client in every TLS handshake. Other than that it is a good thing that Let's Encrypt now has an ECDSA root. When researchers might find a problem with RSA in the future, we have an alternative ready to use.

wbl 6y ago

You are exactly correct on both points!

toast0 6y ago

If it were just checking and issuing certificates, faster signing and slower verifying would be a bad tradeoff, since certificates are issued once and used many times; certificate size benefits notwithstanding. The really nice thing performance wise is that when sending a certificate via TLS, you need to sign the TLS exchange up to that point. Making that faster means you can support a lot more connection handshakes with the same server.

zepearl 6y ago
Interesting, thank you! (this would have been my next question, hehe)

pinjiz 6y ago

Yes, that is correct! It makes sense to use ECDSA for leaf certificates, because the TLS server can then handle more clients compared to a RSA based certificate of the same strength (the private key operation is much cheaper with ECDSA and is needed for every TLS handshake). The client of course, needs a few more cycles to verify the signature, but that is not noticeable most of the time. IMHO it does not really make sense to use a ECDSA root certificate unless you have a very constrained environment, where every byte counts. The root certificate will never be transferred to the client during a TLS handshake - so the size benefit is minimal (the intermediate certificate will be a bit smaller, because ECDSA signatures are smaller). But the signature validation will take more cycles on the client in every TLS handshake. Other than that it is a good thing that Let's Encrypt now has an ECDSA root. When researchers might find a problem with RSA in the future, we have an alternative ready to use.