Diffie-Hellman "handshake" vs RSA "handshake"

Question

I have a question about exchanging symmetric keys. I have read something about the Diffie-Hellman algorithm, where two parties generate the shared key independently, sharing only some parts of it before generation.

In general, I guess that I get the point of how this works, but wouldn't it be easier if the server requested a public RSA key from the client, encrypts the symmetric key using this public key, and sending it back to the client?

Hope you can help, and thanks in advance.

fre3zr

Answer 1

Using a client's RSA public key to encipher a session key generated by the server is possible, but has a several disadvantages:

• If the client's RSA private key leaks in the future, past communication sessions can be deciphered; there is no forward secrecy, like there can be in some Diffie-Hellman variants. The only option to get that desirable property would be to use a new RSA key pair for each exchange, but then
  • the server has no way to verify the public RSA key generated by the client, thus the protocol might become vulnerable to a man-in-the-middle, unless the client also has a long-term key to sign it's one-session RSA public key.
  • as pointed in that other answer, it requires generation of an RSA key on the client side for each session, and that is typically quite slow.
• The client does not participate in the generation of the session key, thus might be vulnerable to replay, and rightly less confident in the session key (one generator more easily becomes stuck or low-entropy than the combination of two generators implemented by two parties).
• RSA decryption on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be (same for the signature of the RSA public key needed for forward secrecy, if that signature is RSA-based). That's true if DH is performed on a group $\mathbb Z_p$ (notice that the modulus is of the same order of magnitude in RSA and DH for comparable security, but the decryption exponent in RSA has about as many bits as the modulus, when it can be much shorter in DH; we are talking e.g. 2048 versus 256 bits, and commensurate performance gap; use of RSA CRT does not fully offset that); the difference in performance can be even larger if we use an elliptic-curve group for DH.

Answer 2

This is indeed possible, however there is a major disadvantage to doing so, namely that RSA key generation is slow.

You have to generate two large prime numbers, which is done by picking random odd numbers and checking whether they are prime. The probability of a number $x$ being prime is around $1/\log_e(x)$. This means that the probability of an $n$-bit number being prime is around $1/0.3n$. Finding two $1024$-bit primes will take a few hundred goes, which takes a nontrivial length of time.

Diffie-Hellman—whether in a bog-standard prime field $\mathbb{F}_p$ or over some fancy elliptic curve $\mathbb{E}(\;\cdot\;)$—uses uniformly distributed group elements, which are only slightly more difficult to find than a random string from a PRNG, making this option much more efficient than generating an ephemeral RSA key.

If quantum computers turn up, then the approach that you discuss is the most straightforward way to go about replacing Diffie-Hellman in the TLS handshake, as the algorithms that I know about provide encryption and—occasionally—signatures, but nothing like Diffie-Hellman.

Answer 3

The point of using Diffie-Hellman Key Exchange is to guarantee Perfect Secrecy. So RSA public key is only used for the digital signature verification of the Diffie-Hellman parameters sent by the server.

As said before, if RSA private key gets compromised all the intercepted Key Exchanges that used RSA as algorithm would get deciphered too, thus revealing the underlying generated symmetric key.