> Without doing any key management or requiring some kind of reliable identity or memory of previous sessions, the best we can do in the inner > protocol is an ephemeral Diffie-Hellman, so suppose we do this: > > a. Generate random a and send aG on curve P256 > > b. Generate random b and send bG on curve P256 > > c. Both sides derive the shared key abG, and then use SHAKE512(abG) to generate an AES key for messages in each direction. > > d. Each side keeps a sequence number to use as a nonce. Both sides use AES-CCM with their sequence number and their sending key, and keep > track of the sequence number of the most recent message received from the other side. > > ... > > Thoughts?
We should get Stev Knowles explain the "skeeter" and "bubba" TCP options. >From "private conversations" I understand that the options where doing pretty much what you describe: use Diffie Hellman in the TCP exchange to negotiate an encryption key for the TCP session. That would actually be a very neat thing. I don't believe using TCP options would be practical today, too many firewalls would filter them. But the same results would be achieved with a "zero-knowledge" version of TLS. That would make session encrypted by default. Of course, any zero-knowledge protocol can be vulnerable to man-in-the-middle attacks. But the applications can protect against that with an end to end exchange. For example, if there is a shared secret, even a lowly password, the application protocol can embed verification of the zero-knowledge "session key" in the password verification, by combining the session key with either the challenge or the response in a basic challenge-response protocol. That would be pretty neat, zero-knowledge TLS, then use the password exchange to mutually authenticate server and client while protecting against MITM. Pretty much any site could deploy that. -- Christian Huitema _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography