These questions revolve around DH and ECDH vs DHE and ECDHE. Specifically within the context of TLS/SSL. There are three questions in total (and a fourth bonus question).

The goal of using Diffie-hellman at all in TLS/SSL is to avoid the case where the contents of the certificate are the sole source for seed value for generating symmetric keys. In a non Diffie-Hellman TLS/SSL session (aka, an RSA key exchange), if an attacker where to capture all the traffic, then at some time in the future acquire the private key, they can decrypt the entire content of the previously captured data.

Using Diffie-Hellman, however, a compromised private key won't instantly allow the attacker to decrypt all the prior captured cipher text. Which is why you'd want to use Diffie-Hellman for key exchange, instead of RSA.

But from my reading, DH and ECDH perform the diffie-hellman key exchange using values stored in the certificates. My first question: is specifically which of the DH values are stored in the Public Certificate and Private Key?

Having said that, my second question is does using DH/ECDH provide forward secrecy?

Lastly, it would seem that there is a bigger security increase going from DH/ECDH to their ephemeral counterparts (DHE/ECDHE), than there would be from going from RSA to DH/ECDH. Given that, my third question is what would the benefit be (if any) of using DH/ECDH instead of the ephemeral counter-parts?

bonus question: Does DH/ECDH have much usage in present day SSL/TLS implementations? Or is it mostly just RSA and DHE/ECDHE that are typically used for key exchanges?


2 Answers 2


A Diffie-Hellman key agreement has the following general form, presuming it is done in a group $G$ of order $q$ with generator $g$:

  • $A$: Generate $x \in \mathbb{Z}_q$ at random. Calculate $X = g^x$
  • $B$: Generate $y \in \mathbb{Z}_q$ at random. Calculate $Y = g^y$
  • $A \to B$: $X$
  • $B \to A$: $Y$
  • $A$: Calculate $S = Y^x$
  • $B$: Calculate $S = X^y$

First question: The certificate of $A$ contains the public key $X$ and a reference to the group $G$. The group might either be explicitly specified (as is common in the case of DH) or referenced by an identifier (as is common in the case of ECDH). The corresponding private key is the secret exponent $x$. Note that such certificates are rare; most commercial certificates contain RSA public key and might not be used for DH or ECDH (obviously).

Second question: No. If static-DH/ECDH or ephemeral-static-DH/ECDH is used, at least one party will always use the same private key. If that private key is apprehended by an adversary, all prior shared secrets that involve the key pair that private key belongs to, might be calculated from the protocol messages.

Third question: The security of RSA key transport trivially requires that the client (who generates and sends the RSA encrypted pre master secret) has access to a good (pseudo) random number generator. This is true for all attack scenarios; if the client random generator is compromised, RSA key transport will provide no secrecy. For DH/ECDH on the other hand, there are attack scenarios where the client doesn't even need a random generator.

Fourth question: AFAIK DH/ECDH are rare for SSL/TLS, because they require that the server has a DH/EC certificate, and those are rare.

  • $\begingroup$ Brilliant answer, thanks! One quick question. When you answered the first question, you said "...The group might be explicitly specified (as is common in the case of DH) or referenced by an identifier (as is common in the case of ECDH)." For DH, do you mean that the Public Certificate will also include (along with X), the DH Group#, aka, 1, 2, or 5? If so, what did you mean by an "identifier" which is the case of ECDH" $\endgroup$
    – Eddie
    Commented Mar 31, 2014 at 14:42
  • $\begingroup$ A diffie-hellman public key will, when encoded for a X.509 certificate, be coupled with it's domain parameters, which includes the prime modulus $p$, generator $g$, group order $q$ and (optionally) co factor $j = (p-1)/q$. An EcPublicKey is otoh commonly coupled with an object identifier signifying which standard group the key belongs to, such as P-256, P-521 etc. $\endgroup$ Commented Mar 31, 2014 at 14:47

I want to answer the third question, as all other questions are brilliantly answered.

In TLS handshake as in diagram:

TLS handshake

In DH/ECDH, the "ServerKeyExchange" message will be empty since the value g^x is already present in certificate. This can save server a lot of computation. This will be a advantage in servers with heavy load and save time in CPU computation. In their ephemeral counterparts, the server needs to send ServerKeyExchange message and therefore has to compute g^x value for its secret x.


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.