[147050] in cryptography@c2.net mail archive
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
daemon@ATHENA.MIT.EDU (Adam Langley)
Wed Sep 11 18:36:17 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <52309D98.9050601@gmail.com>
From: Adam Langley <agl@google.com>
Date: Wed, 11 Sep 2013 18:33:20 -0400
To: William Allen Simpson <william.allen.simpson@gmail.com>
Cc: Phil Karn <karn@ka9q.net>, cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Wed, Sep 11, 2013 at 12:43 PM, William Allen Simpson
<william.allen.simpson@gmail.com> wrote:
> Thanks, this part I knew, although it would be good explanatory text to
> add to the draft.
Done.
> My old formulation from CBCS was developed during the old IPsec
> discussions. It's just simpler and faster to xor the per-packet counter
> with the MAC-key than using the ChaCha cipher itself to generate
> per-packet key expansion.
XORing a per-session secret with the sequence number would not be
sufficient for Poly1305. The mask part (the final 16 bytes), at least,
needs to be uniformly distributed. Having different values be related
would be very bad. Off the cuff I'm not sure whether the evaluation
point also has the same issue, but it's not something that I'd like to
find out.
> Anyway, good explanation! Please add it to the draft.
Done.
> No, we should design with
> the expectation that there's something wrong with every cipher (and
> every implementation), and strengthen it as best we know how.
Keep in mind that something similar to this line of thinking has been
very costly in the past:
* It held back the use of counter modes (because the input to the
cipher was mostly zeros) and encouraged the use of CBC mode instead.
* It encouraged MAC-then-Encrypt because the encryption could help
"protect" the MAC.
Both cases were rather a mistake! (The latter certainly, and I dislike
CBC mode so I'm lumping it in there too.)
This ChaCha case is very similar to running a block cipher in counter
mode, something that's solidly established now. It's also exactly as
was intended in the Salsa/ChaCha design. If ChaCha has insufficient
diffusion to cope with it then ChaCha is bust and needs to be
replaced.
I know we differ on the meaning of "conservative" in this case, but
I'm pretty comfortable with my spin on it by using ChaCha as designed,
rather than missing something important when trying for a more complex
design.
Cheers
AGL
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
