Return to Answer

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 RSA 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 (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. 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.

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.

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 RSA 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 (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. 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 gp; use of RSA CRT does not offset that); the difference in performance can even larger if we use an elliptic-curve group for DH.

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 RSA 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 (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. 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.

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 RSA 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).
• The roles of the cleint and server are very different; when working between peers, there must be some way to decide who acts as client and who acts as server (in DH the two side can be entirely symmetrical, generating two session keys).
• RSA decryption (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. 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 gp; use of RSA CRT does not offset that); the difference in performance can even larger if we use an elliptic-curve group for DH.

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 RSA 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 (and RSA signature, which is needed for forward secrecy) on the client side is significantly more compute-intensive than the whole Diffie-Hellman exchange needs to be. 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 gp; use of RSA CRT does not offset that); the difference in performance can even larger if we use an elliptic-curve group for DH.