3 ms·

Safer entropy accumulation in Linux 5.18's RNG

• loeg 5y ago
  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).
• aftbit 5y ago
• d110af5ccf 5y ago
  > 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?!
  • tptacek 5y ago
    It used `mix_pool_bytes`, which you can read about in section 5.6 of this paper: https://eprint.iacr.org/2013/338.pdf https://eprint.iacr.org/2013/338.pdf
    • d110af5ccf 5y ago
      > 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.
      • tptacek 5y ago
        This is considered at length in the commit message Jason links to; see upthread.
        • d110af5ccf 5y ago
          So effectively - initial key file leaked or otherwise duplicated between systems but system as a whole not compromised.
        • loeg 5y ago
          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."
  • loeg 5y ago
    Correct. At least, it was not in this particular use.
• tptacek 5y ago
  The commit log message is probably a better link than the (short) thread: https://git.kernel.org/pub/scm/linux/kernel/git/crng/random.git/commit/?id=d512f889f8c7c7b80fe556748b90ae290b92f610 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.
  • 0xdeadb00f 5y ago
    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?