NAME

random, urandom - random numbers from the kernel

SYNOPSIS

/dev/random
/dev/urandom

DESCRIPTION

Reading either device gives random bytes, as many as asked for. Programs that need random numbers for keys, salts, temporary names or seeds read them here; Python's os.urandom and secrets do.

The two devices are the same generator and behave the same: neither ever blocks, and there is no count of entropy. /dev/random is there for programs that open it by that name.

The generator is ChaCha20 (RFC 8439) with a 256-bit key. Every read ends by replacing the key with output no one sees, so a later state of the kernel tells nothing about bytes read before; the key also changes every 64 KiB within one long read.

What is written to either device is mixed into the key, by anyone; it can only add to what the generator knows, never take away. The kernel also mixes in, at load, at every open and at every read, the clock ticks since boot, the beam position of the chipset and the timers of both CIAs. After a boot those are guessable, so the boot step randseed(1M) writes in the seed saved at the last shutdown, the date and the process table before anything else uses the devices.

The driver is the loadable module random, of the demand class: it loads at the first open of either device, and is never unloaded, since that would lose what was written in.

FILES

/dev/random

character major 48, minor 0.

/dev/urandom

character major 48, minor 1.

/etc/conf/mod.d/random

the module.

/etc/random-seed

the seed kept across reboots, 512 bytes, readable by root only.

DIAGNOSTICS

Another minor number gives ENXIO. The devices have no ioctl and cannot be mapped.

EXAMPLES

dd if=/dev/urandom bs=16 count=1 | od -x
echo something only I know > /dev/urandom

SEE ALSO

randseed(1M)

NOTES

The module needs a kernel cut with c 48 (k30 -64 or later, k46 -53 or later) and kbootset 1.1.0.261031-30 or later, the first whose registry has random. An older kernel refuses to load it, and an older kbootset refuses a generation that holds it.