Entropy and Random Numbers
I know the OneRNG is called a "Random Number Generator", but that isn't really what it does!
Good random numbers have a couple of main properties - they are unpredictable and evenly distributed across their full range. Sometimes it can be difficult to determine the difference, so here's a concrete example - look at the dice images at the top of this page. Every time the page loads, the dice are different; effectively unpredictable. Except you can always predict with 100% accuracy the value of the final die, once you know what the other 5 are ...
The reason for that is that the dice are simply in a randomised order; there are always 6 unique values, from 1 to 6 inclusive. Distribution is perfectly even, and while the first die value is as unpredictable as we can get it, the remaining ones are increasingly predictable to the point of uselessness (in practice the whole thing is driven by JavaScript's Math.random() function, which isn't really all that random internally at all! See the small source file for details).
So you need to have both features to be useful. Let's see how the OneRNG helps us make random numbers :-
The OneRNG generates Entropy
The OneRNG generates informational entropy by measuring internal RF noise sources, specifically an avalanche diode circuit (the primary source), and a channel-hopping radio receiver (secondary source).
The noise from these systems is completely unpredictable, and we sample this noise to produce a stream of data that can be loosely described as "random". However, this stream of data will always be biased; for example there will tend to be more "1"s than "0"s.
In practice, the avalanche diode system picks up a slight DC bias, and generates about 5% more 1s than 0s. The RF receiver tends to work better, with only about 0.14% more 1s; but it is potentially more vulnerable to outside interference so we prefer to stick with the avalanche diode.
(If a noise source has failed, the OneRNG firmware will detect the resultant sequence of very biased data (such as "all 0s") and refuse to use the source, effectively shutting down.)
A Whiter Shade of Pale
We can see that the data coming from the OneRNG's primary source is fundamentally unpredictable, but isn't perfectly evenly distributed. We can describe the quality of the primary source as delivering roughly 7 bits of entropy for every 8 bits of data.
This data needs to be improved before it can be used. This job is called "whitening", and the technology generally used to do is is a "hash function". Hashes are intended to help compute data references (rather than directly use the data themselves), and because they try hard to avoid "collision" (where two different input data can produce the same output) and are generally not "invertable" (i.e. you cannot reasonably work backwards from the output to discover what the input was), they turn out to be very good for smoothing out the distribution of values in cases like ours.
We have a whitening hash function onboard the OneRNG (a CRC16 generator) that you can use, but it is not enabled by default - we recommend that instead you just add the OneRNG as an entropy source to your existing Operating System's random number generator.
OS Entropy Sources
The various different Operating Systems in use today collect their entropy from all the places that they believe they can find real-world unpredictability. Computers are inherently completely predictable in their operation - if you can describe the current condition of the machine, you know what state it will go to next, perfectly. Of course they are increasingly complex, which makes this job impossible in practice!
Linux collects timing data from the keyboard and mouse usage, and from the IDE disks. You can also elect to collect data from any specialist RNG hardware on your system, such as the Intel RdRand CPU instruction or a Trusted Platform Module. Many systems today, especially servers, don't have keyboards, mice, or even IDE disks; and many people elect to distrust vendor hardware systems for highly sensitive tasks (although see "On Trust").
OS Random Number Sources
Sticking with the example of Linux, /dev/random provides random numbers by directly hashing the internal entropy pool. Each use of /dev/random depletes the data available, and if the entropy sources cannot deliver sufficient data, your request to read /dev/random will block - it will wait until more entropy is available.
For almost every normal task, you are supposed to instead use /dev/urandom. This interface internally does exactly the same as /dev/random, except that when the entropy pool is close to exhaustion it will instead start to deliver data from a software device, a PRNG that has been seeded from 'good' random data.
If you use the OneRNG to populate Linux's entropy pool data directly, both systems are "improved" - high-quality reads from /dev/random will not block (unless you are exceptionally greedy), and /dev/urandom will not need to fall back to PRNGs.
