[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.
Aha indeed. Start pumping those bytes into box.com, Google drive, dropbox etc.. and watch them suffer!
All those services rely on data deduplication and compression to fit all the information in their data centers. Otherwise, it would be impossible for them to store everybody’s information that easily.
An incompressible file can be useful for performing some tests, like measuring data transfer rates. Since some services (like HTTP/S through any sort of acceleration device) compress on the fly, and that can muck with your results, passing a file that can’t be squished can be handy.
You might also use an incompressible file to deter high-speed piracy of large media (for example, a CD/DVD-based video game). As I recall, I read about some games using that technique awhile back (until someone found that file, realized it was crap and replaced it with a file filled with zeroes).
Now how about a way to use a natural chaotic input as the random number seed, like SGI did with their Lavarand project?
It used a low resolution webcam aimed at six lava lamps and periodically used images from the camera as seed data which was run through two random number generators.
I participated in an IRC chat with one of the system’s inventors who said they’d put one together for a “major financial institution” to protect important data stored on a CD-ROM disc. Being extra paranoid, the client insisted on having the CD-ROM drive inside a microwave oven, connected to the alarm system. If someone broke in (past all the other security systems) the microwave would fry the disc.
The client also insisted on having exactingly specific maintenance procedure written up, including step by step how to change the light bulbs in the lava lamps.
Pointing the camera at any chaotic natural scenery would work as well but SGI used the lava lamps because they were cool.
Galane, done. Most PRNGs these days come with some way to seed the PRNG already, so just seed a PRNG with some HW RNG data.
This is actually a recommended procedure with some HW RNGs; they often have some form of strong bias, hence the need for mixing/conditioning/… hardware. But, an easy way to handle conditioning and be guaranteed good statistical output is to use a PRNG as the conditioning part.
This one has strong bias towards a particular frequency in the raw data, but the conditioning stuff takes care of that to an extent.
Or you could take a webcam, put a cover on the lens, and turn up the gain until you see random noise appear.
Anyone wanna tell us how it’s done? Where he’s getting the randomness from? Why it takes a whole FPGA? Or if not the whole of an FPGA, you know what I mean… Aren’t you just supposed to measure shot noise from a resistor or diode or something?
https://github.com/zdavkeos/whirlyfly#about
“Whirlygig uses a series of unlocked inverter chains to generate truly random bits.”
Also, peeking at Wikipedia: http://en.wikipedia.org/wiki/Ring_oscillator#Jitter and http://en.wikipedia.org/wiki/Ring_oscillator#Applications
Looks like this is a pretty common way to build hardware RNGs. A series of inverters are used to build an oscillator which has some unpredictable jitter based on various environmental and fabrication variations.
As for why you would do this instead of using a resistor or diode, my guess is that it’s more difficult to fabricate resistors into silicon, and if you’re already using an FPGA, you have programmable access to unclocked inverters, but not to the individual diode junctions.