On Wed, Sep 11, 2013 at 12:43 PM, William Allen Simpson <william.allen.simp...@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 firstname.lastname@example.org http://www.metzdowd.com/mailman/listinfo/cryptography