/dev/random
In Unix-like operating systems, ,  and  are special files that serve as pseudorandom number generators. They allow access to environmental noise collected from device drivers and other sources.    typically blocked if there was less entropy available than requested; more recently (see below, different OS's differ) 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.  blocks after boot until the seed has been securely initialized with enough entropy, and then never blocks again. Not all operating systems implement the same methods for  and  and only a few provide .

Example 

> hexdump -C -n 8 /dev/random
0000000 79 5d 13 c2 b4 fe ca d7 |y].Â´þÊ×|
> hexdump -C -n 8 /dev/random
0000000 bd f1 6d 48 10 f8 25 3c |..mH..%<|

This shell script is a random printable character generator, slightly biased:

#!/bin/sh
printf " \$ti";
read pngs</dev/urandom;
pc=1;
while [ $pc -le $(((${#pngs}%5)+8)) ]; do
  read s s2</dev/urandom;
  printf "\n\n";
  printf `printf "\\%o" "$(((${#s}%26)+65))"`;
  printf `printf "\\%o" "$(((${#s2}%26)+97))"`;
  l=${#s};
  i=1;
  while [ $i -le $l ]; do
    c=`printf %c "${s%${s#?}}"`;
    s=${s#?};
    cc=`printf %d \`printf "\047$c" 2>&-\``;
    printf `printf "\\%o" "$((((cc+i)%95)+32))"`;
    i=$((i+1));
  done;
  pc=$((pc+1));
done;

Linux

Random number generation in kernel space was implemented for the first time for Linux in 1994 by Theodore Ts'o.
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"/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.

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 .

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. With Linux kernel 3.17+, the VirtIO RNG was modified to have a default quality defined above 0, and as such, is currently the only HWRNG mixed into  by default.

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.

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:
 Z generates a random value of r.
 Z computes .
 If the output of  is equal to the desired value, output r as z.
 Else, repeat starting at 1.
Bernstein estimated that an attacker would need to repeat  16 times to compromise DSA and ECDSA.  This is possible because Linux reseeds H on an ongoing basis instead of using a single high quality seed.

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.

In 2020, the Linux kernel version 5.6  only blocks when the CPRNG hasn't initialized. Once initialized,  and  behave the same.

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.

Since OpenBSD 5.1 (May 1, 2012)  and  use an algorithm based on RC4 but renamed, because of intellectual property reasons, ARC4. While random number generation here uses system entropy gathered in several ways, the ARC4 algorithm provides a fail-safe, ensuring that a rapid and high quality pseudo-random number stream is provided even when the pool is in a low entropy state. 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. As of OpenBSD 5.5 (May 1, 2014), the  call used for OpenBSD's random devices no longer uses ARC4, but ChaCha20 (arc4random name might be reconsidered as A Replacement Call for Random).

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,
NetBSD,
Tru64 UNIX 5.1B, AIX 5.2 and HP-UX 11i v2. 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.

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.

While DOS does not naturally provide such functionality, there is an open-source third-party driver called , which functions similarly in that it creates two devices,  and , which are also accessible as  and , that programs can access for random data.

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

EGD as an alternative
A software program called EGD (entropy gathering daemon) is a common alternative for Unix systems that do not support the  device.  It is a user-space daemon, which provides high-quality cryptographic random data.  Some cryptographic software such as OpenSSL, GNU Privacy Guard, and the Apache HTTP Server support using EGD when a  device is not available. OpenSSL disabled support for the EGD daemon by default in OpenSSL 1.1.0; applications should check for support using the  preprocessor macro.

EGD gathers random entropy from various sources, processes it to remove bias and improve cryptographic quality, and then makes it available over a Unix domain socket (with  being a common choice) or over a TCP socket.  The entropy gathering usually entails periodically forking subprocesses to query attributes of the system that are likely to be frequently changing and unpredictable, such as monitoring CPU, I/O, and network usage as well as the contents of various log files and temporary directories.

The alternative PRNGD, is a compatible pseudo-random source.

EGD communicates with other programs that need random data using a simple protocol.  The client connects to an EGD socket and sends a command, identified by the value of the first octet:
 command 0: query the amount of entropy currently available.  The EGD daemon returns a 4-byte number in big-endian format representing the number of random bytes that can currently be satisfied without delay.
 command 1: get random bytes, no blocking.  The second byte in the request tells EGD how many random bytes of output it should return, from 1 to 255.  If EGD does not have enough entropy to immediately satisfy the request, then fewer bytes, or perhaps no bytes, may be returned.  The first octet of the reply indicates how many additional bytes, those containing the random data, immediately follow in the reply.
 command 2: get random bytes, blocking.  The second byte tells EGD how many random bytes of output it should return.  If EGD does not have enough entropy, it will wait until it has gathered enough before responding.  Unlike command 1, the reply starts immediately with the random bytes rather than a length octet, as the total length of returned data will not vary from the amount requested.
 command 3: update entropy.  This command allows the client to provide additional entropy to be added to EGD's internal pool.  The next two bytes, interpreted as a 16-bit big-endian integer indicate how many bits of randomness the caller is claiming to be supplying.  The fourth byte indicates how many additional bytes of source data follow in the request.  The EGD daemon may mix in the received entropy and will return nothing back.

See also
 CryptGenRandom – The Microsoft Windows API's CSPRNG
 
 Entropy-supplying system calls
 Fortuna algorithm
 Hardware random number generator
 Standard streams

References

External links
 
 

Unix file system technology
Device file
Random number generation