On Sat, Jun 18, 2022 at 07:17:00AM +0800, Sandy Harris wrote: > Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > > ChaCha is a permutation that requires those constants. > > No. The actual permutation does not use the constants. > They are used in setting up the state & directly affect > only the first round. The other 19 rounds do not use > the constants; they operate on the more-or-less random > state left by the previous round. I guess. But that just seems like all the more reason to stick with the constants in that first round, as chacha lacks round constants like "hermetic" permutations. Better to give less control over that initial state. Anyway, we're not going to veer off into lala land and redesign chacha on lkml. > There is no such argument for > memset(&chacha_state[12], 0, sizeof(u32) * 4); > ChaCha has a counter and a nonce in those > bits, so setting them to zero is a deviation. No. There's a new key each time. So the nonce begins at zero. And the counter begins at zero as well at the beginning like usual. So it's actually a rather boring by-the-books usage of chacha. > Dropping the memset() and using whatever > the existing state has there may not be ideal, > but it is certainly better than the zeroes. I'm not so sure about that. For starters, it means that we'll never actually exceed the first 32 bits, and so the branch for the increment of the next word is never true, which has some tiny value. And as for the nonce, I'd like to reserve that for whatever interesting use comes up in the future (like using the cpu number or something in an interesting parallel design). But the larger reason for rejecting your idea wholesale is that I'm trying to enforce the property that input data goes through our hash function (via mix_pool_bytes). Full stop! It's time that this willy-nilly stuff ends where we're feeding in things right and left with no actual design on which is ingesting what input and how it interacts. So if you do think that a particular block of memory somewhere at some point has some entropic value, then by all means call mix_pool_bytes or add_device_randomness on it. But don't try to stuff it in where it doesn't belong. The type of valuable patch I'd like to encourage is this recent one from LinusW: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ac9d25557dcc9fe90ed12bfbb6db401e892ca004 This seems like the kind of thing that might really help the situation on certain devices in a real way. More of that! Less of fake crypto. Jason
