On Wed, Feb 9, 2022 at 9:31 AM Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > Do we need a BUG_ON(random_data_len > 32) here? I suppose we do. I'll add it. I didn't have this originally because there are really only same-file callers which are careful, and the compiler can't optimize it out. But maybe that carefulness won't be there in the future, so seems like a good idea to add it. > > + memset(&chacha_state[12], 0, sizeof(u32) * 4); > > No IV, no generation counter here? As you already have a generation counter > in use for other purposes, why not use it here as well as some non-zero > starting point? No. The "fast key erasure" proposal sets the nonce to zero and sets the counter from zero, so I'd like to do the same, and leave the nonce field available for some other interesting use in the future. For example, setting the nonce to smp_processor_id() if we do future interesting things with lockfree algorithms. For now we have already a 256-bit key which is more than sufficient. By the way, if https://blog.cr.yp.to/20170723-random.html (the original fast key erasure rng description) is a wall of text that's not too appealing, you can read Dan's implementation of it in supercop, which is remarkably simple: https://github.com/jedisct1/supercop/blob/master/crypto_rng/chacha20/ref/rng.c . You'll notice the new code in this commit isn't too far from there. Jason
