Editing /dev/random (section)

==Linux==
[[File:Rngtest FIPS-140-2 screenshot.png|thumb|upright=1.5|Rngtest testing {{nowrap|{{mono|/dev/urandom}}}} pool, same result can be observed with {{nowrap|{{mono|/dev/random}}}} pool]]
The Linux kernel provides the separate device files {{nowrap|{{mono|/dev/random}}}} and {{nowrap|{{mono|/dev/urandom}}}}. Since kernel version 5.6 of 2020, {{nowrap|{{mono|/dev/random}}}} only blocks when the CSPRNG hasn't initialized. Once initialized, {{nowrap|{{mono|/dev/random}}}} and {{nowrap|{{mono|/dev/urandom}}}} behave the same.<ref>{{Cite web |title=/dev/random Is More Like /dev/urandom With Linux 5.6 - Phoronix |url=https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.6-Random-Rework |website=www.phoronix.com}}</ref>

In October 2016, with the release of [[Linux kernel]] version 4.8, the kernel's {{nowrap|{{mono|/dev/urandom}}}} was switched over to a [[ChaCha20]]-based [[cryptographic pseudorandom number generator]] (CPRNG) implementation<ref>{{Cite web |date=2016-07-27 |title=kernel/git/torvalds/linux.git - Linux kernel source tree |url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=818e607b57c94ade9824dad63a96c2ea6b21baf3 |access-date=2016-11-23 |publisher=kernel.org}}</ref> by [[Theodore Ts'o]], based on [[Daniel J. Bernstein|Bernstein]]'s well-regarded [[stream cipher]] [[ChaCha20]].

Since version 5.17 of the Linux kernel, the random number generator switched from using the [[SHA-1]] [[cryptographic hash function]] in the entropy collector to [[BLAKE2s]], a newer, faster and more secure hash function.<ref>{{Cite web |title=Linux 5.17 Random Number Generator Seeing Speed-Ups, Switching From SHA1 To BLAKE2s - Phoronix |url=https://www.phoronix.com/news/Linux-5.17-RNG |website=www.phoronix.com}}</ref>

=== Original implementation ===
Random number generation in [[Kernel (operating system)|kernel space]] was implemented for the first time for [[Linux]]<ref name=":0">{{cite web
 |url         = https://randombit.net/bitbashing/posts/syllable_dev_random.html
 |title       = On Syllable's /dev/random
 |first       = Jack
 |last        = Lloyd
 |date        = 2008-12-09
 |access-date  = 2019-08-21
}}</ref> in 1994 by [[Theodore Ts'o]].<ref>{{cite web
 |url         = http://everything2.com/title/%252Fdev%252Frandom
 |title       = /dev/random
 |date        = 2003-06-08
 |publisher   = [[Everything2]]
 |access-date  = 2013-07-03
 |archive-url  = https://web.archive.org/web/20091117215406/http://everything2.com/title/%252Fdev%252Frandom
 |archive-date = 2009-11-17
 |url-status     = live
}}</ref>
The implementation used [[cryptographic hash function|secure hashes]] rather than [[cipher]]s,{{clarify|date=February 2017}} to avoid [[export of cryptography|cryptography export restrictions]] that were in place when the generator was originally designed. The implementation was also designed with the assumption that any given hash or cipher might eventually be found to be weak, and so the design is durable in the face of any such weaknesses. Fast recovery from [[Entropy pool|pool compromise]] is not considered a requirement, because the requirements for pool compromise are sufficient for much easier and more direct attacks on unrelated parts of the operating system.

In Ts'o's implementation, the generator keeps an estimate of the number of [[bit]]s of noise in the [[entropy pool]]. From this entropy pool random numbers are created. When read, the {{nowrap|{{mono|/dev/random}}}} device will only return random bytes within the estimated number of bits of noise in the entropy pool.  When the entropy pool is empty, reads from {{nowrap|{{mono|/dev/random}}}} will [[Asynchronous I/O|block]] until additional environmental noise is gathered.<ref name="linux-man-page">{{man|4|random|Linux}}</ref> The intent is to serve as a [[cryptographically secure pseudorandom number generator]], delivering output with entropy as large as possible. This is suggested by the authors for use in generating cryptographic keys for high-value or long-term protection.<ref name="linux-man-page"/>

A counterpart to {{nowrap|{{mono|/dev/random}}}} is {{nowrap|{{mono|/dev/urandom}}}} ("unlimited"<ref>{{cite web | url=https://repo.or.cz/w/davej-history.git/blob/d0562c8dc:/drivers/char/random.c#l682
| title=/dev/random and /dev/urandom implementation in Linux 1.3.39, function <code>random_read_unlimited</code>
| date=1995-11-04
| access-date=2013-11-21}}</ref>/non-blocking random source<ref name="linux-man-page"/>) which reuses the internal pool to produce more pseudo-random bits. This means that the call will not block, but the output may contain less entropy than the corresponding read from {{nowrap|{{mono|/dev/random}}}}. While {{nowrap|{{mono|/dev/urandom}}}} is still intended as a pseudorandom number generator suitable for most cryptographic purposes, the authors of the corresponding [[man page]] note that, theoretically, there may exist an as-yet-unpublished attack on the algorithm used by {{nowrap|{{mono|/dev/urandom}}}}, and that users concerned about such an attack should use {{nowrap|{{mono|/dev/random}}}} instead.<ref name="linux-man-page"/> However such an attack is unlikely to come into existence, because once the entropy pool is unpredictable it doesn't leak security by a reduced number of bits.<ref>{{cite AV media|url=https://media.ccc.de/v/32c3-7441-the_plain_simple_reality_of_entropy#video&t=1262|title=The plain simple reality of entropy|author=Filippo Valsorda|date=2015-12-29}}</ref>

It is also possible to write to {{nowrap|{{mono|/dev/random}}}}. This allows any user to mix random data into the pool. Non-random data is harmless, because only a privileged user can issue the [[ioctl]] needed to increase the entropy estimate.{{Dubious|date=December 2020|reason=This isn't the reason that writing non-random data is harmless. 1. The non-random data mixes with the random data in a way that keeps only the randomness, like XOR? That would make it harmless?  2. The entropy estimate is not increased when you write to it, according to https://linux.die.net/man/4/urandom, but it DOES affect the output, so that isn't what makes it harmless. 3. Only privileged users can update the entropy estimate, which doesn't make it harmless?}} The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in {{mono|/proc/sys/kernel/random/}} and can be displayed by the command {{code|cat /proc/sys/kernel/random/entropy_avail}} and {{code|cat /proc/sys/kernel/random/poolsize}} respectively.

=== Entropy injection ===
Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator<ref>{{cite web |last1=Gutterman |first1=Zvi |last2=Pinkas |first2=Benny |last3=Reinman |first3=Tzachy |date=2006-03-06 |title=Analysis of the Linux Random Number Generator |url=http://www.pinkas.net/PAPERS/gpr06.pdf |url-status=live |archive-url=https://web.archive.org/web/20081003041432/http://www.pinkas.net/PAPERS/gpr06.pdf |archive-date=2008-10-03 |access-date=2013-07-03}}</ref> in which they describe several weaknesses. Perhaps the most severe issue they report is with [[embedded system|embedded]] or [[Live CD]] systems, such as routers and [[diskless node|diskless clients]], for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.

The Linux kernel provides support for several [[hardware random number generator]]s, should they be installed. The raw output of such a device may be obtained from {{mono|/dev/hwrng}}.<ref>{{cite web
| url=http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
| title=Cryptography Users Guide
| date=2013-06-04
| publisher=[[Texas Instruments]]
| access-date=2013-07-03
| archive-date=2018-04-16
| archive-url=https://web.archive.org/web/20180416073524/http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
| url-status=dead
}}</ref>

With Linux kernel 3.16 and newer,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=be4000bc4644d027c519b6361f5ae3bbfc52c347|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ be4000bc4644d027c519b6361f5ae3bbfc52c347 "hwrng: create filler thread"|website=Git.kernel.org|access-date=18 October 2016}}</ref> the kernel itself mixes data from [[hardware random number generator]]s into {{nowrap|{{mono|/dev/random}}}} on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as {{mono|rngd}} from {{mono|rng-tools}}, is needed to do that job. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0,<ref>{{cite web|url=https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34679ec7a0c45da8161507e1f2e1f72749dfd85c|title=kernel/git/torvalds/linux.git - Linux kernel source tree @ 34679ec7a0c45da8161507e1f2e1f72749dfd85c "virtio: rng: add derating factor for use by hwrng core"|website=Git.kernel.org|access-date=18 October 2016}}</ref> and as such, is currently the only HWRNG mixed into {{nowrap|{{mono|/dev/random}}}} by default.

The entropy pool can be improved by programs like {{mono|timer_entropyd}}, {{mono|haveged}}, {{mono|randomsound}} etc.  With {{mono|rng-tools}}, [[hardware random number generator]]s like ''Entropy Key, etc.'' can write to {{nowrap|{{mono|/dev/random}}}}. The [[diehard tests]] programs {{mono|diehard}}, {{mono|dieharder}} and {{mono|ent}} can test these random number generators.<ref>{{cite web |url=http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |title=?? |website=Vanheusden.com |access-date=2016-10-23 |archive-url=https://web.archive.org/web/20130921054659/http://www.vanheusden.com/te/timer_entropyd-0.1.tgz |archive-date=2013-09-21 |url-status=dead }}</ref><ref>{{cite web|url=https://code.google.com/p/dieharder/|title=Google Code Archive for dieharder|website=Code.google.com|access-date=18 October 2016}}</ref><ref>{{cite web|url=http://stat.fsu.edu/pub/diehard/|title=The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness|website=Stat.fsu.edu|access-date=2016-10-23|archive-url=https://web.archive.org/web/20160125103112/http://stat.fsu.edu/pub/diehard/|archive-date=2016-01-25|url-status=dead}}</ref><ref>{{cite web|url=https://www.gnu.org/software/hurd/user/tlecarrour/rng-tools.html|title=rng-tools|website=Gnu.org|access-date=2016-10-23}}</ref>

=== 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>