Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

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

share|improve this answer
    
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. –  mirabilos Jan 6 at 22:51

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 a HMAC key for each direction for suites that need it (which is everything except the GCM and CCM 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 common, keyexchange method is RSA, sometimes emphasized as akRSA. 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 authenticated) with the Finished message. It is optional for the server to request client authentication; if so the client sends its own (RSA) cert and uses its matching privatekey to (RSA) sign the ClientKeyExchange, but this is rarely used. This is "purely" RSA.

DHE 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 also elliptic-curve variants ECDHE-{RSA,ECDSA} 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 also '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, 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: Pre-Shared Key and Secure Remote Password. 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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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