---
This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is much more efficient to communicate on since it saves an extra round-trip each exchange.
---
Two points:
- The first and second sentences don't appear to be particularly related.
- The symmetric system isn't more efficient because of round-trips. (I'm also not sure which round trips it saves on.)
Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 7.4.7.1, 8.1.1)
Finally, a bit of a plug, but... If you're interested in the build up, my PyCon 2013 talk "Crypto 101" starts from XOR and ends with TLS in 45 minutes. It mostly goes into a bit more detail about thinks like block and stream ciphers. I'm hoping to eventually turn this into a book. (If you're interested, my e-mail's in my profile.)
I absolutely loved your talk; not only is it pretty informative but also entertaining, and found myself rewatching it just because. I think your talk gave me enough knowledge of crypto to take another go at Stanford's "Cryptography I" class. So thanks and I'll look out for your book.
Awesome! Always glad to hear from a happy customer :)
Is there something in particular that you would like more of or perhaps to stay the same? Humor is good, I suppose?
Obviously, a book lets me go in more detail, but I'm disinclined to take that too far. The entire beauty of Crypto 101 is that it doesn't go into detail. Right now I'm mostly just marking sections that you could skip if you want to.
--- This public key exchange only needs to happen once per session, the first time the client and server connect. Once they’ve agreed on a shared secret, the client and server communicate using a symmetric-key crypto system which is much more efficient to communicate on since it saves an extra round-trip each exchange. ---
Two points:
- The first and second sentences don't appear to be particularly related. - The symmetric system isn't more efficient because of round-trips. (I'm also not sure which round trips it saves on.)
Also (and I made the same mistake in my talk...), yes, explaining DH is important, but now it kind of sounds like in TLS both sides figure out the master secret using DH (and, in your talk, specifically, regular DH, not EC-based DH), when in reality that depends on the ciphersuite, and the vast majority of TLS connections don't work that way. From what I understand to be most TLS configurations in the wild, the pre-master secret is encrypted using the server's public key. (RFC 5246: 7.4.7.1, 8.1.1)
Finally, a bit of a plug, but... If you're interested in the build up, my PyCon 2013 talk "Crypto 101" starts from XOR and ends with TLS in 45 minutes. It mostly goes into a bit more detail about thinks like block and stream ciphers. I'm hoping to eventually turn this into a book. (If you're interested, my e-mail's in my profile.)