[147658] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits -
daemon@ATHENA.MIT.EDU (Christian Huitema)
Sun Oct 13 15:28:54 2013
X-Original-To: cryptography@metzdowd.com
From: "Christian Huitema" <huitema@huitema.net>
To: "'John Kelsey'" <crypto.jmk@gmail.com>,
"'Bill Frantz'" <frantz@pwpconsult.com>
In-Reply-To: <F3566D30-64F2-4FA4-94F6-962FFE512E06@gmail.com>
Date: Sat, 12 Oct 2013 23:06:35 -0700
Cc: cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
> 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
