9
$\begingroup$

I have a question about the performance benefits (in terms of server-side CPU load) of ECC (Elliptic Curve cryptography) cipher suites in SSL/TLS.

It is a known fact that ECC is very good for performance, it offers a good "security / key length" ratio.

But ECC kan be used for 2 things in SSL/TLS sessions:

  • ECC key establishment: ECDHE algorithm.
  • ECC authentication: ECDSA algorithm with ECC server certificate.

So I am wondering: do you need the 'full' ECC package (ECDHE + ECDSA = ECC key establishment + ECC server certificate) to get a substantial performance gain with SSL, or does ECDHE (ECC key establishment) already provide the largest portion of the possible performance gain?

Or, to make this question less abstract, let's consider 3 SSL cipher suites:

a) Non-ECC cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (DHE-RSA-AES256-SHA256). Here ECC is not used at all.

b) Partial ECC cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ECDHE-RSA-AES256-SHA384). Here ECC is used for DH key establishment, while RSA is used for server authentication (RSA server certificate).

c) Full ECC cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ECDHE-ECDSA-AES256-SHA384). Here ECC is used both for DH key establishment and for server authentication (ECC server certificate).

I assume that scenario C is better (performance wise) than scenario B, which in turn is better than scenario A. But: where exactly would scenario B be positioned?

If scenario A = 1% (bad performance: high server CPU load) and scenario C = 100% (good performance: low server CPU load), then how far can you get with scenario B: 10%, 50%, 90% ...?

I hope the question is clear and that someone knows the answer or can point me to some documentation about this subject.

Thanks in advance!

Bert

Improve this question
$\endgroup$
1
  • $\begingroup$ You need to multiply the cost delta per key exchange, as answered by Raoul722, times the number of key exchanges you need to handle your traffic, which can vary a lot depending on your server(s), client(s), protocol(s), and users, and particularly the extent to which a single connection handles multiple requests or a single key exchange handles multiple connections; see (cross) security.stackexchange.com/questions/100054/… $\endgroup$
    – dave_thompson_085
    Feb 11, 2017 at 5:50

1 Answer 1

Reset to default
4
$\begingroup$

It is hard to give a precise percentage as you expect because performances depend on the hardware platform. But let's get into the subject.

The only difference between TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 and TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 is the signature algorithm.

Whatever, one will have to generate an ECC key pair on the fly in order to perform an ECDHE. Then, this key pair will be signed using the certificate private key. If the certificate contains a RSA public key, then the generated ECC public key will be signed using RSA. Otherwise (i.e. if it contains an ECDSA public key) it will be signed using ECDSA. Also note that one will have to verify the peer signature on top of generating his own.

So your question is equivalent to comparing RSA to ECDSA, I suggest you to take a look at How do RSA and ECDSA differ in signing performance? and Signatures: RSA compared to ECDSA.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ SSL/TLS client signs (and thus server must verify) its half of ephemeral key exchange only when using client authentication (also called mutual authentication or client certificate) which is optional and pretty rare, see (cross) security.stackexchange.com/questions/23880/… . Also technically server signs DHE parameters or ECDHE curveid plus pubkey, and client if auth used signs handshake sequence including pubkey, but those don't matter for performance. $\endgroup$
    – dave_thompson_085
    Feb 11, 2017 at 5:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.