Linux has two random number generators available to userspace, /dev/random
and /dev/urandom
.
/dev/random
is a source of "true" randomness - i.e. it is not generated by a pseudo-random number generator. Entropy is fed into this by the input driver and the interrupt handler, through the functions add_input_randomness
and add_interrupt_randomness
. Processes reading this device will block if the entropy runs out.
/dev/urandom
is a pseudo-random number generator. It is fed by the same entropy pool as /dev/random
, but when that runs out, it switches to a cryptographically strong generator.
Userspace applications can feed into the entropy pool by writing to /dev/{,u}random
.
Have a read of the random(4) manual page, and the file drivers/char/random.c
in the kernel source tree. It is well commented and most of what you ask is explained there.
FreeBSD's /dev/random
by default is a pseudo-random number generator using the Yarrow algorithm (but can point to a hardware RNG if one is connected). The software generator takes entropy from Ethernet and serial connections and hardware interrupts (changeable through sysctl kern.random
). The Yarrow algorithm is believed to be secure as long as the internal state is unknown, therefore /dev/random
should always output high-quality data without blocking.
See random(4).
On NetBSD, /dev/random
provides random data based only on entropy collected (from disks, network, input devices, and/or tape drives; adjustable using rndctl), while /dev/urandom
falls back to a PRNG when the entropy pool is empty, similar to Linux.
See random(4), rndctl(8), rnd(9).
OpenBSD has four generators: /dev/random
is a hardware generator, /dev/srandom
is a secure random data generator (using MD5 on the entropy pool: "disk and network device interrupts and such"), /dev/urandom
is similar but falls back to a PRNG when the entropy pool is empty. The fourth, /dev/arandom
, is also a PRNG but using RC4.
See random(4), arc4random(3).
Mac OS X also uses the Yarrow algorithm for /dev/random
, but has an identically working /dev/urandom
for compatibility. "Additional entropy is fed to the generator regularly by the SecurityServer daemon from random jitter measurements of the kernel." See random(4).
As the Wikipedia page says:
It is also possible to write to /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. The current amount of entropy and the size of the Linux kernel entropy pool are available in /proc/sys/kernel/random/, which can be displayed by the command cat /proc/sys/kernel/random/entropy_avail.
So, in your case, if you are really intent on injecting some randomness obtained from the RaspberryPi as a file, then all you need is to write the file into /dev/random
with a simple "cat randomfilefromrasp > /dev/random
". What would be more complex (and require extra rights) would be to assert that the extra randomness ensures some given value of extra "entropy". But it matters only for the irksome blocking mechanism of /dev/random
(this device tends to block when it supposes that it has burnt all its entropy); your extra file still gets added to the mix and will contribute to the actual entropy (i.e. you do get the security benefits, even if the kernel does not notice it).
Best Answer
Most commodity PC hardware has a random number generator these days. VIA Semiconductor has put them in their processors for many years; the Linux kernel has the via-rng driver for that. I count 34 source modules in the
drivers/char/hw_random/
directory in the latest source tree, including drivers for Intel and AMD hardware, and for systems that have a TPM device. You can run the rng daemon (rngd) to push random data to the kernel entropy pool.