/dev/random

Quality 0.50 · 1 view · Updated 2 months ago

Pseudorandom number generator file in Unix-like operating systems

title: "/dev/random" type: doc version: 1 created: 2026-02-28 author: "Wikipedia contributors" status: active scope: public tags: ["unix-file-system-technology", "device-file", "random-number-generation"] description: "Pseudorandom number generator file in Unix-like operating systems" topic_path: "technology/operating-systems" source: "https://en.wikipedia.org/wiki//dev/random" license: "CC BY-SA 4.0" wikipedia_page_id: 0 wikipedia_revision_id: 0

::summary Pseudorandom number generator file in Unix-like operating systems ::

::figure[src="https://upload.wikimedia.org/wikipedia/commons/9/91/Hexdump_of_dev_urandom.png" caption="/dev/urandom}}}}"] ::

In Unix-like operating systems, **** and **** are special files that provide random numbers from a cryptographically secure pseudorandom number generator (CSPRNG). The CSPRNG is seeded with entropy (a value that provides randomness) from environmental noise, collected from device drivers and other sources. Users can obtain random numbers from the CSPRNG simply by reading the file.{{cite web | url=https://man7.org/linux/man-pages/man7/random.7.html | title=random(7) - Linux manual page | date=2023-02-10 | access-date=2023-11-24

In older operating systems, typically blocked if there was less entropy available than requested; more recently (see below for the differences between operating systems) it usually blocks at startup until sufficient entropy has been gathered, then unblocks permanently. The device typically was never a blocking device, even if the pseudorandom number generator seed was not fully initialized with entropy since boot.

This special file originated in Linux in 1994. It was quickly adopted by other Unix-like operating systems.

Linux

::figure[src="https://upload.wikimedia.org/wikipedia/commons/6/60/Rngtest_FIPS-140-2_screenshot.png" caption="/dev/random}}}} pool"] ::

The Linux kernel provides the separate device files and . Since kernel version 5.6 of 2020, only blocks when the CSPRNG hasn't initialized. Once initialized, and behave the same.

In October 2016, with the release of Linux kernel version 4.8, the kernel's was switched over to a ChaCha20-based cryptographic pseudorandom number generator (CPRNG) implementation by Theodore Ts'o, based on 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.

Original implementation

Random number generation in kernel space was implemented for the first time for Linux{{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 |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 The implementation used secure hashes rather than ciphers, to avoid 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 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 bits of noise in the entropy pool. From this entropy pool random numbers are created. When read, the 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 will block until additional environmental noise is gathered. 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.

A counterpart to is ("unlimited"{{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 random_read_unlimited | date=1995-11-04 | access-date=2013-11-21}}/non-blocking random source) 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 . While 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 , and that users concerned about such an attack should use instead. 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.

It is also possible to write to . 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. The current amount of entropy and the size of the Linux kernel entropy pool, both measured in bits, are available in and can be displayed by the command and respectively.

Entropy injection

Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems, such as routers and 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 generators, should they be installed. The raw output of such a device may be obtained from .{{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

With Linux kernel 3.16 and newer, the kernel itself mixes data from hardware random number generators into on a sliding scale based on the definable entropy estimation quality of the HWRNG. This means that no userspace daemon, such as from , is needed to do that job.

The entropy pool can be improved by programs like , , etc. With , hardware random number generators like Entropy Key, etc. can write to . The diehard tests programs , and can test these random number generators.

Critique of entropy injection

In January 2014, Daniel J. Bernstein published a critique 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 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:

  1. Z generates a random value of r.
  2. Z computes .
  3. If the output of is equal to the desired value, output r as z.
  4. Else, repeat starting at 1. Bernstein estimated that an attacker would need to repeat 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.

Bernstein also argues that entropy injection is pointless once the CSPRNG has been initialized.

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

BSD systems

The FreeBSD operating system provides a link to . Both block only until properly seeded. FreeBSD's PRNG (Fortuna) reseeds regularly, and does not attempt to estimate entropy. On a system with small amount of network and disk activity, reseeding is done after a fraction of a second.

DragonFly BSD inherited FreeBSD's random device files when it was forked.

Since OpenBSD 5.1 (May 1, 2012) and uses arc4random, a CSPRNG function based on RC4. The function was changed to use the stronger ChaCha20 with OpenBSD 5.5 (May 1, 2014). The system automatically uses hardware random number generators (such as those provided on some Intel PCI hubs) if they are available, through the OpenBSD Cryptographic Framework.{{cite web |url=http://bxr.su/OpenBSD/lib/libc/crypt/arc4random.c |title=libc/crypt/arc4random.c |website=BSD Cross Reference, OpenBSD src/lib/ |editor=deraadt |editor-link=Theo de Raadt |date=2014-07-21 |access-date=2015-01-13 |quote=ChaCha based random number generator for OpenBSD.}} was removed in OpenBSD 6.3 (April 15, 2018).{{cite web |url=https://github.com/openbsd/src/commit/0d60993c06101c0a9e6fb6c3a3302133f1b65f98 |title=src/etc/MAKEDEV.common |website=GitHub OpenBSD source code mirror src/etc/ |editor=naddy |date=2017-11-14 |access-date=2017-11-14 |quote=/dev/arandom removed from OpenBSD.}}

NetBSD's implementation of the legacy API has been switched over to ChaCha20 as well.

macOS, iOS and other Apple OSes

All Apple OSes have moved to Fortuna since at least December 2019, possibly earlier. It is based on SHA-256. Multiple entropy sources such as the secure enclave RNG, boot phase timing jitter, hardware interrupt (timing assumed) are used. RDSEED/RDRAND is used on Intel-based Macs that support it. Seed (entropy) data is also stored for subsequent reboots.

Prior to the change, macOS and iOS used 160-bit Yarrow based on SHA-1.

There is no difference between and ; both behave identically.

Other operating systems

and are also available on Solaris,{{cite web | url=https://blogs.oracle.com/solaris/post/solaris-random-number-generation | title=Solaris Random Number Generation | first=Darren | last=Moffat | work=Oracle Solaris Blog | date=2013-09-12 | access-date=2022-04-30 NetBSD, Tru64 UNIX 5.1B,{{cite web | url=http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51B_HTML/MAN/MAN4/0199____.HTM | title=random(4) | date=1999-09-19 | access-date=2013-07-03}} AIX 5.2{{cite web |url = http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.files/doc/aixfiles/random.htm |title = random and urandom Devices |work = pSeries and AIX Information Center |date = 2010-03-15 |access-date = 2013-07-03 |archive-url = https://web.archive.org/web/20210303075907/http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=%2Fcom.ibm.aix.files%2Fdoc%2Faixfiles%2Frandom.htm |archive-date = 2021-03-03 |url-status = dead | url=http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=KRNG11I | title=HP-UX Strong Random Number Generator | date=2004-07-23 | access-date=2013-07-03}} As with FreeBSD, AIX implements its own Yarrow-based design, however AIX uses considerably fewer entropy sources than the standard implementation and stops refilling the pool when it thinks it contains enough entropy.{{cite web | url=http://lists.gnupg.org/pipermail/gnupg-devel/2003-April/019954.html | title=AIX 5.2 /dev/random and /dev/urandom devices | first=Iain | last=Roberts | date=2003-04-25 | publisher=Lists.gnupg.org | access-date=2013-07-03 | archive-url=https://web.archive.org/web/20120222144110/http://lists.gnupg.org/pipermail/gnupg-devel/2003-April/019954.html | archive-date=2012-02-22 | url-status=live}}

In Windows NT, similar functionality is delivered by , but reading the special file does not work as in UNIX. The documented methods to generate cryptographically random bytes are CryptGenRandom and RtlGenRandom. Windows PowerShell provides access to a cryptographically secure pseudorandom number generator via the cmdlet.

Cygwin on Windows provides implementations of both and , which can be used in scripts and programs.

References

References

  1. "/dev/random Is More Like /dev/urandom With Linux 5.6 - Phoronix".
  2. (2016-07-27). "kernel/git/torvalds/linux.git - Linux kernel source tree". kernel.org.
  3. "Linux 5.17 Random Number Generator Seeing Speed-Ups, Switching From SHA1 To BLAKE2s - Phoronix".
  4. {{man. 4. random. Linux
  5. Filippo Valsorda. (2015-12-29). "The plain simple reality of entropy".
  6. (2006-03-06). "Analysis of the Linux Random Number Generator".
  7. "kernel/git/torvalds/linux.git - Linux kernel source tree @ be4000bc4644d027c519b6361f5ae3bbfc52c347 "hwrng: create filler thread"".
  8. "??".
  9. "Google Code Archive for dieharder".
  10. "The Marsaglia Random Number CDROM including the Diehard Battery of Tests of Randomness".
  11. "rng-tools".
  12. Daniel J. Bernstein. (2014-02-05). "cr.yp.to: 2014.02.05: Entropy Attacks!".
  13. "[PATCH 5.15 038/145] random: use computational hash for entropy extraction".
  14. {{man. 4. random. FreeBSD
  15. "random(4)".
  16. "A comparison of /dev/random speed on Linux and BSD".
  17. {{man. 4. random. OpenBSD
  18. (2014-11-16). "libc/gen/arc4random.c".
  19. "Apple Platform Security". [[Apple Inc.]].
  20. "xnu/bsd/dev/random at xnu-1456.1.26 - apple-oss-distributions/xnu". [[Apple Inc.]].
  21. {{man. 4. random. Darwin
  22. (October 2012). "iOS Security". [[Apple Inc.]].
  23. {{man. 4. rnd. NetBSD
  24. "Get-SecureRandom (Microsoft.PowerShell.Utility) - PowerShell".
  25. "How does Cygwin's /dev/random and urandom work?".

::callout[type=info title="Wikipedia Source"] This article was imported from Wikipedia and is available under the Creative Commons Attribution-ShareAlike 4.0 License. Content has been adapted to SurfDoc format. Original contributors can be found on the article history page. ::

unix-file-system-technologydevice-filerandom-number-generation