6

My question is about the client and server performance for (EC)DHE. I am having difficulties in understanding this picture (which is based on numbers from Ivan Ristic' book "Bulletproof SSL and TLS").

Let's start with the third row "RSA 2048, DHE 2048". I can understand that client and server computation times differ because creating a signature is different from verifying it.

I understand that ECDHE is faster than DHE and therefore the numbers in the second row are smaller than the ones in the third row.

My questions are:

  1. The effort for DHE and ECDHE is identical for client and server, isn't it?
  2. Why is the client's computation time for "RSA 2048, ECDHE 256" smaller than the server's while for "RSA 2048, DHE 2048" it is the other way around?
  • Wouldn't be this question for the crypto-stackexchange? – KanekiDev Mar 8 '17 at 9:14
  • It cannot be migrated with an open bounty, but yes, that would have made sense – Rory Alsop Mar 8 '17 at 9:25
  • The bounty award period will be over soon. Can somebody then please move this question to cryptography? – HorstKevin Mar 15 '17 at 9:23
2
+25

DHE uses modular arithmetic to compute the shared secret. ECDHE uses algebraic curves to generate the key, therefore it has lower computational, storage and memory requirements.

DHE is considerably slower than ECDHE. If you want some actual numbers here they are:

Key exchange    Parameters               Transactions/sec
DHE-RSA         1024-bit RSA key,
                1024-bit DH parameters        347.64

ECDHE-RSA       1024-bit RSA key,
                192-bit ECDH parameters       612.25


DHE-RSA         1776-bit RSA key, 
                1776-bit DH parameters        97.62

ECDHE-RSA       1776-bit RSA key,
                192-bit ECDH parameters       349.53

As you can see, the performance penalty for DHE increases a lot more when increasing the number of bits. If you really want the best of both worlds, you could use ECDHE-ECDSA and you have both forward secrecy and efficiency.

Here you can find other independent results that should give you relevant info.

The effort is not at all identical. The client is never a problem. You will only notice the performance differences on the server (because there is one server and many possible negotiating clients - so only in the case of 1 client and 1 server the effort will be equal).

-EDIT-

So, to conclude: 1. Yes for one client. No for more concurrent clients, for obvious reasons. 2. Both assumptions are incorrect. On identical machines, the computation time will be similar in both cases.

  • 1
    As I wrote in my question: I know that ECDHE is faster than DHE. What I don't know is: Where does the asymmetry between client and server come from? If you look at the plain DH protocol it looks the same for both, client and server. – HorstKevin Mar 8 '17 at 12:54
  • I know that the client has a very hard time to validate the received prime number and generator. The server producing those numbers does not need to validate them on each handshake. (of course clients also can just skip additional checks since they are not all possible anyay - most even skip the check for safe primes) – eckes Mar 13 '17 at 20:33
  • It's not about 1 client and one server. Most standardized protocols based on ECDH derived a symmetric key from using some hash-based key derivation function. The shared secret calculated by both parties is equal, but you have one server and many clients. For the client there is one calculation, for the server is as many as the number of negotiating clients. I have added that in the answer. – Overmind Mar 14 '17 at 6:11
  • 2
    Both of my questions remain unanswered: 1. The effort for DHE and ECDHE is identical for client and server, isn't it? 2. Why is the client's computation time for "RSA 2048, ECDHE 256" smaller than the server's while for "RSA 2048, DHE 2048" it is the other way around? – HorstKevin Mar 15 '17 at 9:57
  • 1
    1. Yes for one client. No for more concurrent clients, for obvious reasons. 2. Both assumptions are incorrect. On identical machines, the computation time will be similar in both cases. – Overmind Mar 15 '17 at 10:16
0

RSA has an unfortunate imbalance in the computation effort needed by client and server.

The server needs to do more work when decrypting the clients offer because normally the public exponent is chosen much smaller in server certificates. The private modulus 'd' can't be too small (Boneh & Durfee: Cryptanalysis of RSA with private key d less than N^0.292).

This has the effect that the client needs to carry out only a few modular multiplications and can use square-and-multiply optimization, whereas the server needs to do the exponentiation with the large private exponent.

Fortunately the server has more knowledge about the private key, so it can use the Chinese Remainder Theorem (CRT) optimization, it can divide the expensive exponentiation with the modulus n into two. The cost of doing modular exponentiation increases by the cube of the number of bits in the modulus. Doing two exponentiation calculations (mod p and mod q) is therefore more efficient (details). But it is still much more work than the client has to do. And then the server also needs to do RSA blinding to protect against timing attacks

(I am currently not sure why it is the other way around for DHE or ECDHE. For EC I guess it is related to the need for checking the parameters on the curve)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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