Randomness with OneRNG and NeuG

In recent months, we have discussed two hardware true random-number generators (TRNGs) that are open-hardware projects running free software: the OneRNG (which we looked at in January) and the NeuG FST-01, which we looked at in June. However, both of those articles covered conference presentations that explored the design and usage of the TRNGs in question, rather than exploring real-world usage. I recently received one of each hardware device, and decided to put them to the test.

OneRNG

The OneRNG was launched in a Kickstarter campaign, which I backed at the level required to get a production-run device (higher pledge levels were available that rewarded the backer with an early, hand-assembled model instead). The production-run devices began shipping in early June, and it looks as though the project has sufficient orders that it will produce more batches as time goes on.

The device itself is a small circuit board with a single LED, a metal heat sink/shield covering some of the larger components, and a USB port. Both an external USB version and one with an internal USB connector (e.g., for server motherboards) were available; I tested the external version. The documentation explains how to set up the device as well as how to verify that it has not been tampered with. That process includes a physical inspection, but there is software support as well.

From the factory, the production hardware runs firmware version 3.0 (the pre-release models sent to early adopters may be on older firmware). The client-side software available for download on the site (architecture-independent RPMs and Debian packages are provided, as is a tar archive) includes a set of scripts. One is a shell script to make the device feed entropy to the rngd daemon, while the other is a Python script that computes a checksum of the firmware on the OneRNG device, to compare it to a known, project-signed checksum. That allows the user to verify that the code running on the device has not been modified. Users concerned that the Python script itself has been compromised can verify its checksum on the OneRNG documentation page—although to be truly paranoid, one should check the copy of the page stored in GitHub, since—unlike the main site—it can be retrieved over HTTPS.

A few prerequisites are required to run the OneRNG software: python-gnupg, at, and rng-tools. The RPMs and Debian packages install a configuration file at /etc/onerng.conf and a udev rule to recognize the device when plugged in. Once plugged in, rngd begins reading random bits from the device into the kernel entropy pool. The LED on the device lights up bright orange when the kernel entropy pool is full, and dims to a lower level when the pool is being depleted. Running:

    cat /proc/sys/kernel/random/entropy_avail

reported 1338 without the OneRNG plugged in; immediately after plugging in the device, it reported 3354. Obviously, those two numbers are arbitrary, single samples; what is important is that the OneRNG refills the entropy pool considerably faster than the usual entropy-collection methods. One can empty the pool by piping /dev/random to /dev/null, and the OneRNG's LED will dim. About two seconds after canceling the pipe operation, and the pool will be full again. Without the OneRNG, the pool takes about 5 minutes to refill on my test system.

By default, the device is configured to sample noise from its onboard avalanche diode circuit, but the OneRNG has another source available. The metal "shield" serves not only to dissipate heat—and the OneRNG runs hot enough to be unpleasant to touch, though the project claims this is to be expected—but also to block external radio frequency interference. The board's second available entropy source is a de-tuned radio receiver that, when shielded, should only hear random noise. Changing the settings in /etc/onerng.conf allows the user to selectively enable or disable the avalanche diode and the RF noise source.

On the whole, the OneRNG is quite simple to use: it is as close to plug-and-play as one can reasonably get, and the configuration options are easily navigated. Assuming the heat produced by the device is acceptable, it seems like a good investment for anyone in need of a TRNG.

NeuG

The NeuG project produces a software stack that can run on a range of similar boards; the flagship offering is the FST-01, which can be purchased from the Free Software Foundation (FSF) store, among other places. Like the OneRNG, the NeuG FST-01 runs as a USB Communication Device Class / Abstract Control Model (CDC/ACM) device, presenting a serial interface on /dev/ttyACMN when running. But the FST-01 initially presents itself as a small flash drive when plugged in. On the drive are instructions and an empty folder named "DROPHERE." The user can switch the FST-01 into ACM mode for the current session by unmounting the flash drive. To make the device start up in ACM mode every time, one must place a file into the DROPHERE folder first.

While random bytes can be read directly from the ACM device, configuring it as a source for the kernel entropy pool requires following some additional steps, which are described in the documentation. They are essentially the same as are implemented in the OneRNG software package: creating a udev rule to recognize the hardware and a systemd configuration file to initiate usage with rngd.

The NeuG documentation presents several configuration options, though, some of which might conflict with the settings needed by OneRNG. For example, the first configuration option listed recommends hard-coding HRNGDEVICE=/dev/ttyACM0 in the rng-tools configuration file, followed by a snippet of code built around the NeuG's command-line options. This will not work if the OneRNG (or another device) is /dev/ttyACM0. The second option described uses udev rules to launch rngd. I eventually got this method to work, though not without removing the ModemManager package—a hangup not encountered with the OneRNG, despite the fact that both of TRNGs appear as ACM devices.

The performance of the NeuG is comparable, which is to say that it refills the kernel entropy pool in the blink of an eye. Since the kernel has a hard-coded 4096-bit size limit to its entropy pool, it can be hard to gauge how practically useful either device's speed truly is. Perhaps it would be most interesting to see if one could envision a workflow that would drain the pool on a regular basis and still reflect some sort of real-world use case. The canonical example brought up in RNG discussions is large-scale cloud deployments, where one physical server needs to support hundreds of virtual machines (or containers) but does not have sufficient disk-timing or mouse-movement entropy to keep up with demand.

On the other hand, the NeuG is also considerably smaller, physically, than the OneRNG, and it does not generate heat; both factors could be important to any given user depending on the circumstances (imagine, say, a fanless enclosure, and the OneRNG's heat production may be more problematic, as might the associated power drain). If aesthetic issues are important for your use case, note that the NeuG features a blue LED rather than the OneRNG's orange.

In the long run, the NeuG looks to be about as reliable at supplying entropy as the OneRNG. The OneRNG team has certainly provided easier-to-use packages that take trial and error out of the setup and configuration process. The NeuG project would benefit from such improvements, as it would benefit from providing users with a forum or mailing list on which to meet and ask questions (a nicety OneRNG also provides).

Analysis

Apart from refilling the entropy pool in a hurry, the main selling point of a TRNG is that it is expected to produce higher-quality output than can be achieved with software-only techniques. To that end, I captured random data from the OneRNG, the NeuG, the default system entropy sources, and from haveged.

It quickly became apparent that detailed analysis of the RNG output was not a simple task. The simplest test suite is ENT, which performs six rather basic tests on each input file, such as computing the mean, shannon entropy, serial correlation coefficient, and Chi-squared distribution of the bits. All four of the options I tested resulted in roughly the same results for these tests: between 7.999 and 7.9999 bits of entropy per byte, serial correlations under .003 (with zero being perfect), and so on. Haveged did score somewhat poorly on one Chi-squared test, but a second run on a different sample gave it a score much like the TRNGs.

The other easy-to-try testing tool is dieharder, which runs a battery of tests devised by the US National Institute for Standards and Technology (NIST) and others. Here, too, the four RNG methods tested produced roughly similar results.

The wrinkle is that many mathematicians working in the RNG field seem to hold ENT and dieharder in rather low regard, so citing them as evidence of entropy quality is likely to be met with dismissiveness. In our NeuG coverage from LinuxCon Japan, we noted that NeuG creator Yutaka Niibe recommended the TestU01 and PractRand packages to verify output.

Neither of those tools is packaged for Debian, so I set out to build and run them locally, with somewhat disappointing results. PractRand relies on G++'s experimental C++11 support for some of its core functionality, and even when I got it to build, it had a segmentation fault on every run. TestU01 comes with a 219-page user's guide [PDF] and I eventually just ran out of time attempting to determine how to use it within a reasonable timeframe. Some of TestU01's utilities take several hours to run, even on a small sample, and small samples are not recommended.

Perhaps the more fundamental concern, though, is that both of these rigorous test suites are academic in nature. They are geared toward researchers implementing new pseudo-random number generator algorithms, and a lot of the code in the packages are implementations of the projects' own RNG routines (for comparison testing). In some cases, they are not even able to execute tests against file input. The choices made may be valid for the intended audience, but they are not too helpful for TRNG testing. It would be nice to have a simpler way to use these more rigorous test suites, since the simple statistical tests are reputed to be easy to fool.

On the other hand, this level of detail is not likely to matter to many potential buyers. It is clear enough that the OneRNG and NeuG projects conduct their own statistical analysis, and the results seem to show acceptable randomness for the needs of everyday Linux users. The practical matter, as always, is that having a TRNG in one's system can prevent the situation where a process hangs waiting for the kernel entropy pool to refill. It helps that TRNGs are theoretically more resistant to attack than software generators, so for those in need of additional entropy, it is worth considering either the OneRNG or the NeuG—or, for that matter, both.