Specifically with TLS,

  1. What is RSA used for during key exchange?
  2. What is Diffie-Hellman used for?
  3. Since RSA already provides authenticity and confidentiality, why is Diffie-Hellman used during the exchange?
  4. I've heard DH exchanges aren't secure. Is that something to be worried about in an RSA with Diffie-Hellman exchange?
  5. If DH is used for forward secrecy. What's wrong with just generating new RSA key pairs and exchanging keys with that?

The use of Diffie-Hellman along with RSA is the one thing I don't understand about modern Public-Key Cryptography.


2 Answers 2

  1. What is RSA used for during key exchange?

RSA can be used either (a) for signing the key agreement transcript with some other mechanism of key agreement (ciphersuites TLS_*DH*_RSA_WITH_*), or (b) for the client to encrypt a premaster secret key it sends to the server as an authenticated key agreement (ciphersuites TLS_RSA_WITH_*).

The premaster secret determines the key under which records exchanged by the peers in the session are symmetrically encrypted and authenticated, e.g. with AES-GCM.

In both cases, the server does a private key operation to prove its identity: in (a), it signs the key agreement transcript with the server's long-term public key, producing a signature that the client (and anyone else) can verify; in (b), it decrypts the client's premaster secret key, proving it is able to decrypt messages encrypted to the server's long-term public key.

Note that in TLS 1.3, RSA key agreement is going away.

  1. What is Diffie-Hellman used for?

Diffie–Hellman, over finite fields or over elliptic curves, can be used for ephemeral or static key agreement.

In the ephemeral case, both parties generate and exchange a fresh key pair and use it to agree on a premaster secret key, which they then authenticate by another means, such as an RSA or ECDSA signature. (Note that in principle you could use DH for key agreement and authentication, but nobody does this in TLS.)

In the static case, at least one of the parties, typically the server, has a long-term DH public key, which the other party, typically the client, combines with a DH private key to derive a premaster secret. The server proves its identity by deriving the same premaster secret from its private key and the client's (ephemeral or static) public key. (Static DH isn't used much.)

  1. Since RSA already provides authenticity and confidentiality, why is Diffie-Hellman used during the exchange?

Diffie–Hellman provides a fast key agreement procedure, with a small number of rounds trips, that supports fast key erasure: as soon as the session is done, all copies of the DH private keys, the derived premaster secret, the derived master secret, etc., can be erased by the peers. Fast key erasure means compromising the long-term identity keys does not enable retroactive decryption of the session.

In contrast, with RSA key agreement, future compromise of the server's long-term identity key trivially enables an adversary to retroactively decrypt past sessions, because the session keys were all encrypted to the server's long-term identity key.

  1. I've heard DH exchanges aren't secure. Is that something to be worried about in an RSA with Diffie-Hellman exchange?

There are lots of security issues one might be concerned about. Maybe your friend is concerned about historical mistakes in supported ciphersuites; maybe your friend is concerned about timing side channels in finite-field arithmetic over general primes; maybe your friend is concerned about dynamic DH group choices and insufficient validation; maybe your friend is concerned about choices of elliptic curves. But I can't read your friend's mind: you'll have to be more specific.

  1. If DH is used for forward secrecy. What's wrong with just generating new RSA key pairs and exchanging keys with that?

You could generate a fresh RSA identity key for every session, ask your certification authority to sign a certificate for that key, and then use that for RSA key agreement.

This would be the most stupidly expensive TLS stack ever, because generating RSA keys is extraordinarily expensive compared to generating DH keys (and takes an unpredictable amount of time to boot), sensible certification authorities store their keys in hardware security modules that you don't want to have attached to your TLS front ends, and sensible certification authorities have elaborate audit trails around certificates including Certificate Transparency logs that you can explore at crt.sh.

You could devise an RSA-based key agreement protocol with ephemeral RSA keys and without involving your CA, but RSA keys are still extraordinarily expensive to generate, and it would take additional round-trips between the peers, and you would still have to find some way to authenticate them.

  • $\begingroup$ So DHKE is pretty much only used for the server and client to establish a session key, which will be used with a symmetric cipher (ie. AES), and only for that session? And then RSA is used to make sure the key exchange actually happened with the server the client wants (authentication)? Also, when I said Diffie-Hellman was 'insecure', I was referring to the limited set of prime numbers used in the algorithm. As far as I understand, if this was a major vulnerability, DHKE with RSA would be 'comprimised'. Anyways, thanks for the answer. $\endgroup$
    – wispi
    Apr 12, 2018 at 0:31
  • 1
    $\begingroup$ @wispi Yes, DH key agreement is used to agree on a quickly erasable session key, and RSA signature is used to authenticate it. (The soon-to-be obsolete RSA key agreement method is used to agree on a session key and authenticate it, but it can't be erased quickly—there's no ‘forward secrecy’.) There's no shortage of prime numbers with thousands of bits, but you need only one large prime for finite-field Diffie–Hellman, and the choice of Group #14 in RFC 3526 is perfectly good. $\endgroup$ Apr 12, 2018 at 1:14
  • $\begingroup$ Back when SSL3 and TLS1.0 had 'export' suites with keyexchange limited to RSA-512 or DHE-512 (and ECDHE wasn't yet in use) the former could use a nominally ephemeral RSA-512 transport key signed by the certified RSA auth key. No extra trips; see 7.4.3 in 2246 (but not later). Still, servers tended to replace this 'ephemeral' key only once a day, or a week, or so. $\endgroup$ Apr 12, 2018 at 4:42
  • $\begingroup$ @SqueamishOssifrage So if I'm understanding this correctly, right now, servers can use TLS to exchange a key with RSA (providing no forward secrecy), but in TLSv1.3 they're removing that ability? $\endgroup$
    – wispi
    Apr 15, 2018 at 5:24
  • $\begingroup$ @wispi Pretty much. The client has to agree to do so as well. Clients could reject TLS_RSA_WITH_* ciphersuites, of course. $\endgroup$ Apr 15, 2018 at 16:48
  • The Diffie-Hellman key exchange is vulnerable to Man-in-the-middle attacks, so an enemy could intercept our messages and create his own shared with us. Using asymmetric encryption like RSA repels this kind of attack: we encrypt our message with the servers public key so only they can decrypt them. This is in theory enough to make our communication secure.
  • Let's say we don't use DH, but only RSA - what happens when the server accidently leaks the private key? Every past and future message can be decrypted and read. Using DH in addition to RSA will secure any past key exchange, making them secure even if the private key becomes common knowledge.
  • Generating new asymmetric keys is expensive. It would take too much time and performance to always create a new one.
  • $\begingroup$ Isn't RSA also vulnerable to Man-in-the-middle attacks unless you use 2-way authentication? Or do you mean that DH is harder to protect against this attack? $\endgroup$
    – Aemyl
    Apr 11, 2018 at 6:44
  • $\begingroup$ I'm referring to a system where we already know / trust the public key of the server, for example in a trusted certificate chain like with HTTPS and TLS. Without that the exchange would be interceptable even with RSA, that's true. $\endgroup$
    – Nova
    Apr 11, 2018 at 16:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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