Editing /dev/random (section)

=== Critique of entropy injection ===
In January 2014, [[Daniel J. Bernstein]] published a critique<ref name=":1">{{cite web |author=Daniel J. Bernstein |author-link=Daniel J. Bernstein |date=2014-02-05 |title=cr.yp.to: 2014.02.05: Entropy Attacks! |url=https://blog.cr.yp.to/20140205-entropy.html |quote=Is there any serious argument that adding new entropy all the time is a good thing? The Linux /dev/urandom manual page claims that without new entropy the user is "theoretically vulnerable to a cryptographic attack", but (as I've mentioned in various venues) this is a ludicrous argument}}</ref> of how Linux mixes different sources of entropy.  He outlines an attack in which one source of entropy capable of monitoring the other sources of entropy could modify its output to nullify the randomness of the other sources of entropy.  Consider the function {{tmath|H(x,y,z)}} where ''H'' is a hash function and ''x'', ''y'', and ''z'' are sources of entropy with ''z'' being the output of a CPU-based malicious HRNG Z:
# ''Z'' generates a random value of ''r''.
# ''Z'' computes {{tmath|H(x,y,r)}}.
# If the output of {{tmath|H(x,y,r)}} is equal to the desired value, output ''r'' as ''z''.
# Else, repeat starting at 1.
Bernstein estimated that an attacker would need to repeat {{tmath|H(x,y,r)}} 16 times to compromise DSA and ECDSA, by causing the first four bits of the RNG output to be 0.  This is possible because Linux reseeds H on an ongoing basis instead of using a single high quality seed.<ref name=":1" />

Bernstein also argues that entropy injection is pointless once the CSPRNG has been initialized.<ref name=":1" />

In kernel 5.17 (backported to kernel 5.10.119), Jason A. Donenfeld offered a new design of the Linux entropy pool infrastructure. Donenfeld reported that the old pool, consisting of a single 4096-bit [[Linear-feedback shift register|LFSR]] is vulnerable to two attacks: (1) an attacker can undo the effect of a known input; (2) if the whole pool's state is leaked, an attacker can set all bits in the pool to zero. His new design, which is faster and safer, uses the blake2s hash function for mixing a 256-bit pool.<ref>{{cite web |title=[PATCH 5.15 038/145] random: use computational hash for entropy extraction|url=https://lore.kernel.org/lkml/20220527084855.501642285@linuxfoundation.org/|website=lore.kernel.org}}</ref>