On Wed, Feb 9, 2022 at 9:31 AM Dominik Brodowski <linux@xxxxxxxxxxxxxxxxxxxx> wrote: > > Am Wed, Feb 09, 2022 at 02:19:14AM +0100 schrieb Jason A. Donenfeld: > > Continuing the reasoning of "random: use RDSEED instead of RDRAND in > > entropy extraction" from this series, at init time we also don't want to > > be xoring RDSEED directly into the crng. Instead it's safer to put it > > into our entropy collector and then re-extract it, so that it goes > > through a hash function with preimage resistance. > > Any reason why you re-order > > > + mix_pool_bytes(utsname(), sizeof(*(utsname()))); > > mix_pool_bytes(&now, sizeof(now)); My "vim fingers" did that as a matter of habit. But it's actually maybe worse this way, in a very subtle way that really doesn't really matter. The RDSEED bytes should be hashed in first, not last, so that we don't need to rely on the hash function's collision protection. In general crypto hygiene, HASH(secret||thing) is sometimes preferable to HASH(thing||secret). I'll fix that up and mention it in the commit message. Thanks for noticing it. > > ? It shouldn't matter, but it's an additional change I see no rationale for. > > Also, AFAICS, we now only call rdseed 8 times (to mix into the input pool > directly and to update the primary pool indirectly) instead of 8 times (for > the input pool) and 12 times (for initializing the primary pool). That's > still 64 bytes, and we use that to seed 48 bytes, we're still on the safe > side. So feel free to add my And later in this patchset, this is reduced to a 32 byte extraction (which is the size of our pool, which is what we were aiming for). Compressing an entire 64 byte blake block of rdseed down to 32 bytes puts us in a very good position. Jason
