Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

My current understanding of an entropy pool is that it gathers truly random bits of data at a slow rate. I'd like to know how Unix & Linux collect entropy, and how that entropy is used by /dev/random.

I've heard (generically) of entropy collection methods such as the video card cpu's status when a "randomly" selected network packet arrives, matched against the hiss factor in the digital-analog converter, and other even more obtuse methods.

I believe that the entropy "pool" is tapped as need be, and is used to seed a psuedo random generator....

I'm not after an in-depth answer, but I am interested to know if this is the general approach used by Unix/Linux ?.. and perhaps some hints about what is actually going on at the entropy-collection coal-face... and then, what is the entropy fed into.. Is it an AES Rijndael cipher?

The background information for my comemnts above, came from Steve Gibson's Security Now! podcast: Episode #301 Going Random, Part 2 of 2... He only spoke generically (but as is his style, with enough detail and clarity so that even I could understand him. Having listened to the preceding 300 episodes helps :), ...and I'd like to know if this is how Unix/Linux does it...

share|improve this question

1 Answer 1

up vote 14 down vote accepted

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

share|improve this answer
    
Thanks. A good overview, and from the source, I see we are secure in the hands of a Twisted Generalized Feedback Shift Register (scary stuff :) ... Along with obtuse "random" inputs to the pool, it seems that a SHA hash is generated "across the pool, 16 words (512 bits) at a time" and mixed back into the pool, and then a few more gyrations are perfomed on the pool... Steve Gibson comments in his podcast that: SHA-256 uses/is the strongest state-of-the-art hash we have. ... I didn't discover what generates /dev/urandom output, but the lead-up process is certainly significant –  Peter.O Jun 2 '11 at 11:59
    
+1, good answer; I once tried to generate random character data with cat /dev/random and always wondered why my stream stopped after so many characters –  Mike Pennington Jun 2 '11 at 12:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.