This is a (relatively) short post that I’ve been meaning to write for a while. A recent Ars Technica story (and the resulting HN discussion) prompted me to finally sit down and write this.
I’ve been aware of software defined radios for quite some time. The entire concept seemed very cool (especially because I’ve always been interested in radio). Unfortunately they were also somewhat expensive.
The RTL-SDR series of dongles changed all of that. For less than $20 you could enter the exciting world of software defined radio - using GNURadio and other programs to apply open source and programming to radio. It’s all very cool stuff but I struggled to find a practical application. Then I found rtl_entropy.
This time last year you would never hear words like “encryption”, “cryptography”, and “entropy” on news broadcasts like CNN. Then Edward Snowden starting revealing the reach of the National Security Agency’s various programs and since then we’ve been bombarded with a new revelation on an almost weekly basis.
Ideas that would have seemed crazy and paranoid just a year ago now seem remarkably likely. Backdoors in closed source programs. Submarines tapping undersea cables. Data collection on a massive scale. Tampering of hardware by various state agencies (the NSA and counterparts in China, for example).
Just today Ars Technica posted a story about the FreeBSD developers no longer explicitly trusting hardware RNG modules from Intel (RDRAND) and Via (padlock). Note that I say explicitly because unlike Linux (which has always mixed all available sources of entropy) FreeBSD uses one hardware source explicitly. With all of the questions surrounding the (potential) involvement of the NSA in these designs this probably wasn’t the best idea. In FreeBSD 10 that’s going to change.
However, RDRAND and padlock were always very good (supposedly) sources for LOTS of entropy. With their use being called into question, what are we to do for applications that require large amounts of available system entropy but are (hopefully) free from tampering and yet readily available?
That’s where rtl_entropy comes in. I first found this project back in August. rtl_entropy uses atmospheric radio noise from an RTL-SDR dongle to generate entropy. Because the RTL-SDR hardware is able to sample about 3.2 MS/S this translates into about 3.4Mbits/s of entropy. That’s a lot, especially when you consider what some high price (yet still proprietary and unknown) hardware entropy sources cost.
rtl_entropy is open source and available for inspection. It runs with cheap, mass-produced radio dongles which are (presumably) difficult to “cook” for this purpose. As the author states “it samples atmospheric noise, does Von-Neumann debiasing, runs it through the FIPS 140-2 tests, optionally (-e) does Kaminsky debiasing if it passes the FIPS tests, then writes to the output. It can be run as a daemon which by default writes to a FIFO, which can be read by rngd to add entropy to the system pool”. All of this for less than $20.
When compared to hardware random number generator devices from the Wikipedia table we can see just how revolutionary this is. With proprietary hardware (and in some cases software), which is still unavailable for inspection, the next cheapest source of high quality entropy is $235 per Mbit/s. With a $15 RTL-SDR dongle rtl_entropy is about $6 per Mbit/s and the entire software stack is open source. As said before, it’s also ready to use by just about any Linux system via rngd.
Also, because Linux always mixes the sources of available entropy rtl_entropy can be safely combined with various other mechanisms available - RDRAND, haveged, aed, etc.
I’m proud my company and I have been able to sponsor Paul and his work on rtl_entropy. This is what open source is all about!
