Generating random numbers from white noise

Even though rand() may be a good enough random number generator for making a video game, the patterns of random bits it spits out may not be sufficient for applications requiring truly random data. [Giorgio] built his own random number generator, and after many statistical tests it ended up being random enough for a few very complex calculations.

Previously, we saw [Giorgio] generate random numbers with a Chua circuit, but for all the complexity of building an electronic strange attractor there’s actually a much simpler source of random data: a white noise generator.

[Giorgio]‘s random number generator for this project is just a pair of resistors, with an op-amp buffer, amplifier, and current switch to turn analog data into a digital output of random 1s and 0s. [Giorgio] sampled this data by plugging the digital out into one of the GPIO pins of a Raspberry Pi and recording the data with s small script.

To verify his sequence of bits was actually random, [Giorgio] performed a few tests on the data, some more reliable in determining randomness than others.

Because every project needs a few awesome visualizations, [Giorgio] plotted each sequence of bits as either a black or white pixel in a bitmap. The resulting image certainly looks like television static, so there are no obvious problems with the data.

[Giorgio] also performed an interesting Monte Carlo simulation with his megabytes of random data: By plotting points on a plane (with a range from 0,0 to 1,1), [Giorgio] can approximate the value of π by testing if a point is inside a circle with a radius of 1. The best approximation of pi using 10,000 points of random data came out to be 3.1436

Of course [Giorgio] put his random data through a few proper statistical tests such as rngtest and dieharder, passing all the tests of randomness with flying colors. An interesting build that shows a small glimpse of how hard generating really random numbers actually is.

Generating truly random sequences

Your brain can’t generate random numbers, and computers can’t either. Most of the ‘random’ numbers we come across in our lives are actually pseudorandom numbers; random enough for their purpose, but ordered enough to throw statistical analyses for a loop. [Giorgio] thought generating random sequences would make for an excellent project, so he whipped up a random sequence generator out of a few Opamps, resistors, and a handful of caps.

[Giorgio] used a Chua Circuit – a circuit that models nonlinear equations – to create a chaotic system. When pairs of points from these systems of equations are plotted on a graph, a fabulous and chaotic ‘double scroll’ pattern (seen above) can be found. After taking oscilloscope probes to different points on his Chua circuit, [Giorgio] watched chaos magically appear on his ‘oscope screen.

The double scroll pattern isn’t exactly random, but since the Z signal of his circuit chaotically varies between positive and negative, the only thing needed to create a random sequence of 1s and 0s is sending the Z signal through a comparator.

After calibrating and sampling his circuit [Giorgio] captured thousands of samples at a rate of 5 samples per second. From a cursory glance, it looks like [Giorgio]‘s circuit is at least as good as flipping a coin, but proper tests for randomness require many more samples.

A very, very cool piece of work that is much, much more elegant than getting random bits from a Geiger counter.

A hardware random number generator for your FPGA

[Zach] sent in a project he’s been working on that brings hardware random number generators to common hardware you might have lying around. It’s called Whirlyfly and it turns an FPGA dev board into a hardware random number capable of outputting random bits over a USB connection at 3 Mbps.

Previously, the whirlygig ran on a custom CPLD that interfaced to a *nix box and provided high quality random numbers via /dev/hw_random. [Zach]‘s efforts takes the core of the whirlygig and ports it to the very popular and inexpensive Papilio One FPGA dev board.

As for what [Zach] can do with his random number generator, it’s extremely easy to write a Monte Carlo experiment to approximate the value of π with a better accuracy than [Ptolemy] was able to muster 1900 years ago. There’s also the aspect of encryption, and – why you would do this we have no idea – making an uncompressable file is also possible.

Intel’s new way of creating randomness from digital orderliness

Random number generation is a frequent topic of discussion in projects that involve encryption and security. Intel has just announced a new feature coming to many of their processors that affect random number generation.

The random number generator, which they call Bull Mountain, marks a departure from Intel’s traditional method of generating random number seeds from analog hardware. Bull Mountain relies on all-digital hardware, pitting two inverters against each other and letting thermal noise tip the hand in one direction or the other. The system is monitored at several steps along the way, tuning the hardware to ensure that the random digits are not falling more frequently in one direction or the other. Pairs of 256-bit sequences are then run through a mathematical process to further offset the chance of predictability, before they are then used as a pseudorandom number seed. Why go though all of this? Transitioning to an all-digital process makes it easier and cheaper to reduce the size of microchips.

A new instruction has been added to access this hardware module: RdRand. If it works as promised, this should remove the need for elaborate external hardware as a random number source.

[via Reddit]

Electronic dice, overkill and simplified

[littlebird] posted a tutorial on making electronic dice.  He’s using an ATmega328 for the numbers work, and a mercury switch to activate it all. A nice blue enclosure to match the blue LEDs he’s using for the number display wraps it up nicely. Of course, someone had to mention that this was an amazing amount of over kill and it could just be done with a 555 timer like they used to do “back in the day”. [littlebird] responded with another tutorial to prove that he hadn’t forgotten how to work with the basics. He goes on to point out, now that we see both in action, that he can expand his microcontroller based one quickly with a few lines of code, where every new feature added to the 555 timer version would require additional components.

You can catch videos of both after the break.

[Read more...]

Hardware based randomness for Linux

True randomness can be hard to come by in the digital world. [Andy Green] is making it easier to get true entropy by using this random USB dongle. The Whirlygig uses a CPDL to gather data from a set of of oscillators. The oscillators have a constantly fluctuating frequency due to temperature changes; if they run faster they generate more heat which in turn slows them down. This, along with the variable latency associated with polling a USB device, gives great depth of randomness. The device is detected and mounted under ‘/dev/hw_random’ and can then be fed into ‘/dev/random’ using the rng-tools package. [Andy's] done a lot of testing, both on the hardware, and on the quality of randomness. We didn’t see an option to order this but he’s got hardware and firmware repositories so that you can throw one together yourself.

[Thanks Zunk]

A random USB… hourglass

[Peter] thought of a creative, way to generate random entropy for under $100.

The USB Hourglass combines a sand timer with a rotating mechanism and an optical beam through the center of the timer to observe the falling sand. The amount of light reaching a detector is digitized at frequent intervals and processed by a microcontroller to determine when to rotate the hourglass. The digitized light levels are also sent by USB to a host PC where they can be used as a source of random entropy. Power is supplied over the USB cable.

With the USB Hourglass, the user can look at the sand falling through the center of the hourglass and monitor the randomness in the USB output data. And one can read the code line-by-line, compile it, and upload it to the microcontroller using only open-source and widely supported tools.