From my understanding, one of the major reasons we recommend Diffie-Hellman Ephemeral (e.g. DHE or ECDHE) over non-ephemeral DH, for SSL / TLS, is that compromise of the RSA private key (i.e. private certificate) would allow an attacker to decrypt previously captured conversations. In contrast, ephemeral should prevent decryption unless the attacker is in posession of the key at the time of the conversation.

How does this decryption of non-ephemeral Diffie-Hellman key exchange work in this context? Is it simply a case of observing the unencrypted primitives that are exchanged over the wire? If so, what is the point of using DH, if it provides no additional security over encrypting the key with RSA, and RSA already provides authentication of the server?

  • 1
    I didn't look deeply into useless suites like fixed DH, but I think fixed-DH simply uses a signed DH key instead of an RSA key and thus has the essentially the same security properties. Jun 20, 2013 at 19:35
  • I'm not exactly sure what you're asking,I've probably misunderstood the question but as far as the first part goes, if you have all the traffic logged, you have everything. You look for the handshake, decrypt the pre-master with the private key, together with the random bits sent in plaintext with the Hello messages you can derive the master key. Using the master key you can now decrypt the traffic of previously sessions.
    – Adi
    Jun 22, 2013 at 21:49
  • @Adnan The difference is that DH ephemeral doesn't work that way. If you can observe the exchange data (e.g. through getting the private key at a later date), you still can't decrypt it. You have to have the key at the time and do a MitM attack, to learn the private exchange value of DHE.
    – Polynomial
    Jun 23, 2013 at 15:42
  • @Polynomial But as far as I can see, you're asking about non-ephemeral DH. "How does this decryption of non-ephemeral Diffie-Hellman key exchange work in this context?" also the title "How does non-ephemeral Diffie-Hellman key exchange become compromised in SSL when the RSA private key is leaked?"
    – Adi
    Jun 23, 2013 at 19:40
  • 1
    @Adnan Yes, but I'm asking what the specific difference is. Saying "you just capture the data" doesn't tell me the mechanism by which the secret is revealed, nor does it explain why DHE is immune to the same attack. I'm also interested in what benefit the non-ephemeral DH provides over plain RSA, since I don't see any.
    – Polynomial
    Jun 24, 2013 at 8:40

3 Answers 3


First let's be sure that we talk about the same thing. In SSL, there are "ephemeral DH cipher suites" (DHE) and "non-ephemeral DH cipher suites" (DH).

With DHE, the server private key (the permanent one, the one which is stored in a file, and whose public key is in the server certificate) is of type RSA (DHE_RSA cipher suites) or DSS (DHE_DSS cipher suites), and is used only for signatures. The server generates a new random DH key pair (the private key will not be stored, which is how perfect forward secrecy is achieved: a private key cannot be stolen afterwards if it has never been stored), and sends the public key to the client, in a message which the server signs with its RSA or DSS private key.

With DH cipher suites, the permanent server private key is a DH private key. The server certificate contains the DH public key. The server cannot see its RSA key be stolen because the server does not have a RSA key. The server only has a DH key. When a cipher suites is called "DH_RSA", it means "the server key is a DH key, and the server certificate was issued (i.e. signed) by a Certification Authority who uses a RSA key".

Stealing the DH private key of one party involved in a DH key exchange allows ulterior reconstruction of the shared secret, just like RSA. In "ephemeral DH", the PFS is obtained through "ephemeral", not through "DH". Technically, it would be possible to have "ephemeral RSA" but it is not done in practice(*) because generating a new RSA key pair is kinda expensive, whereas producing a new DH key pair is cheap.

(*) Ephemeral RSA keys were possible with old versions of SSL as part of the "export" cipher suites, meant to comply with the pre-2000 US export regulations: the server could have a 1024-bit signature RSA key, and generate an ephemeral 512-bit RSA key pair for key exchange, used in encryption mode. I don't recall having ever seen that in the wild, though, and it is a moot point since US export regulations on key sizes were lifted.

Non-ephemeral DH cipher suites exist in order to allow servers with DH certificates to operate. DH keys in certificate exist because in older times, RSA was patented but DH was not, so standardization bodies, in particular NIST, were pushing DH as the must-implement standard.

Reality caught up with that, though. I have never seen a SSL server using a DH certificate. Everybody uses RSA. The RSA patent expired a decade ago anyway.

  • 1
    That makes SO MUCH more sense now. I had never considered the idea that the DH key pairs could be generated and thrown away per session. Thanks! :)
    – Polynomial
    Jun 28, 2013 at 16:30
  • SSLv3 TLSv1.0 and 1.1 define DH_{RSA,DSS} as cert contains DH key and is signed (by CA) using RSA or DSA respectively, but TLSv1.2 drops the ciphersuite-based restriction on cert signature and adds an extension (SigAlgs) which restricts all signatures; see 5246 7.4.2 just after the itemized list. And similarly for fixed-ECDH. Nov 7, 2017 at 22:36
  • @TomLeek One correction maybe, I read the server certificate will not contain the DH public key. It is shared in a different Server Key Exchange message. Could you please confirm this? Jul 16, 2018 at 11:57
  • @AnonymousPlatypus: no, the bear was right (as usual). ServerKX contains the ephemeral DH key for (very common) ephemeral DHE_$auth (note the E) or 'anonymous' (DH_anon) keyexchange, but is not used at all for (very rare) 'static' DH_$obsauth (no E) which has the static/fixed key in the cert. See rfc5246 et pred 7.4.3 and 7.4.2. And similarly for ECDHE and ECDH_anon versus ECDH, see rfc4492. Jul 21, 2018 at 14:37

For SSL/TLS, we need 2 things:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

A few ways of doing both:

Most common: TLS_RSA_WITH_AES_...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).


RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Preferred, because you get Perfect Forward Security (PFS)

Not common: DH_RSA_... (this is the non-ephemeral DH in OP's question)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

The case you are referring to is the 3rd ("Not common") and as you can see, RSA is used neither for 1 (Authentication) nor for 2 (computing symmetric key) and so there is no question of RSA private key being leaked. The RSA in DH_RSA could be misleading but as Tom Leek mentioned, the Administrator of the server will provide credentials and their DH public key to a CA (Certificate Authority) who will then sign the DH public key with the CA's RSA private key.

  • Maxim, by authentication, I mean that the client authenticates the server. Note that the server only presents a certificate, not proof that it has the corresponding private key. The client authenticates the server indirectly --- it generates a random pre-master-secret, encrypts it with server's RSA public key and sends it to server. Both the client and server can compute the master secret using the pre-master secret. Only the legitimate server will have the RSA private key to decrypt the encrypted pre-master secret and compute the same master secret. Refer to Section of RFC 5246 Apr 14, 2020 at 22:56
  • Maxim, the client encrypts the pre-master secret and sends it to the server, not the other way around. Apr 14, 2020 at 23:01
  • You wrote that RSA is used for “1 (authentication)”. What do you mean here by “authentication” in terms of using the RSA key data from the server’s certificate? There is only one operation where this key is used, not two as you wrote. In “TLS_RSA_WITH_AES_...” it is only used for “key transport” (the client encrypts, and the server decrypts the “premaster secret”), while in “TLS_(EC)DHE_RSA_WITH_AES_...” it is only used to sign by the server (and verify by the client) the ephemeral key, as you correctly pointed out. Apr 15, 2020 at 17:33
  • 1
    Maxim, there is only one step and not 2 steps. This is why I said "The client authenticates the server indirectly". A bogus server will not be able to decrypt the encrypted pre-master secret and so authentication fails. Only the legitimate server has the RSA private key, the fact that it can decrypt and get the pre-master secret and compute same symmetric keys to encrypt/decrypt traffic is proof that the server is who it claimed to be in the certificate. As only one party (the client) generates the pre-master secret, this is called key-transport and not key exchange. This is TLS_RSA_WITH_AES. Apr 15, 2020 at 19:34
  • 1
    Maxim, in TLS_(EC)DHE_RSA_WITH_AES (ephemeral diffie hellman), the server, in addition to presenting certificate that contains its RSA public key, it also signs its ephemeral DH parameters with its RSA private key and sends it to client. Client uses server's RSA public key to verify the signature on the DH parameters. If signature check succeeds, authentication succeeds and client sends its ephemeral DH parameters to server. Both parties use the DH parameters to compute the same pre-master secret. As both parties contribute material to compute the pre-master secret, this is called key exchange Apr 15, 2020 at 19:34

You've asked about the use of non-ephemeral (static) Diffie-Hellman key exchange and its advantages or disadvantages over encrypting the key session key (premaster secret) with RSA.

In TLS_DH_RSA_WITH_... the signature algorithm (RSA/DSS) indicates the signature algorithm the CA used to sign the certificate and there is no signature as part of the handshake; if the server arrives at the same session key, then it must have the matching DH private key. (Mike Ounsworth)

Thus the "RSA" or "DSS" part in the "TLS_DH_" cipher suite is misleading. It only denotes an algorithm used by the CA to sign the DH parameters (public key), not the actual signature algorithm used during TLS handshake.

In “TLS_DH_” cipher suites, there are two ways for the client to provide its public DH parameters (public key) to the server:

  1. via the client certificate;
  2. via the ClientKeyExchange message of ClientDiffieHellmanPublic type.

If the client has sent a certificate which contains a suitable Diffie-Hellman key (for fixed_dh client authentication), then Yc is implicit and does not need to be sent again. In this case, the client key exchange message will be sent, but it MUST be empty. (RFC 5246,

When using static Diffie-Hellman with a client certificate, you get mutual authentication in one shot, because a client certificate and a server certificate are used to generate the session keys.

DH denotes cipher suites in which the server's certificate contains the Diffie-Hellman parameters signed by the certificate authority (CA). [...] The server [...] request a Diffie-Hellman certificate. Any Diffie-Hellman certificate provided by the client must use the parameters (group and generator) described by the server. (Section A.5 of RFC 5246)

Note that certificates with DH parameters are rather rare anyway.

In theory, if you compare speed and security of DH vs RSA, there are no major differences (nevertheless, there are some details).

In practice, since public CAs no longer issue certificates with the DH parameters, you cannot use "TLS_DH_" cipher suites, so RSA is the only choice between the two non-PerfectForwardSecrecy algorithms that you have mentioned.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .