At what stage of the SSL/TLS handshake is the DHE and RSA used and what is the purpose of using a pre-master secret when you could just use RSA to exchange the symmetric key (i.e. AES) for further communications. I am confused how DHE, AES and RSA fuse into the SSL/TLS handshake process. Is there a handshake with purely RSA, purely DHE or both.


2 Answers 2


The SSL/TLS handshake consists of a series of messages which do keyexchange and (usually) authentication together. See rfc5246 or its predecessors or Wikipedia for details. The handshake actually results in one "premaster secret" and one "master secret" which is then used to derive multiple keys: an encryption key for each direction (for an algorithm that may be AES or something else), an IV for each direction for suites that need it (which is all CBC suites in protocol versions before TLSv1.1, and some of the AEAD suites in TLSv1.2), and a HMAC key for each direction for suites that need it (which is everything except the AEAD suites in TLSv1.2). See How key materials are generated in SSL V3 from master secret and What is the purpose of four different secrets shared by client and server in SSL/TLS? .

The original, and still a common, keyexchange method is RSA, sometimes emphasized as 'plain' RSA or kRSA. The server sends a certificate containing an RSA (public)key; the client validates the cert and uses the publickey to RSA encrypt the random premaster secret. The server proves correct decryption (and is implicitly authenticated) with the Finished message. The server can optionally request client authentication; if so the client sends its own cert and uses its matching privatekey to sign a partial transcript, which the server validates and verifies, but this is rarely used. Except possibly the client auth, this is 'pure' RSA.

DHE (DH in ephemeral mode) is used in conjunction with a signing certificate, which can be either RSA or DSA. The server sends its cert which client validates, and also its DH group and ephemeral publickey signed under its cert; client generates its ephemeral key in the same group and sends that, plus its cert and signature if client authentication is used.

There is also a method to use DH keyagreement without certificates and authentication, which is in effect ephemeral, but SSL/TLS doesn't call it that, it calls it DH-anon instead. This is usually a bad idea; many people imagine only passive eavesdroppers and think they only need encryption, but in today's internet active attacks of many kinds are widespread and if you don't use authentication you probably aren't secure. You could view this as 'pure' DHE even though it isn't called that.

There are elliptic-curve variants ECDHE (ephemeral, RSA or ECDSA signing} and ECDH-anon. The handshake sequence, and security properties, are the same, only the actual crypto computations are different. These are technically optional but in fact nowadays widely implemented and becoming more popular to use.

And there are 'static' methods (DH and ECDH, no E or anon) which use long-term [EC]DH keys instead of ephemeral ones. This requires certs for the static keys (and preagreement on the group or curve) which is less convenient, especially for classic (non-elliptic) DH, although TLSv1.3 is planned to add standardized DH groups that might change this, and these methods don't seem to be used at all on the public net.

Finally, there are some methods that don't use publickeys at all, including Pre-Shared Key (PSK) and Secure Remote Password (SRP). These basically work only in a private net (or virtual one) and aren't seen on the public net.

AES or other data cipher like 3DES or RC4 is not used in the handshake. It is used for data after the handshake.

Contrary to @mirabilos for [EC]DHE methods the ephemeral key material IS signed under the server cert and the client cert if client auth used. Not for the -anon methods, which are designed not to authenticate.

  • 1
    $\begingroup$ Out of curiosity, is there any situation where RSA signing occurs after the key exchange step? Or do all options exclusively use symmetric signing algorithms from that point onward? $\endgroup$
    – Timo
    Commented Oct 4, 2017 at 12:28
  • 1
    $\begingroup$ @Timo: no. Actual signing (RSA, DSA or ECDSA) is used during the handshake; after that authentication is symmetric: PRF (effectively a MAC) for Finished and HMAC or AEAD for data. Although you can later start a new handshake using renegotiation, but that's a new handshake. $\endgroup$ Commented Oct 5, 2017 at 0:35

You can use RSA to exchange the keys, But the problem is, it does not provide perfect forward security. This is what may happen if you use RSA for key exchange. If someone is able to store your SSL session and if he can get the server private key, He can get the secret key generated by the SSL session. So he can decrypt the entire SSL session.
So we use Diffie Hellman(or Elliptic Curve DH) for key exchange. Private and public keys of DH key exchange is generated at that time. So they cannot be reproduced later. Here DH does not have authentication. because of that server signs the DH public key before sending to the client. This is what DHE and RSA means. It uses DH for key exchanging purpose and RSA for signing. Here AES means finally AES secret key is generated. This link will give you further information

  • $\begingroup$ The problem here is that DHE needs good entropy on both sides, and that the DHE part is not secured by at least the server's key (or both parties' if they have some), to protect from casual eavesdroppers or the bad-entropy case. I'm currently considering switching to ephemeral RSA keys (short-lived, maybe a day or so) due to this, but have not yet tested whether this is portable enough. $\endgroup$
    – mirabilos
    Commented Jan 6, 2014 at 22:51

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.