NAME

SYNOPSIS

DESCRIPTION

The various random devices produce random output data with different ran-
dom qualities. Entropy data is collected from system activity (like disk
and network device interrupts and such), and then run through various
hash or message digest functions to generate the output.
/dev/random This device is reserved for future support of hardware
random generators.
/dev/srandom Strong random data. This device returns reliable random
data. If sufficient entropy is not currently available
(i.e., the entropy pool quality starts to run low), the
driver pauses while more of such data is collected. The
entropy pool data is converted into output data using MD5.
/dev/urandom Same as above, but does not guarantee the data to be
strong. The entropy pool data is converted into output
data using MD5. When the entropy pool quality runs low,
the driver will continue to output data.
/dev/prandom Starting from MirOS #10uB5, this reads from the same dev-
ice as /dev/arandom does, but still writes back to the
pool safe for unprivileged users. Before, it returned sim-
ple pseudo-random numbers.
/dev/wrandom This device is actually the same as /dev/prandom, but can
be written to by regular users, even if this interface is
simulated using pipes or other means on other operating
systems where /dev/prandom can only be read from. Its pur-
pose is to allow anything from userspace or other not 100%
trustworthy sources to contribute even fractional bit
amounts of entropy into the kernel pool by hashing, col-
lapsing, and rate-limiting.
/dev/arandom As required, entropy pool data re-seeds an ARC4 generator,
which then generates high-quality pseudo-random output
data.
The arc4random(3) function in userland libraries seeds it-
self from this device, providing a second level of ARC4
hashed data.
The arc4random_pushb_fast(3) function, any write access to the KERN_ARND
sysctl(3) and writes to /dev/wrandom feed data back to the kernel as
described above and in arc4random(9).