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. – CodesInChaos Jun 20 '13 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 '13 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 '13 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 '13 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 '13 at 8:40

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.

|improve this answer|||||
  • 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 '13 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. – dave_thompson_085 Nov 7 '17 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? – Anonymous Platypus Jul 16 '18 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. – dave_thompson_085 Jul 21 '18 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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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