I've read in this article, that encrypting a premaster key with a RSA public key is not safe from forward secrecy attacks. If an adversary, records all communication between a client and a server. And the server later is decommissioned and retrieved by the adversary and the adversary also retrieves the private key stored in the server. He can decrypt the premaster key and generate a master key and decipher all recorded communication between the client and server.

To prevent forward secrecy attack, one can implement Diffie-Hellman Ephemeral Mode for the premaster exchange.

Now to my question. What role does RSA play in this if DHE is used? Because I've seen cipher suites with RSA and DHE in it.

  • $\begingroup$ After some research, it seems like RSA in a DHE cipher suite is just used for signing key exchange messages from the server and verified by the the client using the public key that they are authentic. $\endgroup$
    – einstein
    Feb 25 '18 at 12:54
  • $\begingroup$ You are correct, see my answer. Although you should not forget about the entity authentication. Without the RSA calculation you would not be certain that you would be talking to the right server (without additional security measures such as secure DNS, anyway). $\endgroup$
    – Maarten Bodewes
    Feb 25 '18 at 12:59
  • $\begingroup$ Crossdupe security.stackexchange.com/questions/46279/… $\endgroup$ Feb 26 '18 at 3:57

Ephemeral Diffie-Hellman (DHE or ECDHE) uses two ephemeral key pairs that should be discarded after use. However, to establish a secure connection it is required that you know the entity that you establish the connection with. If that isn't the case then an impersonation or man-in-the-middle attack is possible.

So RSA in this case points to the key pair of the server, the public key of which is in the server certificate. This certificate is used to establish a chain to a trusted (root) certificate in the certificate store, e.g. the one in your browser or system store. This chain is verified and validated so that the public key of the server can be trusted to a certain degree (the level of trust established by trusting all of the CA's in the certificate store is an ongoing debate).

Now that you've established trust in the public key the private key of the server can be used for two related goals:

  1. entity authentication of the server and
  2. making sure that the ephemeral public keys and parameters have indeed been generated by the client and server.

The RSA algorithm is used for the private key calculation at the server to sign the messages used to perform the key agreement to agree on the master secret. This master secret in turn is used to derive the session keys used to encrypt the data streams. The client uses the RSA algorithm for the verification of the public keys, parameters and to make sure that the server controls the private key used for the signature generation (server entity authentication).

The advantage of directly encrypting the master secret (in the old RSA_ cipher suites) is that it establishes the master secret and performs the entity authentication in one single operation. Fortunately DH and certainly ECDH is relatively fast compared to RSA private key operations.


  • obviously the certificate needs to have an RSA public key, so ECDSA certificates cannot be used by the server;
  • the client is not authenticated by default - to authenticate the client it is required for the server to explicitly request client authentication, this is why you need to login on most websites (or authenticate yourself when paying, of course);
  • the certificates themselves may be signed by a different algorithm than RSA, and if client certificates are used then they may use a different algorithm as well.

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.