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. _______________________________________________ The cryptography mailing list firstname.lastname@example.org http://www.metzdowd.com/mailman/listinfo/cryptography