I understand how Diffie-Hellman algorithm can be used to agree on a common key between a client and server. I am struggling to understand the three variations of Diffie_Hellman - Anonymous Diffie-Hellman, Fixed Diffie-Hellman and Ephemeral Diffie-Hellman. Is DHE used along with AES for forward secrecy ? Can someone explain what these variations are and how they are used in TLS ?
-
1All 3 variations are described at [wiki.openssl.org:Diffie Hellman](https://wiki.openssl.org/index.php/Diffie_Hellman#Diffie-Hellman_in_SSL.2FTLS). Just cut+paste the information here would answer the question. But just duplicating easy to find information is likely not the idea of this site. So please study the existing explanation and if you have trouble understanding it please ask a more specific question. – Steffen Ullrich Jan 30 '21 at 22:21
-
Thanks for the link. I read that already. Here is what it says about Ephemeral Diffie-Hellman- "Ephemeral Diffie-Hellman uses temporary, public keys. Each instance or run of the protocol uses a different public key. The authenticity of the server's temporary key can be verified by checking the signature on the key" I thought the authenticity of the server can only be verified using digital signatures. How is Ephemeral Diffie-Hellman verifying the authenticity of the server by itself ? – RKA Jan 30 '21 at 22:56
-
1Please don't bury the necessary details of your question in the comments, but edit the question instead. Also, it says nothing about verifying the server authenticity - it is about *"authenticity of the server's __temporary key__"*. – Steffen Ullrich Jan 30 '21 at 23:08
-
2The answers to ["Confusing about Ephemeral Diffie-Hellman"](https://security.stackexchange.com/questions/12052/confusing-about-ephemeral-diffie-hellman) may also be helpful. – Gordon Davisson Jan 31 '21 at 00:04
1 Answers
These three variants of Diffie-Hellman all operate in roughly the same way. In all three, the client and the server pick a random number (private key), compute a value (their public key) based on that random number, and then share that public key with the other side.
In anonymous Diffie-Hellman, neither side signs or otherwise authenticates their public key. As a result, you can determine that you computed a shared secret with somebody, but not who that party is. This leaves you vulnerable to a man-in-the-middle attack. Usually this is also an ephemeral key exchange.
In fixed Diffie-Hellman, one side (usually the server) presents their public key in a certificate (usually signed by a certificate authority). If this is a signed certificate, then the fact that owner of the certificate can negotiate a successful connection is proof that it controls the key and therefore authenticity is established. However, because this key is fixed in a certificate, if the corresponding private key is leaked, all data generated using that key is compromised.
In ephemeral Diffie-Hellman, both sides generate a new, random public and private key each time. The server (and the client, if they are authenticated) signs their Diffie-Hellman public key with the private key in the server certificate (which is usually RSA or ECDSA). The fact that both sides can negotiate a connection successfully and the Diffie-Hellman public key is signed proves authenticity of the connection. An attacker impersonating the server would be limited to reusing a previous signed DH public key sent by the server, but because it did not know the private key, it couldn't successfully negotiate a connection. Because the Diffie-Hellman key material is fresh each time, as long as both sides discard their Diffie-Hellman private key when the connection is done, this provides perfect forward secrecy.
Anonymous Diffie-Hellman is not practically used these days since it provides no authentication. For situations where authentication is not important, using a self-signed certificate is almost as easy. Fixed Diffie-Hellman is not practically used in TLS because ephemeral Diffie-Hellman provides perfect forward secrecy and using that with an RSA or ECDSA certificate is easier and better supported. However, fixed Diffie-Hellman remains useful in situations where the protocol is not online and thus ephemeral options are more difficult.
Much of this also applies to other protocols, such as SSH. However, in the SSH protocol, the signature is not over the public key, but over a hash of the negotiated secret. This is also a secure approach and also provides perfect forward secrecy.
![](../../users/profiles/242928.webp)
- 7,828
- 16
- 15
-
Thanks for the explanation. Since the anonymous Diffie-Hellman and fixed Diffie-Hellman are vulnerable to attacks, are they still used ? – RKA Feb 01 '21 at 17:33
-
-
1I don't think I've ever seen DH parameters in a certificate. Even with "fixed" or non-ephemeral DH, the certificate will probably only contain an RSA or (maybe) ECDSA public key; the server will still need to separately sign and transmit the DH parameters (signing using its private key, the one corresponding to the public key in the cert) for the client to authenticate those parameters. – CBHacking Feb 02 '21 at 04:58
-