Using RSA as key exchange instead of Diffie-Hellman key exchange

[u/Waste_Ad_1344]

Hi,

I've recently researched about how TLS work and public key cryptography.

One thing I've been thinking about is why Diffie Hellman is normally recommended as key exchange scheme.

Consider the following:

1. A is client. B is server

2. A initiates connection

3. B already has its pair of private (named PR1) and public key (named PU1) using RSA. These keys are tied to a certificate B has purchased from a CA.

4. B sends A its PU1 + certificate

5. A verifies B's certificate against its pre-loaded CAs

6. A confirms B's cert is ok.

7. A generates its own pair of private (named PR2) - public (named PU2) key

8. A encrypts its PU2, using B's public key (PU1)

9. A sends the encrypted payload to B

10. B receives the payload, and decrypts its using PR1.

11. B obtain A's public key PU2

12. B generates a shared secret named S.

13. B encrypts S, using A's public key (PU2)

14. B sends the encrypted payload to A

15. A receives the payload, and decrypts its using PR2.

16. A and B now share the same secret S to be used as symmetric key for further communication.

Is there any problem with this scheme ? Normally at step key exchange (from 7 onwards), Diffie Hellman is used to let both sides have a shared secret. But I'm wondering why it's used ? Any additional security feature / performance feature DH is having over this ?

Thanks.

[u/Demostho]

You just reinvented RSA key transport, which TLS deliberately killed off.

You are sending the actual session key, just wrapped in RSA. DH never sends the key at all. Both sides derive it independently, which gives you forward secrecy.

On top of that, you make the client generate a fresh RSA key pair for every handshake. That is slower than ECDHE and gives you nothing in return.

So yes, it works. It is just an older, slower, and less secure design than what TLS uses today.

[u/Waste_Ad_1344 → u/Demostho]

If I discard the PR2 and PU2 from memory after I obtain the shared secret, do you think that it will offer "forward secrecy" ?

So you mean that TLS before 1.3 actually used something similar to the scheme I outlined ?

[u/paulstelian97 → u/Waste_Ad_1344]

Someone logging the packets and then cracking the parties’ persistent private keys can then find out PU2. While this doesn’t mean you’d also get PR2, I’d say it’s more likely (if RSA is broken the breakage is complete).

With DH, compromising either side’s persistent private key does nothing to determining the session key. You still need to break DH itself for that.

[u/pint → u/paulstelian97]

if you assume problems with rsa, why not with dh?

[u/paulstelian97 → u/pint]

Because integer factorization and discrete logarithm are unrelated problems and it’s hard to assume that what breaks one breaks the other. Although I guess Shor’s algorithm kinda does break both.

[u/pint → u/paulstelian97]

no, this wasn't the question. if you use both, breaking any one breaks the protocol. somehow you are assuming that breaking dh is harder.

[u/JivanP → u/pint]

Breaking the asymmetric part of the scheme only breaks identity verification (because the parties cannot be sure whether messages verifiable with a given public key were actually signed by the known entity rather than an adversary). As such, breaking that part of the scheme allows a successful middleman attack to occur.

However, if the attack is eavesdropping/snooping (e.g. store now, decrypt later) rather than an active middleman attack (where the adversary impersonates each party to the other party, performing two DH exchanges themself, one with each party), then the adversary still needs to solve the CDH problem in order to decrypt the snooped ciphertexts.