# Differences between methods of hardware random number generators

I'm reading about various hardware random number generators which - among others - implement the following approaches:

What are the practical pros and cons of these approaches? Is any of these methods "better", more reliable, or more resistant to physical attacks than the others?

• "Modular entropy multiplication" is not a generic type of noise source, as every other bullet point is. Its noise source is thermal noise, one you already listed. (Johnson–Nyquist) A lot of that Github project's readme seems like technobabble. (Not legitimate jargon.) – Future Security Jul 6 '18 at 16:18

Treating each in turn without too much electronics stuff:-

Analog-to-digital converter noise

Better known as quantization noise, is very simple as you can just leave an ADC input floating and the noise appears as a kinda rounding error. So that's a pro, but it is also difficult to measure correctly as other external noise sources can greatly influence it. This means that an entropy rate is difficult to assess that's due solely to quantization. You might be picking up old Fred next door using his arc welder.

No one really uses it as generation method in a standalone RNG device.

Johnson–Nyquist noise

Better known as thermal noise is again very simple and the most common form of entropy. It's the majority of the hiss from an un tuned radio or the bulk of the static on an analogue TV. It's disadvantage is that it's very low level so requires large amplification to get useful entropy. This in turn makes the amplification susceptible to non random factors such as external interference.

The most notorious example of this entropy source is Intel's Ivy Bridge design. Linus Torvalds half believes in it, but I wouldn't trust it if you can't see it for yourself and you can't prove that it even exists.

Reverse biased semiconductor junction

Traditionally this is the most common DIY RNG technique, and a lot of the cheapo USB key type RNGs feature it. The pro is that it can generate a large entropy signal, but is inherently unstable over a monthly time period. Transistors are not designed to run backwards, so the entropy rate slowly degenerates.

Avalanche diode with optional atmospheric noise

Some confusion here. They don't really make specific avalanche diodes any more. The avalanche effect is particular to only certain Zener diodes. Atmospheric noise doesn't really figure in this. Your wiki link's reference to RF noise is simply an indication of the frequency of the noise such a diode makes.

The major advantage here is a relatively huge entropy signal that remains stable over time. You can get 1000s of bits/s of good entropy from such. This and web cam sensors are my favourite methods of entropy generation. The disadvantage is that the RNG has to be bulkier to accommodate higher voltage circuitry.

Modular entropy multiplication

More confusion. I'll try keep this appropriate for crypto rather than the electronics forum. Your link suggesting that MEM is "much easier to get right than other TRNGs" seems difficult to comprehend. Both the Infinite Noise TRNG and Z1FFER TRNG claim to follow Peter Allan's REDOUBLER design, yet they differ substantially. One even includes a so called avalanche diode, yet Allan's original design doesn't have one.

However, keeping an open mind (not a closed mind), I can accept that Allan's may have merit. Unless the whole thing's a scam, the results speak for themselves. It reminds me of a chaotic circuit, perhaps akin to a ring /phase shift oscillator but not quite. Chau circuits are another possible analogy. I have to admit though I've never heard of MEM and phase shift constructs are uncommon in standalone TRNGs. A stable chaotic circuit is something of an oxymoron.

1.5Mbps of 98.8% pure entropy is not to be sniffed at, although I'm uneasy. That's an amazing purity exceeding that from some optical beam splitters or even the fancier ones. I wonder how it was measured considering that non IID data's entropy is notoriously difficult to measure, and there is scant discussion of statistics, entropy characterisation or mathematics generally on the site. The golden rule of a TRNG (entropy out < entropy in) requires careful estimation of the raw rate. A histogram of $(u0i - u1i)$ would have been prudent, as would a correlogram. The absence of a true oscilloscope trace also sets off my spider sense. Needs further validation methinks.

By physical attack I take it to mean using a hammer. All commercial RNGs are susceptible to this and do not really make special provision against it other than the usual component encapsulation /shielding. Hardware security modules have more inbuilt protection, but those are not simple RNGs. Electronic attack can affect them but only as a form of service denial. The cryptographic avalanche effect of the entropy extraction process makes it impossible to force a hardware device to produce specific output.

The final pro of the avalanche effect method is that it's fairly simple to make a reliable DIY RNG if that's your bent. These are very amenable for operation in parallel with very little additional circuitry. You can cheaply increase the entropy rate eight fold by having eight or sixteen diodes. 5 megabit/s of raw entropy is easily possible. This is also the preferred choice of Bundesamt für Sicherheit in der Informationstechnik (BSI) AIS 20.

• No one really uses it. Actually, it is used by millions (tens of million?) of devices around the world. Several popular Atheros wireless cards come with a driver in Linux which use its ADC as a random number generator source by default. I'm sure there are others too. – forest Jun 26 '18 at 22:31
• @forest That's not really a TRNG first and foremost though, it's a network card. Even an Arduino has such for seeding it's random statement but that's a poor way of doing it. I'll edit. What's the entropy rate of your card? – Paul Uszak Jun 26 '18 at 22:44
• Huh? I think you are misunderstanding the purpose of randomness testing. Whitened output is always going to pass the tests, even if you feed it bad randomness. You should only ever run these tests on the raw output. Not doing so is a fatal error (and what haveged infamously got wrong). It's well known that running the tests on post-whitened randomness defeats the purpose of such tests. This is one reason why Intel's RDRAND is so sketchy. You don't get access to the raw output to measure it. And actually, the dieharder paper itself mentions it is only for use on raw output... – forest Jun 26 '18 at 23:45
• @forest That document isn't really appropriate to this particular question as it doesn't deal with hardware at all. It's all theory. And no one uses it for entropy assessment either. Their implementation is suspect, so we have to doubt the theories too until they're proved empirically. – Paul Uszak Jun 27 '18 at 10:03
• Interesting discussion. I published the question here to get a proper answer: crypto.stackexchange.com/questions/60463/… – jans Jul 2 '18 at 18:17

The Electrical Engineering SE would be a good resource for questions about specific sources of noise. Which method is best is not a a question for which you will find a good answer to. The "quality" of any method depends on which models of electronic components are used. They have different properties that don't make direct comparison easy:

• Power use: Two sources that produce the same amount of "randomness" per second can have drastically different power requirements.
• Price: How much you have to pay matters. Just because something is more expensive doesn't mean it's better at producing randomness. Even if it was it might not make a difference because things are either sufficiently unpredictable or they are not. Cheap components may work well enough. They may work better. They may be worse.
• Rate: How much randomness can you extract from a single? How much per unit of time and how much per unit of power?
• Unpredictability and Leaks: How much noise is known only to the HWRNG versus how much noise can be read by an outsider. (This is the reason you should not rely on atmospheric noise. Yes it is unpredictable, but two people in the same area on this planet will read somewhat similar noise signals.) What about side channel risks and protection? It doesn't do much good extracting noise from a random process if the HWRNG leaks information based on how much power it draws while generating random numbers. Or if you can literally hear part of the noise signal coming form capacitors.
• Life-time and Stability - The behavior of some components change as they age. Some components may wear out the longer you use them. Some may change even without use. If you calibrate a system for producing noise as it is now, you might end up with a more predictable HWRNG sometime in the future.
• Production - Variations between components of the same type means you might not be able to buy commodity components and use them interchangeably. Even if two components came from the same manufacturer. One should test the components and design a HWRNG that isn't too sensitive to variation.
• Tamper-ability - Physical access is devastating but remote attacks can be too. I'm sorry I don't have links, but one method used in remote attacks is, I think, referred to as "illuminating" a device. It's when you "shine" an electromagnetic signal at a device. It can turn into a fault injection attack (making unpredictable behavior predictable) or a side channel attack (causing secret information to be bounced back.)

From a cryptography perspective the source of "randomness" or "unpredictability" does not really matter. We just need a signal that has entropy (a term for how much unpredictability there is in a signal) and a means of estimating how much entropy a system has. No one should be using raw readings from signals as their binary output.

Real HWRNGs typically output "whitened" noise. The raw signals from a noise-producing system do not necessarily (almost certainly don't) look like samples from a uniform statistical distribution. The input signals need to be processed to extract randomness. They're not 100% random so the bandwidth of the signal coming out will be less than the bandwidth going in. That's where the entropy estimate comes in. You do not want to emit 100 bits of random output if your un-whitened noise signal is only as unpredictable as 10 coin flips. (We say the input has only 10 bits of entropy in this case.)

Informally speaking the randomness is typically extracted by something like a cryptographic hash function. The signal going in is digitized and fed to the hash function. When enough data is processed, say an estimated 256 bits worth of entropy, the hash function is evaluated and the result is used as a seed/key for a deterministic random number generator. As long as the entropy estimator does not over-estimate the amount of entropy then this hybrid-system is a sound construction.

From this crypto-perspective what matters is efficiency (power use, bits per second, unpredictability) and security (unpredictability, stability, lack of side channels, difficulty with tampering). How we can get that out of hardware is a different type of problem in the realm of physics and electrical engineering.

• How do you estimate the entropy? – Paul Uszak Jun 26 '18 at 22:48

As Future Security mentioned, true randomness is different from randomness in the cryptographic context. I have found that software entropy sources are rather easy to compromise if you have physical access to a device. Hardware is harder, but not impossible. One of the things that can happen is that if I am using a truly random source to feed a block cipher is that I can get the same number twice. If I use a seed and AES to make a CPRNG, I have to iterate through the entire space before I wrap around.

I wrote a paper that used random noise that based on first-principle physical effects so that you could guarantee that the source of noise was provenly random. I was trying to eliminate the nuclear sources that are used in high performance random number generators. No one liked in the cryptography world; however, I suspect that it was a source for writing this SBIR topic. The topic is closed, but the Q&A is a good start if you really want to dig into this topic.

In a short and regrettable explanation of device physics: for all noise sources that you mention except the atmospheric noise, the function that creates noise is based on the bias conditions of the device. For instance, what is usually described as Johnson Noise is actually shot noise in a semiconductor context if you do a derivation from first principles. Due to forward and reverse current in the channel, it is a function of two independently random events based on Poisson transport. You then need to add the tunneling in the high-field region at the drain edge and the hot-electron losses due to channel inversion, which are also based on a Poisson distribution. Based on the device operating conditions of voltage and temperature, you can then have a physical model for noise. You will find that most of the randomness will be a function of temperature, but this not exclusively true. For example if you ignore measurement realities and just look at the math, the quantum effect of tunneling will have a noise contribution long after the silicon has stopped conduction due to lattice transport freeze out.

If I were to pick one architecture, I would start with ring oscillators as you can push through the math to prove that the jitter is random, and there's a body of work on the topic that already exists on how to analyze them even if there are first-order approximations. There will be discrepancies because the noise will be worse than the thermal noise (Johnson noise) for the reasons I outline above.

• Er, you realise that shot noise is absolutely not Johnson–Nyquist noise? They even go in different directions, and one of them doesn't have to involve electrons at all. Bias conditions of the device??? – Paul Uszak Jun 26 '18 at 21:14
• @PaulUszak Yes I do. And Johnson-Nyquist noise is absolutely not the driving term in channel noise in semiconductors. The bias conditions are related to the transport characteristics. You can dig into the references that are listed here: electronics.stackexchange.com/questions/240747/… – b degnan Jun 26 '18 at 22:02
• @PaulUszak I see where you got that impression. I edited the response to clarify disconnect. Thanks for carefully reading the answer. – b degnan Jun 26 '18 at 22:04
• I'd like to see your noise paper. I build TRNGs as a sad hobby. – Paul Uszak Jun 26 '18 at 22:32
• What high performance nuclear RNGs? I'm not aware of any other than Hotbits and that's dead dead slow. – Paul Uszak Jun 26 '18 at 22:33