I just read this post here: Why do we need asymmetric algorithms for key exchange? that asserts that in public key cryptography when asymmetric keys are used to secure communications, for parties to agree on a common shared secret, the following method is used:

So, say you want to send me a very long message, using asymmetric encryption. Here's what you'd actually do:

(1) Pick a random key for use with a symmetric (fast) cipher. Encrypt your message using that (fast) cipher and key. Send me that encrypted message.

(2) Then use asymmetric (slow) encryption to encrypt the following message and send it to me

"Hi, I just sent you a message encrypted using the BLAH symmetric cipher with key ABCDE123456."

So, you use your peer's public key to encrypt a shared secret, send the peer the encrypted secret, and then the peer decrypts the secret with his or her private key. In this way, you can use the big certificates to authenticate parties as well as use them to establish a shared secret.

This makes sense, but i have to be missing something. Why/how would DH be used here as well? I see that there are plenty of schemes like RSA2048 that have large keys, which i assume would be used in this way above, but also incorporate DH in their cipher suite:RSA_DHE, ECDHE.

What benefit does the DH component add? What can it do, now that we can establish a shared secret with the public keys in the certificates?


2 Answers 2


DH is often used to build session keys, which are used to provide forward secrecy. If you only use the public key in the certificate, then corrupting the private key may reveal all the previous encrypted messages. The attacker can first decrypt the symmetric keys then decrypt previous messages if it keeps records of the previous communications. Using DH can prevent this. Even if you have the private key, you still can not figure out any previous DH results to get the symmetric keys. In this way, the privacy of previous messages is still maintained.


Shan Chen's answer covers the use of DH to provide forward secrecy, so I won't cover that. There is an additional use, with a different scheme to exchange messages.

Instead of using public-key cryptography to encrypt a message use it to sign a message.

  1. Exchange DH parameters and public keys
  2. Perform the DH key derivation
  3. Sign some sort of challenge value or session hash to prove identity. This uses a long-term public key in a certificate.

In practical protocols there tend to be slightly different steps, and clients won't necessarily have to sign anything to authenticate to a server. In this sort of scheme no message is directly encrypted with the long-term public key. Indeed several modern public key schemes can't encrypt, only sign or perform Diffie-Hellman key derivation. E.g. Curve25519 is only for DH, and EdDSA is only for signing.


Your Answer

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

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