I am new to cryptography and I am having a hard time to understand what is the need for DHKE procedure. I think I fully understand the principle in which it happens and also the mathematics behind it however I feel it is not needed (most probably I am wrong that's why I asking you guys here). Let's say a client wants to communicate with a server - everything makes perfect sense with the first part of the handshake:

The client sends: "Hello server, this is my TCP max version, this and that, etc."

Then the server responds: "Hello, I am the Foo server. This is my public key (go check my certificate) this is my signature (so you can be sure it is me and not a 'middle man')"

Now due to the properties of the public-private key encryption, the client can send the server HIS public key (we don't care how, it's public anyway, but still the message can be encrypted with the server's public key) and then the secure communication can begin by using asymmetric encryption - when the client send something to the server it will be encrypted with the server's public key (so only the server can decrypt it) and vice versa (when server has to send something to the client it will be encrypted with the client's public key).

If my understanding is correct the DHKE procedure brings nothing new to the table in terms of security and I don't understand the need for using it (I doubt that the symmetric key encryption/decryption is much more efficient in terms of computing power).

Thanks in advance!


when the client send something to the server it will be encrypted with the server's public key (so only the server can decrypt it) and vice versa (when server has to send something to the client it will be encrypted with the client's public key)

As I understand it, you are suggesting not to bother using symmetric encryption; instead, have both sides exchange messages using public key encryption.

That would be horribly expensive (that is, slow); symmetric schemes are literally thousands of times faster than asymmetric schemes.

For example, on my test machine (using OpenSSL), it would 0.4 microseconds to encrypt a 64 byte message (size selected because that would fit within a single RSA encryption); in contrast, it took 614 microseconds (that is, 1500 times as long) to RSA decrypt the same amount using 2048 bit RSA.

Performance varies a lot depending on the processor, however this sort of huge performance is typical.

What is the need for Diffie-Hellman key exchange when we have assymmetric key exchange?

Well, one could use assymmetric key exchanges to share symmetric keys, and use those symmetric keys to encrypt the actual messages - that certainly can be done (for example, in some ciphersuites in older TLS versions). It wasn't great when dealing with server compromise (which is why newer TLS versions abandoned it), but it did work.

  • $\begingroup$ So in the end it comes to speed and optimization. Thanks for the great explanation! $\endgroup$ – dimitar.d Jan 19 at 14:35
  • 1
    $\begingroup$ @dimitar.d: and ciphertext overhead (which I forgot to mention); public key encryption methods have much more ciphertext expansion than symmetric methods $\endgroup$ – poncho Jan 19 at 14:42
  • $\begingroup$ The reason using asymmetric key exchange to share a value (eg RSA-KEM or RSA-OAEP) isn't used is not because forward-secrecy is a fundamental property of DH (indeed, non-forward secret DH used to be used) but because RSA key generation is slow and public keys are large, so it's less efficient to use RSA in an ephemeral protocol. It's perfectly possible, and most of the post-quantum KEMs will probably get used in such a manner (with the performance hit being even bigger than RSA, but with an actual security benefit). The reason it's not done is that DH is faster for ephemeral exchanges. $\endgroup$ – SAI Peregrinus Jan 19 at 16:41

Using Diffie-Hellman also improves security, as in forward secrecy. There are protocols that use asymmetric keys to verify that the other party is who they say they are, then Diffie-Hellman to negotiate a key to use for symmetric encryption of the actual information exchange.

The attack scenario is the following: An eavesdropper logs all the (encrypted) traffic between two parties. At some later point in time, he is able to obtain the private keys for decryption of that conversation, maybe because a flaw in the algorithm was found.

With just asymmetric + symmetric encryption, the eavesdropper can now read every message that he logged. With the addition of DHKE, he now also would have to crack the DHKE step. Even if this will be feasible due to advances in cryptanalysis, he still might need a lot of computing power to crack DHKE. And he has to do this not once for his traffic log, but for every instance where both parties re-did the DHKE. So most of the communication still stays confidential.

Same thing is true if the attacker could somehow dump the symmetric key from memory of one of the involved machines. Multiple key changes reduce the use of obtaining one instance of the symmetric key.

Take a look i.e. at the protocol that Signal uses. It will change the symmetric keys via DHKE, as frequently as possible (as soon as enough messages were sent back and forth to include another DHKE): https://signal.org/docs/specifications/doubleratchet/

  • 2
    $\begingroup$ Forward secrecy is orthogonal to DH vs something like RSA-KEM or RSA-OAEP to exchange a symmetric key. It's just that DH (or ECDH) is faster and has smaller messages than RSA. Forward-secret RSA is straightforward: Create a random RSA key pair (slow), encapsulate a random value under the recipient's public key, send your public key (huge) and the encapsulated value. Recipient decapsulates the value using their private key. Both parties use a KDF to make a shared symmetric key from the random value. Most of the post-quantum schemes do this, just not using RSA. Still forward secret. $\endgroup$ – SAI Peregrinus Jan 19 at 16:37
  • $\begingroup$ You're correct, I removed that part. Thanks! $\endgroup$ – Christoph Sarnowski Jan 19 at 21:50

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.