This proposed design comprehensively ratifies Linux&#x27;s nonsensical legacy random&#x2F;urandom division; for instance, it maintains a &quot;512 bit emergency entropy level&quot; in case urandom becomes &quot;stressed&quot;. It appears to be motivated principally by concerns about the quality of entropy being fed continually into the LRNG --- which is a nonproblem.<p>This is silly.<p>There are three problems a kernel CSPRNG needs to address:<p>1. It needs to seed itself reliably and not provide output when it&#x27;s not securely seeded.<p>2. It needs to re-key itself regularly to provide forward secrecy and recovery from attacks.<p>3. It needs to be performant enough to be used in applications to the exclusion of all other RNGs.<p>That&#x27;s it. Once problem (1) is addressed, there is never again for the uptime of the system a concern about the quality or &quot;level&quot; of entropy in the LRNG. DRBGs like this document proposes are effectively stream ciphers (in fact: Salsa20, the new hotness in bulk cipher designs, is essentially a hash DRBG --- and, in the BSDs, a [crappy] stream cipher <i>was</i> the RNG). &quot;Entropy&quot; keys the cipher. The idea that you can &quot;run low&quot; on entropy is the same as the idea that you can &quot;run low&quot; on key. No.<p>Kernel CSPRNGs do need continually updated entropy pools. But not because their original entropy is depleted! Rather: you want your RNG to be updated so that its &quot;key&quot; changes regularly, so that if your system is compromised transiently, you&#x27;ll recover.<p>And, of course, the division between &#x2F;dev&#x2F;random and &#x2F;dev&#x2F;urandom sabotages goal (3) --- arguably the most important goal. Almost every time you&#x27;ve read about some crypto randomness catastrophe --- from Debian commenting out their RNG and reducing SSH key space to 16 bits, to Bitcoin wallets coughing up private keys by repeating nonces --- you&#x27;ve been reading about <i>userspace RNG failures</i>. People use userspace RNGs because they think the kernel RNG is too slow. And they think the kernel RNG is too slow because they use &#x2F;dev&#x2F;random, which obstinately refuses to provide output when --- wait, I&#x27;m not dignifying &#x2F;dev&#x2F;random: it refuses to provide output <i>at random</i>.