3 ms·

Ivan - I have your book, I've read it (at least a year ago, if not more) - so sorry if this is covered and/or I should know the answers, but: (1) Seems like th

Ivan - I have your book, I've read it (at least a year ago, if not more) - so sorry if this is covered and/or I should know the answers, but: (1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the difference is that at least with DH, in theory only /new/ sessions can be attacked (MitM impersonating going forward), but older sessions can't be opened up. (2) Doesn't this mean that now the client needs a keypair & certificate? Otherwise, how does the client sign? And where does the client key pair come from? I'm pretty sure my browsers (i.e., clients) don't have their own keys & certificates. TIA for answering my silly questions.

ivanr 9y ago
(1) Yes, that's the argument against the RSA key exchange. I can break into your server, bribe or blackmail your system administrators, or take you to court to get your private key. This last case happened to Lavabit, for example. Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete. The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete. (2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.

ivanr 9y ago

(1) Yes, that's the argument against the RSA key exchange. I can break into your server, bribe or blackmail your system administrators, or take you to court to get your private key. This last case happened to Lavabit, for example. Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete. The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete. (2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.