Safer entropy accumulation in Linux 5.18's RNG | Hacker News Reader

Safer entropy accumulation in Linux 5.18's RNG

twitter.com

61 pointszx2c410 comments

The commit log message is probably a better link than the (short) thread:

https://git.kernel.org/pub/scm/linux/kernel/git/crng/random....

It's quite detailed.

The nutshell of this is that `mix_pool_bytes` (we'll call it M), the LFSR mixing function in the core of the LRNG, has been replaced with Blake2. The M function is slow doesn't adequately recover security if the state is compromised. This is a well-known problem, but one no longer accepted in new designs as CSPRNGs are increasingly formalized.

The new LRNG is much simpler (a lot of it is simply calls to Blake2 now), easier to reason about, and fast.

So just so I'm not misunderstanding: this changes the innerworkings of the "mixing" function that takes a number of raw entropy inputs and mixes them together, from an LFSR-based one to a hash-based one backed by blake2s.

But this doesn't change the chacha20-based CSPRNG that actually ends up being the output of /dev/urandom?

But am i correct in saying this entropy mixing eventually leads to some seed data that seeds the chacha20-based CSPRNG?

Great! We do something similar for mixing input entropy in FreeBSD, but use SHA256 instead (only because the code predates Blake2, and there hasn't been a compelling reason to switch).

> replace gobs of complicated 1990s-era code with a modern hash function

Uhh ... was the kernel not already using a cryptographically secure hash function to mix new randomness in?!

It used `mix_pool_bytes`, which you can read about in section 5.6 of this paper:

https://eprint.iacr.org/2013/338.pdf

> a good PRNG should be able to eventually recover from compromise even if the entropy is injected into the system at a very slow pace

I haven't gone through the entire paper yet. Any idea what sort of threat model involves compromise of the PRNG state but not the entropy pool being used to refresh it? Assuming cryptographically secure functions it seems like being able to determine the internal state would necessitate low level access to the system so you could directly read it.

This is considered at length in the commit message Jason links to; see upthread.

The whole of it seems to be (I'll split it into two sections):

> If an attacker has access to the system to such a degree that he can learn the internal state of the RNG, arguably there are other lower hanging vulnerabilities -- side-channel, infoleak, or otherwise -- that might have higher priority.

I think this probably matches most people's intuitions.

> On the other hand, seed files are frequently used on systems that have a hard time generating much entropy on their own, and these seed files, being files, often leak or are duplicated and distributed accidentally, or are even seeded over the Internet intentionally, where their contents might be recorded or tampered with. Seen this way, an otherwise quasi-implausible vulnerability is a bit more practical than initially thought.

This is a reiteration of "unpredictable initial seeding is hard."

So effectively - initial key file leaked or otherwise duplicated between systems but system as a whole not compromised.

Correct. At least, it was not in this particular use.

Reply on news.ycombinator.com