The Infinite Noise TRNG is an affordable and secure true random number generator (TRNG). It’s based on a modular entropy multiplier technique that continuously loops over previous random output, gathering randomness from the noise of the hardware components along the way, to generate the next random output. This way it produces a constant, measurable level of entropy which is then whitened to produce true random numbers. The openness of the implementation makes it easy to inspect and verify, as all security hardware should be!

Who needs random numbers?

Almost any cryptographic operation relies on random numbers - and there are many different approaches to collect this entropy. For Linux systems, this is mostly done with user input and other hardware timing’s "randomness". This approach is very slow and its performance mainly depends on the computer’s activity.

For situations where the Linux Random Pool /dev/random depletes and finally blocks, hardware random number generators like the Infinite Noise TRNG provide a secure, high performance way to feed entropy into your computer.

• When you operate many virtual machines, lack of entropy can be a serious problem as all VMs share the host's entropy source. The Infinite Noise will provide lots of random numbers to the host system.
• Large web-servers doing SSL encryption can be sped up by using hardware random number generators, while making communications more secure.
• If you operate Linux-based WiFi access points (whether using a PC, laptop, or custom hardware), they can

benefit from plentiful available entropy, as WPA2 authentication relies on it.

The next big thing about random number generators is security. When you take a close look at the last 20 years of information technology, there have been dozens of security incidents with flaws in random number generators.

• 1994: First Netscape *SSL* implementations using a predictable seed.
• 2007: Reverse engineering showed that the *Windows 2000/XP* random number generator had a bug that makes it vulnerable. It's been there for years.
• 2008: Members of the CCC developed an attack overcoming a poor RNG used in MIFARE Crypto-1, which is still used in some *RFID* tags.
• 2008: The random number generator used in *OpenSSL* had a critical bug - possibly affecting the security of all keys generated before 2008.
• 2013: Snowden documents unveiled that the *Dual_EC_DRBG* algorithm has been backdoored by the NSA as part of the Bullrun project. Even worse - it has been recommended by the NIST and actually adopted by manufacturers. At the same time discussions concerning the use of Intel's *RdRand* (previously named: Bull Mountain [1]) in the Linux kernel came up. Doesn't that name sound alarming enough? But even worse - there seem to be ways to let it produce not-so-random numbers. 2
• 2016: The Linux driver for a very common wireless card (ath9k) appears to have a HWRNG which was *not designed* to be used as security device. Its just an ADC - and nobody knows where the data comes from. But one thing is for sure: It's not very random and dominated the Linux entropy pool - which is really bad. Thats why kernel developers decided to disable it by default - but the change did not arrive in all distros yet.

In all these scenarios, the Infinite Noise TRNG helps you to generate random numbers with confidence. A good entropy source can’t help you with everything - but it’s fundamental for all secure applications.

Most of the points in this list of RNG related flaws can be found in the Prominent examples of the Wikipedia article "Random number generator attacks". For the rest, I’ve added some references.

Use Cases

The Infinite Noise TRNG is useful in any situation requiring more entropy than normally available on a typical personal computer. The Infinite Noise TRNG is a good choice if you are:

• Building your own certificate authority
• Administering wireless access points with WPA2
• Running a high-traffic server with SSL enabled
• Having fun with one-time pads
• Replacing /dev/urandom with a more secure and faster /dev/random
• In need of a strong password

How It Works

The hardware derives entropy from thermal noise, like many random number generators. What divides it from other TRNGs is the *modular entropy multiplication* technique.

Thermal noise of resistors is being amplified in an infinite loop to generate data – which is not totally random yet. By using modular entropy multiplication there is some correlation of adjacent bits in the stream.

Health monitoring of important parameters of the raw datastream is implemented in the devices driver, which then uses the SHA-3 hashing function for cryptographic whitening to produce true random numbers.

There is no way to override the signal without being noticed by the driver. Of course it’s possible to influence it a bit, but because we use modular entropy multiplication, this only makes the output slightly more random.

Since by definition there are no patterns in random data, how can you know the data coming from your entropy source was not spoofed? The Infinite Noise TRNG produces this predictable level of entropy, just because it’s the only way to constantly verify the hardware is working properly. And only then will it apply whitening with the SHA3 hashing function.

It may sound daunting, but this is the key feature of this implementation, as the foreseeable (and very high) *level* of entropy enables the driver to monitor proper function of the device. This is an essential feature for any trustworthy random number generator, which most devices unfortunately are missing. Even when you can access the raw output - during operation you often don’t find a way to monitor its operation.

Hardware

The circuit implementinh modular entropy multiplication consists of a pair of a charge capacitors (C8, C9), opamps, comparators COMP1 andCOMP2, solid state switches SW1 and SW2. The driver controls these switches to run two modular entropy multipliers in parallel.

In the first half of a cycle, we need to determine if the current voltage stored in the capacitor is lower than Vref (2.5V). If thats the case, the whole charge is being multiplied by 1.84. When it is higher, we first need to subtract Vref from it – to prevent overshooting.

This logic can be solved very efficiently using the modulo operation.

In the signal loop, additional noise is collected from components along the way, which forms our random output.

Data is being sampled by readings from the two comparator outputs (tied to the capacitors) resulting in a digital stream that is returned via USB.

For more insights into modular entropy multiplication check some of the first project updates:

• Update 2: How MEM works in the real world
• Update 5: Parallel MEM and USB

Software

Health Monitor

Using modular entropy multiplication a very simple but reliable entropy source like thermal noise can be used to produce a raw stream of 300.000 bit/s with a provable level of entropy of 0,86 bit per bit.

raw device output, revealing the pattern of modular entropy multiplication

Any deviations from this expected level of entropy by more than 3% are treated as "NOT OK" and the data will be discarded, so we can always be sure data seeded into the SHA3 function already was pretty random and was coming from the Infinite Noise.

Using the debug mode you can get an insight:

$ infnoise --debug --no-output 
Generated 1048576 bits.  OK to use data.  Estimated entropy per bit: 0.874112, estimated K: 1.832880
num1s:50.538887%, even misfires:0.100875%, odd misfires:0.191457%

Additionally there are some other basic sanity checks, like looking for more than 20 consecutive 1’s or 0’s.

Whitening

Data passing the health monitor will be seeded into an SHA3 hashing function (aka. Keccak-1600 sponge) to create true random numbers for your applications.

The driver allows application of a multiplier, which defines how many bits will be put out of the hashing function for each incoming bit of entropy. This enables you to generate over 50 megabyte/s of pure random numbers without measurable degradation of entropy.

The fact that you can actually apply multipliers in range of 10000+ shows how conservative the driver is with the health monitoring - and how well SHA-3 works.

Signed Packages

Signed packages for several Linux distributions are available as releases and on my website. For Debian based distros there is also an apt repository.

The driver is the most critical part of this, so make sure you verify the signatures against my PGP Key: 71AE 099B 262D C0B4 93E6 EE71 975D C25C 4E73 0A3C/0x975DC25C4E730A3C. This key is used only for code signing, so please don’t use it for contacting me.

The packages come with a unix service and udev rules to start the driver when the device is plugged in. As default application, the random numbers are passed to the linux kernels entropy pool with no multiplier. There is also a config file under /etc/infnoise.conf to permanently enable options like debug mode or multipliers.

You can always stop or disable the service when you want to access the device directly.

As it’s fully open-source, you can also compile it yourself - but you’ll need to install the service files and udev rule manually.

Anyway, you can check the GitHub revision from which the software has been compiled by using --version.

$ infnoise --version
GIT VERSION - 0.2.3
GIT COMMIT  - ad40d816ed1e2e09c6f905ce34a01287885bfa47
GIT DATE    - 2018-03-02T21:59:58+01:00
BUILD DATE  - 2018-03-02T22:07:22+01:00

In the additional package infnoise-tools, you will find some tools to process random data - for generating passwords or to analyze samples.

$ infnoise-passgen random.out 10
password:suyxi{ez{
This password has 50.00 bits of entropy

During the campaign I’ll work on the tools and driver, so make sure to sign up for updates or tell me your ideas for improvements. Please open issues on GitHub for feature requests.

How It Started

The Infinite Noise TRNG is based on a semiconductor design originally developed by Peter Allan in 1999. The design being produced through this campaign was created by Bill Cox (a.k.a., waywardgeek) and implements it with stock-components and a simple USB interface. The design was not modified by me – I just found the GitHub project and wanted to have one. I’m in touch with Bill Cox and he’s happy to support this effort.

Above was only a short summary of the basic operation principle of modular entropy multiplication. If you want to dive into all the details, please check Bill’s GitHub repository or my fork which is usually some commits ahead.

There is also a recent version from Peter Allen called the Redoubler, but I prefer Bills design as it has no firmware at all.

Device without enclosure

Features & Specifications

• Random output: Default 30 KB/second of random data
• Interface: USB2.0
• Supported platforms: (Windows, Linux, and also ARM-support)
• Low Power: 8 mA
• Weight: 10 g
• Dimensions: 15 mm x 50 mm x 8 mm
• No firmware
• Uses off-the-shelf components
• SHA3-“Whitening" and health monitor built into host drivers
• Fully open source (see GitHub repo) and OSHWA-certified (#DE000006)

Comparisons

As mentioned above, the key benefit of this architecture is the continuosly verified level of entropy coming from the hardware number generator which is whitened with SHA-3 in the fully open-source driver, so it will never give out a sequence that is not totally random.

In case of an attacker trying to inject a signal, modular entropy multiplication will profit from the signal, resulting in an unsuccessful attack. Only if the injected signal is extremely strong can an attack partially succeed - as the driver will discard the data, resulting in no output at all.

*needs lot of cpu

Test Reports

Besides the 12-hour test for every single device, there is a testsuite for extended verification of the design of this TRNG. It especially covers the different multipliers for the driver - revealing the full power of this design.

*at full output rate with a Intel i7-4558U CPU @ 2.80GHz.

Each row in this table is based on a testrun generating 250 Megabytes of random data.

For more details, dieharder and rngtest check the links below.

Support & Documentation

• Software releases are available on GitHub and 13-37.org
• My GitHub fork and Bill's repo.
• Entropy testing tools & results
  • results with raw sample data
• Other devices using modular entropy multiplication:
  • Peter Allen's FiReBuG and Redoubler
  • Rob Seward's Z1FFER on openrandom.org
• Pick-and-place machines:
  • VisionBot
  • LitePlacer
• Circuit simulation on everycircuit.com
  • This works only with Google Chrome so I made a recording:

Parts List