Diffie–Hellman offers secure key exchange only if sides are authenticated. For authentication, sides are using public/private key. So if side A knows the public key of the side B, then A can simply use that key to encrypt the message (or the new session key).

Why bother to use separate key exchange algorithm?


1 Answer 1


I assume you're talking about SSL/TLS or a similar protocol. In these protocols there are two reasons to use Diffie-Hellman:

  1. Your certificate only supports signing
    Either it is an RSA certificate restricted to signing, or it uses an algorithm that doesn't support encryption, such as DSA or ECDSA.
  2. Forward security - What happens if the server's private key gets leaked somehow?
    If you simply encrypted the session key to the server's public key, all past communication with that server can be decrypted. Which is very bad.
    If an ephemeral Diffie-Hellman key-exchange was used, a private key leak won't compromize past communications, since the keys used for the key exchange are long gone, and the leaked long term key was only used for authentication and not for confidentiality.
  3. You don't know the public key of the other side
    There are situations where you don't know the other side's public key, but you have a different way to authenticate them. In that case you can use anonymous Diffie-Hellman together with that other way. For example TLS supports authentication based on a symmetric shared secret in a way that's secure against MitM.

Some other protocols such as CurveCP use EC Diffie-Hellman for both authentication and key-exchange. In this case they profit from the performance advantage elliptic curves have over RSA.


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.