∞ Noise

(Quick reminder, before it becomes obvious from the text — I have more interest in hardware random number generation than I have understanding …)

Just got Bill “WaywardGeek” Cox’s Infinite Noise USB Random Number Generator. It uses very few components, and doesn’t even have a microcontroller on board. It relies on the controlled amplification of thermal noise as its entropy source.

Not great enhanced image of the Infinite Noise board. Yes, that's all there is to it
Not great enhanced image of the Infinite Noise board. Yes, that’s all there is to it

As it’s so very simple, it uses a driver to read from the device, and then hashes the data to reduce the data stream to very close to pure noise. Building the driver is easy, once you work it that the code lives in the infnoise/software folder on the author’s github repo.

Normal operation would look like this:

sudo ./infnoise | entropy_consuming_program …

as in

sudo ./infnoise | rngtest -t 10

which I left running for a work day to get

…
rngtest: bits received from input: 10327720032
rngtest: FIPS 140-2 successes: 515955
rngtest: FIPS 140-2 failures: 431
rngtest: FIPS 140-2(2001-10-10) Monobit: 63
rngtest: FIPS 140-2(2001-10-10) Poker: 61
rngtest: FIPS 140-2(2001-10-10) Runs: 162
rngtest: FIPS 140-2(2001-10-10) Long run: 151
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=29.022; avg=178.828; max=19531250.000)Kibits/s
rngtest: FIPS tests speed: (min=17.403; avg=30.153; max=85.917)Mibits/s
rngtest: Program run time: 56727702860 microseconds

So from its success to failure rate, it produces pretty decent (for my casual use) results. These bytes chug out at around 22¾ Kbytes/second; not screamingly fast, but decent, considering the very simple hardware.

You can run the hardware without hashing/whitening, and the results (from a much shorter run) are less solid:

sudo ./infnoise --raw | rngtest -t 10
…
rngtest: bits received from input: 15499264
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 774
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 774
rngtest: FIPS 140-2(2001-10-10) Runs: 774
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=27.201; avg=355.760; max=9765625.000)Kibits/s
rngtest: FIPS tests speed: (min=24.868; avg=30.488; max=41.554)Mibits/s
rngtest: Program run time: 49831593 microseconds

Another naïve test is seeing how images made from the data stream look:

don't stare at this too long, or richard d james's grinning mug will appear
random bytes (PNG), file size 49435 bytes
nvrandom20150121074051
raw bytes (PNG), file size 45421 bytes

Each of these 128 pixel squares should be no less than 49152 (= 128 × 128 × 3) bytes — plus the size of any PNG header/metadata — in size. The fact that the raw output is smaller shows that PNG’s compressor found some patterns it could work with.

It’s a fun little device, and Bill is adding new code and features to the driver at waywardgeek/infnoise regularly.

Screamingly fast HWRNG on Arduino Due

Well, look at this:

$ stty -F /dev/ttyACM0 speed 115200 raw cs8
$ rngtest -t 6 < /dev/ttyACM0
  … much snippage …
rngtest: bits received from input: 312368864
rngtest: FIPS 140-2 successes: 15602
rngtest: FIPS 140-2 failures: 16
rngtest: FIPS 140-2(2001-10-10) Monobit: 2
rngtest: FIPS 140-2(2001-10-10) Poker: 2
rngtest: FIPS 140-2(2001-10-10) Runs: 8
rngtest: FIPS 140-2(2001-10-10) Long run: 4
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=837.317; avg=1168.033; max=1948.060)Kibits/s
rngtest: FIPS tests speed: (min=16.834; avg=27.779; max=77.221)Mibits/s
rngtest: Program run time: 271917796 microseconds

Over a megabit/second of decent quality random data. This is from an Arduino Due, which has an Atmel SAM3X8E ARM Cortex-M3 microcontroller on board. I hadn’t found much use for this board previously, as it fell between a regular 8-bit Arduino and my (many!) Raspberry Pis.

This changed when I found out about Walter Anderson’s Entropy library, which uses µc timer jitter as a source of entropy. Originally designed as a slow but true source of random integers on the Atmel AVR chips, it’s been extended to use the SAM3X8E‘s built-in hardware RNG. Since the Due has a native USB port, you’re not limited to standard baud rates.

Here’s the code, trivially modified from one of Walter’s examples:

// Generate_Random_Bytes_Due - speedy demo of Arduino Due's HWRNG
// based on Generate_Random_Bytes, for Entropy, an Arduino library.
// Copyright 2012 by Walter Anderson
//  modified - scruss - 2014-08-13
// remember to reconnect to native USB port

#include <Entropy.h>

void setup() {
  SerialUSB.begin(115200);
  while (!SerialUSB) {
    ; // wait for serial port to connect.
  }
  Entropy.initialize();
}

void loop() {
  uint16_t r = Entropy.random();
  SerialUSB.write(lowByte(r));
  SerialUSB.write(highByte(r));
}

It’s a minor pain to have to reconnect the USB cable to the other port on the Arduino Due after programming, but it’s worth it just to see an 84 MHz µc belting out random bytes 37½% faster than an 800 MHz Raspberry Pi …

Artisanal Hardware Random Number Generator

Artisanal Hardware Random Number Generator

Artisanal Hardware Random Number Generator — scruss
(the Flickr page has popup notes about the circuit.)

Trickles out a few thousand made-with-love organic random numbers per second to the attached Arduino. The circuit is essentially Rob Seward’s True Random Number Generator v1 (after Will Ware, et al) which uses a MAX232 to power two reverse-biased 2N3904s to create avalanche noise. Another 2N3904 amplifies the resulting noise into something an Arduino can sample using AnalogRead(). Many modern processors include hardware RNGs (such as RdRand in recent Intel chipsets) so this circuit is just a toy now.

My interest in random number generators didn’t just arise from yesterday’s post. I’ve had various circuits breadboarded for months gathering dust, so I thought I’d pull out the most successful one and photograph it. Hardware RNGs seem to be a popular hobby electronics obsession, and there are many designs out there in variable states of “working” and/or “documented”. I wanted one that could be powered from the 5V rail of an Arduino, and didn’t use too many expensive components. Rob’s RNG Version 2 circuit and code is the basis, but I replaced the 12V external supply with the MAX232 circuit he used in version 1.

Perhaps the reason that there are so many RNG projects out there in various states of abandonment is that making a good, reliable hardware RNG is hard. Just a few of the things you have to think about are:

  • Analogue sources of noise can fade over time; power supplies droop as capacitors age, contacts can corrode, … How do you deal with this fade? If the output becomes so small, can you rely on those few bits from your A→D converter to be useful noise?
  • Could someone try to attack your RNG so they can influence the results of your secure transactions? How would you detect it? How would you signal to the data user that something is amiss securely, such that an attacker couldn’t fake distress behaviour?
  • What if the generator just stops? How do you flag that in a trusted “no really i mean it and it’s really me saying this not some attacker honest no” way? There may still be a tiny bit of noise that your circuit picks up; are you sure it’s your kind of noise, or some attacker trying to inject noise into your system? Remember, testing for real noise is exceptionally hard, and you can’t guarantee that a hardware RNG that worked today will work properly tomorrow.

(I’d like to thank Peter Todd for providing most of those issues over a pint and a chat during from a keysigning event. Peter saved me from spending too many hours working on this by hinting that — just maybe — I didn’t actually know what I was doing…)

If you want to read more on how to build a proper hardware RNG, the article “Understanding Intel’s Ivy Bridge Random Number Generator” and its references make a good (if very technical in places) introduction. I’m nowhere near paranoid enough to experiment further with RNG design, although I do have all the components to build an LM393-based XR232USB…

“Well, that was unexpected…”: The Raspberry Pi’s Hardware Random Number Generator

Hey! This is a bit old! Things may have changed and I haven’t necessarily fixed them.

Most computers can’t create true random numbers. They use a formula which makes a very long stream of pseudo-random numbers, but real randomness comes from thermal noise in analogue components. The Raspberry Pi has such a circuit in its SoC, as it helps making the seed data for secure transactions. It was only recently that a driver for this circuit was supplied. To enable it (on Raspbian): I think the module is enabled by default now for the different versions of the SoC.

  1. Make sure your system is up to date with
    sudo apt-get update
    sudo apt -y upgrade
  2. Install the module:
    sudo modprobe bcm2708-rng
  3. To make sure it’s always loaded, add the following line to /etc/modules (editing as root):
    bcm2708-rng
  4. For some RNG-related stuff, install rng-tools:
    sudo apt-get install rng-tools

The /dev/hwrng device should now be available, but can only be read by the root user.

Nico pointed out that you also need to:

  1. Edit /etc/default/rng-tools, and remove the # at the start of the line
    HRNGDEVICE=/dev/hwrng
  2. Restart rng-tools with
    sudo service rng-tools restart

What random looks like

random20130606210642random20130606210630

Random data look pretty dull. Here are random RGB values made with:

sudo cat /dev/hwrng  | rawtoppm -rgb 256 256 | pnmtopng > random$(date +%Y%m%d%H%M%S).png

(you’ll need to install the netpbm toolkit to do this.)

What random sounds like

Two short WAV samples of, well, noise:

Yup, sounds like static. It was made with the rndsound.sh script. You’ll need to install sox to run it.

This is not random

If it sounds like static, and even if it sometimes looks like static, it may not actually be true random noise. An infamous case of a pseudo random number generator being not very random at all was RANDU, which at first glance appeared to produce nearly random results, but close study showed it to be very predictable.

I wrote (what I think to be) a C implementation of RANDU: randu.c. While it produces appropriately random-sounding audio data (randu17.wav), if you output it as an image:

randu17_rgbThose stripes are a giveaway; there should be no order in the output. (Then again, I have no idea if I’ve implemented RANDU correctly.) Testing random data is hard, then — you really need a barrage of tests, and even some of them might fail even for truly random output. Thankfully, when you installed rngtools, it included rngtest, a simple checker for random data:

sudo cat /dev/hwrng | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 1000
rngtest: FIPS 140-2 failures: 0
rngtest: FIPS 140-2(2001-10-10) Monobit: 0
rngtest: FIPS 140-2(2001-10-10) Poker: 0
rngtest: FIPS 140-2(2001-10-10) Runs: 0
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=67.969; avg=921.967; max=1953125.000)Kibits/s
rngtest: FIPS tests speed: (min=842.881; avg=3208.336; max=6407.890)Kibits/s
rngtest: Program run time: 27658884 microseconds

We were lucky that none of the tests failed for that run; sometimes there are a few failures. RANDU, on the other hand fares very badly:

./randu 17  | rngtest -c 1000
rngtest 2-unofficial-mt.14
Copyright (c) 2004 by Henrique de Moraes Holschuh
This is free software; see the source for copying conditions.  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

rngtest: starting FIPS tests…
rngtest: bits received from input: 20000032
rngtest: FIPS 140-2 successes: 0
rngtest: FIPS 140-2 failures: 1000
rngtest: FIPS 140-2(2001-10-10) Monobit: 730
rngtest: FIPS 140-2(2001-10-10) Poker: 1000
rngtest: FIPS 140-2(2001-10-10) Runs: 289
rngtest: FIPS 140-2(2001-10-10) Long run: 0
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=45.630; avg=14255.221; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=23.694; avg=154.238; max=176.606)Mibits/s
rngtest: Program run time: 141071 microseconds

See? Lots of failures there. It’s hardly random at all. If you really want to get out testing randomness, there are the dieharder tests. They takes ages to run, though.

(Note: newish Intel machines also have a real hardware RNG in the shape of Rdrand.)