[Cryptography] Evaluating draft-agl-tls-chacha20poly1305

[William Allen Simpson]

Come on folks, here's an actual design that could help solve problems!
Give it a look!!!

On 9/11/13 6:33 PM, Adam Langley wrote:
> 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.
>
Having re-read Poly1305 yesterday, I'm not sure I agree yet.  But in a
parallel thread now Metzger is also talking about eliminating side
channels by generating the secret IV in counter mode, and you're
essentially doing the same for the integrity check value (ICV).

So absent deeper analysis, I'll wait and see.


> 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.)
>
As to inner-MAC in SSL, I argued against it with ElGamal at the time.
But I've never seen a published rationale.  I don't remember anybody
thinking the MAC was weaker than the cipher.  For both 40-bit DES
(remember the horrors?) and RC4, we thought of MD5 as stronger!

As to CBC, I actually prefer it to counter mode.  I just think folks
kept missing the lessons of early designs.

Yes, counter mode allows some limited parallelism.  And that's a good
thing for such as servers to limit latency.

Yet it doesn't buy any improvement on the client side -- it actually
adds scheduling overhead which potentially increases latency.

And for saturated transmission links, the added overhead is a killer.
The data has to be stored and forwarded serially anyway, so no win.
In the days of yore (a Z80 could barely keep up with 56K links) to now
(current processors having problems keeping up with the lambda at full
rate), a good serialized protocol that can do both the cipher and the
integrity check at the same time in the same registers is what we need!

But the killer argument for me against counter mode is that it allows
the well-funded adversary to attempt decrypt or do oracles in parallel,
making the adversary more efficient without a concomitant security gain
for the defender.

I guess the optimum for me would be the ability to encrypt output in
parallel, but only decrypt input serially.

But we're getting far afield of this design.


> 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.
>
A fair reasoning.  I agree this is a pretty good design, although not
exactly as I'd have done it -- but we need more eyeballs.  There are a
couple of thousand on this list.  Hopefully others will take a look,
and we can get some community support....  I'll shut up for a bit.