I am trying to understand the working of TLS. I understand that there are various way to generate the master secret used to encrypting the data. Such as DH (Ephemeral DHE) and RSA. I understand that, when using RSA, the client generated pre-master key is encrypted by server's public key and is sent back to server for the computation of the master secret. But what about the process when using DHE?

I see that DH public keys of both client and server is used to compute the Master secret? But, is the DH public key the same as the Server's public key?

In Layman's term, is the RSA public key considered as the server's public key?

2 Answers 2


Short answer: it can be, but it's complicated and it depends on what kind of certificate the server has and which TLS cipher suites it's configured to use.

This answer is essentially a copy of this openssl wiki page. Let's go through some examples.

Pure RSA

For these, the server's certificate will contain an RSA key and you will use a cipher suite like


The session key will be generated client-side and sent to the server encrypted with the server's RSA key. For the authentication part of the handshake, the server will use the same RSA key to produce a signature (I think).

Static DH - anonymous

For these, the server uses the same DH keys for each connection, however there is no certificate, so no way for the client to check that this key actually belongs to the server and not to a man-in-the-middle. You will use a cipher suite like


Note: clearly this is insecure.

Static DH - with certificate

For these, the server uses the same DH keys for each connection and the public key will be placed in the server's certificate (a DH certificate rather than the more common RSA certificate). You will use a cipher suite like


As noted here, the signature algorithm (RSA/DSS) indicates which 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.

Note: this is old and deprecated, people prefer DHE now.

Ephemeral DHE + RSA

For these, the server's certificate will contain an RSA key and you will use a cipher suite like


Since the DH is ephemeral, a new DH key will be generated for each new connection so there is no need to put it in a certificate. The RSA key is used to sign a challenge response to prove that the server is who they say they are. These are the preferred ciphers these days.

  • OP is talking about the use of DH vs RSA as a KEM, not certificates.
    – forest
    Commented Jul 20, 2018 at 3:46
  • @forest Why not both? The question asks about "the server's public key",, which by definition is the certificate. When're using a KEM other than DHE, it's the KEM key that goes in the certificate. Commented Jul 20, 2018 at 11:45
  • 1
    DH_anon (and ECDH_anon) uses no certificate at all; that's what 'anonymous' means in the SSL/TLS context. DH_$auth (and ECDH_$auth) (even though which $auth is ignored in 1.2) does use a certificate containing a long-term DH (or ECDH) key. Commented Jul 20, 2018 at 12:16
  • @dave_thompson_085 Right, thanks for calling out my misunderstanding :) Commented Jul 20, 2018 at 12:47
  • My browser suggested "@dave_thompson_085 pointed out some stupids that I made." for the Edit Comment, so this is not the first time you've kept me honest. I thank you for it :P Commented Jul 20, 2018 at 12:59

CloudFlare explains that Diffie-Hellman and RSA, both used in key exchange mechanisms, have advantages.RSA and DH handshake Keyless SSL: The Nitty Gritty Technical Details .

The RSA and DH handshakes both have their advantages and disadvantages. The RSA handshake only uses one public key algorithm operation, RSA. A DH handshake with an RSA certificate requires the same RSA operation, but with an additional DH operation. Given that the certificate is RSA, the RSA handshake is faster to compute. Public key algorithms like RSA and DH use a lot of CPU and are the slowest part of the TLS handshake. A laptop can only perform a couple hundred RSA encryptions a second versus around ten million per second of the symmetric cipher AES.

The DH handshake requires two algorithms to run, but the advantage it brings is that it allows key establishment to happen independently of the server’s private key. This gives the connection forward secrecy, a useful property that protects conversations from being decrypted after the fact if the private key is somehow exposed. The DH version of the handshake also opens up the possibility of using non-RSA certificates that can improve performance, including ECDSA keys. Elliptic curves provide the same security with less computational overhead. A DH handshake with and elliptic curve DSA certificate and elliptic curve Diffie-Hellman key agreement can be faster than a one-operation RSA handshake.

I believe Diffie-Hellman and its TLS/SSL usage will further explain.

Presuming the "server's public key" is used for authentication, then no. The DH public key and the server public key, are not the same. However, I have seen very much mixed opinions on this matter. TLS 1.2 appears to use DH and RSA for the key exchange mechanism. DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network.

  • My mistake, I associated public-key cryptography with asymmetric cryptography. DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network. I will correct the mistake to prevent further confusion!
    – safesploit
    Commented Jul 16, 2018 at 18:07
  • I hadn't thought of using DH for authentication before, but it does seem that's possible with a static key, so thanks for pointing that out! It looks like TLS actually does support it, it's just not very common. Commented Jul 16, 2018 at 18:10
  • I understand this. From your last paragraph of answer, is the DH server key exchange signed by the server? Commented Jul 17, 2018 at 7:17
  • 1
    CloudFlare stats that their SSL handshake (DH) the server's private key signs the client random, server random and public key certificate. The server then sends the client the DH parameter and a signature. "The server also needs a way to prove that it has control of the private key, so the server computes a digital signature of all the messages up to this point "Message 2: “Server Hello”. Both the Diffie-Hellman parameters and the signature are sent in this message." [ blog.cloudflare.com/content/images/2014/Sep/… ] So yes, the DH key exchange is signed.
    – safesploit
    Commented Jul 17, 2018 at 16:55
  • 1
    (@safesploit) cloudflare's text is wrong, although the picture is actually right (through 1.2): the ingoing orange arrows are on the two randoms/nonces and the server DH parameters, and that is in fact what is signed in DHE_RSA (DHE_DSS also, but cloudflare doesn't use that); see rfc5246 7.4.3 et pred. (1.3 proposes to change this to a transcript signature, similar to the client side in current versions.) Commented Jul 20, 2018 at 12:16

You must log in to answer this question.

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