[Cryptography] Crypto Standards v.s. Engineering habits - Was: NIST about to weaken SHA3?

[Christian Huitema]

> 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