[147607] in cryptography@c2.net mail archive
Re: [Cryptography] Crypto Standards v.s. Engineering habits - Was:
daemon@ATHENA.MIT.EDU (John Kelsey)
Thu Oct 10 18:49:24 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <BLU0-SMTP625E17E69E9C8AC2E56173C81E0@phx.gbl>
From: John Kelsey <crypto.jmk@gmail.com>
Date: Thu, 10 Oct 2013 18:32:55 -0400
To: Richard Outerbridge <outer@sympatico.ca>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>,
Bill Frantz <frantz@pwpconsult.com>,
Stephen Farrell <stephen.farrell@cs.tcd.ie>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Oct 10, 2013, at 5:15 PM, Richard Outerbridge <outer@sympatico.ca> wrote:
>
> How does this prevent MITM? Where does G come from?
I'm assuming G is a systemwide shared parameter. It doesn't prevent mitm--remember the idea here is to make a fairly lightweight protocol to run *inside* another crypto protocol like TLS. The inner protocol mustn't add administrative requirements to the application, which means it can't need key management from some administrator or something. The goal is to have an inner protocol which can run inside TLS or some similar thing, and which adds a layer of added security without the application getting more complicated by needing to worry about more keys or certificates or whatever.
Suppose we have this inner protocol running inside a TLS version that is subject to one of the CBC padding reaction attacks. The inner protocol completely blocks that.
> I'm also leery of using literally the same key in both directions. Maybe a simple transform would suffice; maybe not.
I probably wasn't clear in my writeup, but my idea was to have different keys in different directions--there is a NIST KDF that uses only AES as its crypto engine, so this is relatively easy to do using standard components.
--John
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
