Simply:
Paranoia abounds! well maybe a bit - we are in a situation where we don't trust our tools - especially our crypto tools - this project is an attempt to create a cheap open source entropy generator that's open enough that one can verify and trust it.
We've based our design on an existing platform - our Cheap RF system - mostly because it's cheap to build, we had existing hardware, and had just finished bringing up a USB stack for it
Our simple device is a USB stick, it is open source hardware, you can build your own, runs open source firmware - and you can physically open it to make sure that what's inside is what you expect. With an external programmer you can also program it with your own firmware.
We generate ~350kbits per second of entropy packaged at ~7 bits/byte - if you use the entropy data at a lower it accumulates and we quickly approach 8 bits/byte.
First of all - have a look at the board, remove the 'tin foil hat' (a shield to keep the RF noise in and the external interference out) and make sure that the component layout looks like this:
PHOTO TO BE ADDED
In particular check that you have a CC2531 and that it is a 128k or 256k part - write that down somewhere
Stick it in any USB slot - the light should come on almost immediately - the light indicates that entropy is available in the device's internal entropy pool - it will dim when entropy is being extracted. If you are using the RF noise source you may see it flicker periodically as the receiver shifts to a random channel. If it blinks in one or two 1 second blinks it indicates that the avalanche diode noise source is broken and the firmware has detected it is stuck at 0 or 1 - in this case data will not be entered into the entropy pool.
Modern computers need a source of entropy to seed their random number generators - entropy is simply 'randomness' - for example on a Unix/Linux computer random numbers are available from /dev/random, the kernel generates small amounts of entropy into its entropy pool which feeds the random number generator, if applications empty out the pool they will have to slow down and wait until more entropy is available. Programs that use lots of randomness, for example crypto creating lots of SSL certs will perform poorly.
On a Linux machine we can extract our entropy from our device by simply reading from the terminal interface that is created when it's plugged in and writing that data into the kernel entropy pool - the rngd system daemon will do that for us.
Our generator makes random streams of bytes - they're generated by random quantum processes and/or thermal noise - they're don't however present a perfectly randomly distributed bit stream - we get wporst case about 7 bits of entropy per byte of data presented - it is recommended that you use our generator to feed your kernel random number generator's entropy pool rather than using the data directly. The installation instructions above show you how.
Our entropy generator includes two noise sources, you can choose to use either or both.
The primary noise generator is an avalanche diode (actually a pair of transistors) - it generates a series of random pulses at a frequency faster than we are sampling - we've tweaked the sampling level so that we sample a 1 or 0 roughly 50% of the time - because components are never exactly the same each device will be slightly different, some will sample slightly more 1s than others.
We've measured that our circuit samples slightly more 1s than 0s (about 5% more) - this corresponds to ~7bits/byte of entropy - we could make something with more finely tuned parts, but that would require having someone tweak the circuit on the assembly line, it would likely end up costing twice the price, or more for minimal gain.
The secondary noise generator is an RF receiver built into the CC2531 - it randomly (in time and frequency) skips around channels in and around the 2.4GHz wifi band measuring RF signal levels and sampling just the least significant bit - the CC25xx system document has some analysis of the use of this technique you can look at - we're measuring a very slight bias (0.14% more 1s than 0s). This performance is better than the avalanche diode circuit, but RF is by definition theoretically more susceptible to outside manipulation.
The default setting has the primary (avalanche diode) noise source enabled, and the secondary (RF source) disabled
Because our byte streams have the minor built in sampling biases mentioned above it's useful to be able to pass them through a 'whitening' stage - a process that mixes up the bits to even out the number of 1s and 0s without reducing the amount of entropy present in the byte stream. Some applications like rngd check for bitsream sanity and will complain if there are too many more ones or zeros - whitening helps them accept our bitstream and feed it to thye kernel random number generator.
In our case we have a CRC16 generator to use for whitening, when it's enabled we push each byte into the generator and extract the upper byte of the running CRC sum - this means that the bits of adjacent bytes are merged and xored together evening out the number of ones and zeros. This operation can be turned on or off, by default it's turned on. If you want the raw data turn it off.
Internally most of the device's RAM is used as an entropy pool:
Data is sourced a byte at a time from the two noise sources, if both are enabled alternate bytes are taken from each one, if the whitener is turned on the byte is passed through it.
The entropy pool works as a FIFO until it is full, subsequent data is continually xored into the pool as a ring buffer
.When data is copied from the entropy pool to the USB controller it is cleared.
The CC2531 has AES support, we don't use it in the system firmware - but if want to you're welcome to use it - sample code is available in the base Cheap RF kernel (RF and crypto support has been removed from the version of the OS used here).
The basic interface to the device is a simple terminal interface - commands are written to the device, entropy data is returned. All commands are ascii, 4 bytes the first 3 of are always "cmd" (always lower case) followed by a single letter command, any other data is ignored.
There are only a small number of commands:
| Value | Avalanche Disable | RF Enable | Whitener Disable | Funcion |
| cmd0 | 0 | 0 | 0 | Avalanche noise with whitener (default) |
| cmd1 | 0 | 0 | 1 | Raw avalanche noise |
| cmd2 | 0 | 1 | 0 | Avalanche noise and RF noise with whitener |
| cmd3 | 0 | 1 | 1 | Raw avalanche noise and RF noise |
| cmd4 | 1 | 0 | 0 | No noise |
| cmd5 | 1 | 0 | 1 | No noise |
| cmd6 | 1 | 1 | 0 | RF noise with whitener |
| cmd7 | 1 | 1 | 1 | Raw RF noise |
| Offset | Bytes | Function |
| 0x000000 | 6 | Magic number - frames the data in the data stream 0xFEEDBEEF2014 |
| 0x000006 | 3 | size in bytes |
| 0x000009 | 2 | firmware VERSION |
| 0x00000b | 2 | actual code szie |
| 0x00000d | 128k/256k | firmware image |
We have a Programming page it includes:
We're still in the alpha testing process, we don't have boards available for sale at this date, most are still hand-built, but please feel free to make a case for a dev system - drop Paul a note
Check out the various Github repositories for their various licenses - as a rule software is LGPLed while hardware is GPLed.
No one does this alone, the great thing about open source is that we all get to stand on the shoulders of giants