2

I read that D-H is used to make a shared secret between parties that then they use to encrypt the messages.

This is used in TLS, for example, after the server has authenticated itself with a certificate.

But, if I understand correctly, the certificate has server's public key to use for encryption. Why not just encrypt the secret (or symmetric key) with that public key and send that to the server?

EDIT AFTER MARKED AS DUPLICATE: The marked duplicate question Is there any particular reason to use Diffie-Hellman over RSA for key exchange? is asking why prefer DH over RSA (ephemeral DH and ephemeral RSA I think?) for symmetric key exchange. I'm asking why use any of them at all (DH, or ephemeral RSA), why doesn't client just send the symmetric key encrypted with server's certificate public key? Reading the marked duplicate, and https://crypto.stackexchange.com/questions/29744/can-an-ephemeral-rsa-key-give-forward-secrecy I came to the conclusion that my proposal can be used for symmetric key exchange in TLS-like protocol if we do not care about PFS (perfect forward secrecy), and the reason for using ephemeral DH or ephemeral RSA as additional step is only to achieve PFS. Am I correct?

croraf
  • 163
  • 6
  • I agree with Androl that it sounds like a duplicate. I also voted to close this question in favor of the other one. It's a good question, though! If you do not think it is a duplicate, please edit your question to clarify the difference. – Luc Nov 02 '18 at 22:37
  • OK, so if I understand correctly both ways from my title can be used after receiving the server's certificate (at least in older SSL protocols), with the latter method from my title (called RSA in the other question) not providing PFS? What confuses me is that the other answer says this RSA (ephemeral RSA) provides PFS. Is RSA from the other question really the same as just having the client return the secret RSA encrypted with certificates public key? – croraf Nov 03 '18 at 07:25
  • Actually I think the question is not a duplicate (although the answer on the other one is really comprehensive and helped me a lot). The other question is asking DH vs __ephemeral__ RSA. So this is the step after receiving certificate. I was asking why make this extra step and not just return the symmetric key immediately by the client. The reason is PFS. This question also clarified me https://crypto.stackexchange.com/questions/29744/can-an-ephemeral-rsa-key-give-forward-secrecy. Can you confirm? – croraf Nov 03 '18 at 07:36
  • If I understood you correctly, yes, that is the reason. Glad you could find your answer on the other pages! If you want to write a better answer, one that specifically answers your variant of the question, you can always add an answer to one of the questions if you think it's on-topic on either (or both). And in case you get it wrong, I'm sure people will let you know, so it can also help as a check to make sure you understood it correctly. – Luc Nov 03 '18 at 12:57
  • 2
    Thanks. The provided duplicate answer and the link from crypto.SE helped me to get to the conclusion if I'm correct. Unfortunately I cannot answer here as it is marked duplicate (although atm I think it's a separate question as explained above), so I have to wait for admin to reassess. – croraf Nov 03 '18 at 13:03
  • I meant to post another answer on the page marked as duplicate (as it should be on topic, since the questions are seen as duplicates), or perhaps the crypto SE page if you think it's more on-topic there. Unless you edit this question to clearly distinguish it from the other one, I do not think this question will be reopened. – Luc Nov 03 '18 at 13:26
  • *"I came to the conclusion that my proposal can be used for symmetric key exchange in TLS-like protocol if we do not care about PFS (perfect forward secrecy), and the reason for using ephemeral DH or ephemeral RSA as additional step is only to achieve PFS. Am I correct?"* - this is correct. Your idea is essentially RSA key exchange which exists in TLS but is deprected and removed with TLS 1.3 since it does not provide forward secrecy. – Steffen Ullrich Nov 04 '18 at 07:46
  • Hi @SteffenUllrich. I'm dubious that my idea is RSA key exchange removed with TLS 1.3. I think that one is an additional step, ephemeral RSA as described here: https://crypto.stackexchange.com/questions/29744/can-an-ephemeral-rsa-key-give-forward-secrecy (where party A is the TLS client and party B is the TLS server)? In my proposal will party A just give the symmetric key to B, encrypted with TLS server's certificate key. – croraf Nov 04 '18 at 08:27
  • 2
    @croraf: In RSA Kx as done in TLS the client generates the premaster secret and encrypts it with the servers public key taken from the certificate. Then client and server derive the master secret and keys from this premaster secret and some other stuff (client and server random). While a bit more complex than what you propose it is essentially what you propose. There are no ephemeral RSA keys involved in this. – Steffen Ullrich Nov 04 '18 at 08:57

0 Answers0