I am considering building a hardware RNG myself using cheap parts. Is this a good idea and safe enough?

  • Random sources: amplified Zener noise from one randomly chosen 1N4728A Zener diode and amplified reverse current of a randomly chosen SS9014 transistor.
  • Random stream generating: The two amplified signals are further amplified and biased with one LM324 chip and sent to analog input pins of an Arduino, and the full 10-bit ADC readings are used as the random source.
  • Whitening and stream mixing: how to do this on the Arduino's ATmega328P microcontroller?
  • Uplink: USB Serial.

Anyone have knowledge on how the whitening and stream mixing can be done? And how to evaluate the security of this system?


5 Answers 5


The question fails to mention a functionality that must be part of any secure True RNG (as the question aims to build): supervision.

Supervision is responsible to detect a failure of the "Random sources" or "stream generating" stages (hereafter unconditioned source), and in that event reliably prevent use of what the "Whitening and stream mixing" (hereafter conditioning) outputs.

Experience and reasoning show that effective supervision is of paramount importance for security. Wear, build defects, and deliberate attacks against unconditioned sources result into sources that e.g. output a stream of constant bits, or that repeat in a very short cycle, or that reproduce the noise on the power supply, or can be controlled by an adversary beaming smurfons. Should this happen, the conditioning would produce apparently random output that

  • Stands a fair chance to be the same from one use to another. This is the archetypal disaster leading to private keys being identical on many devices (thus not secret as they should), or otherwise vulnerable (example: smartfacts) even without knowing the details of the RNG
  • Or at least, is vulnerable to attack by one knowing the conditioning, and able to guess the output of the unconditioned source, perhaps by influencing it.

True RNG supervision comprises a test that determines misbehavior of the unconditioned source, and the mechanism (alarm management) acting upon that (like: inactivate everything until the next power cycle). FIPS 140 uses the name "power-up test" and did not mandate further supervision, but the need for supervision actually extends to whenever the RNG might be used: failures and attacks are not bound to strike at power-up!

Supervision also faces a functional requirement of not generating false alarms at a rate that would hamper use of the device. This makes statistical random number generator tests (or at least, their usual parametrization) ill-suited to build supervision. That's because such tests are typically designed to have a quantified and sizable probability of failure for a truly random input, when even 0.01% failure is typically intolerable for mass-produced devices without human operator. Moreover, a practical test must tolerate whatever deviation from uniformly random is expected from its unconditioned source when healthy, and that's heavily dependent of the unconditioned source.

The imperious necessity to tailor supervision to source has been overlooked. Until a change notice in late 2002, FIPS 140 mandated tests (in particular monobit and poker tests) that could not tolerate a small bias or bit cross-correlation. Conformance of a practical device required pre-conditioning of the unconditioned source, in turn making the test less effective, and totally ineffective for a cryptographically strong pre-conditioning. Because FIPS 140 has long been the only public standard specifying test of TRNGs, that mistake is deeply entrenched in literature and standards on secure TRNGs.

A modern, minimal practical approach fro a secure TRNG with supervision as above:

  • A theoretical model of the unconditioned source must be made, including a target min-entropy rate $r$ (a quantity without unit, in range $(0,1)$, specifying how much true entropy there is per bit output).
  • The conditioning must be cryptographically secure under the hypothesis that the unconditioned source meets its target $r$. That could mean feeding a Cryptographically Secure Pseudo Random Number Generator $256/r$ bits before it can output anything.
  • The test in the supervision must catch, with high likelihood, any failure mode of the unconditioned source that can be anticipated to occur according to the model and would bring the unconditioned source below its target $r$; and then prevent use of the output of the conditioning.
  • Yet the availability of the output must match operational requirements.

There may be other requirements, like detecting a failure/attack of the conditioning, recovering from compromise of the conditioning's state.. that complicate the conditioning.

Rough sketch for an appropriate model and conditioning in the question's context: we can model the hardware (when working properly) as a noise source followed by a 10-bit ADC at frequency $2f$ usable to digitize signal from DC to a certain upper frequency commensurate with $f$, with the source noise having an average voltage excursion of say 1/32 full scale at that $f$ (for some loose definition of that). The ADC is 10-bit, with a specified non-linearity of 4 steps.

Thus when things are working properly, each pair of 10-bit samples (drawn over an interval $1/f$, or more due to, say, interrupts) carries at least $10-\log_2(32)-\log_2(4)=3$ bits of entropy ($r=\dfrac3{20}$ when we count bits output by the ADC). This means we are confident that $256/r=2707$ bits or 271 samples have 256 bits of entropy. We take a factor of two for leeway in the (currently unspecified) test, and use 342 samples, that is 748 bytes when representing a sample as 2 bytes. Acquires that, hash it with SHA-256 (quite easy on an Arduino), and we have 256 bits that we can affirm indistinguishable from random, if our source including ADC is not defective (that is, meets at least half its target $r$) and the program is running correctly.

Note: We are talking of a sampling rate $2f$ about 10kHz according to this. The LM324 is rated at about 1MHz Gain×BandWidth Product @5V, thus up to a gain of roughly 100, that amplifier is unlikely to limit the bandwidth.

Note: I have intentionally grossly oversimplified and ignored large constant factors, but (I hope) erred on the safe side (lowering $r$), except for the "1/32 full scale" assumption which depends on the unstated schematic.

As often, defining the test is the hard part (to be continued).

We can't define a useful test of an entropy source without some model thereof. Argument: Assume a Cryptographicaly Secure Pseudo-RNG. Seed it once by a fixed constant. By definition of Secure in this context, the output is practically indistinguishable from truly independent random bits without knowledge of the constant. This is an insecure source, since it is easily predictable for one knowing the fixed constant. Yet no test exists able to give any indication of this.

  • $\begingroup$ You can't apply commercial and international mass manufacturing standards to a question like this. DIY TRNGs still pass all the tests, irrespective of attack by the Russians. I can build a kit car that I can't export all over the world. It's still a car. $\endgroup$
    – Paul Uszak
    Commented Mar 20, 2019 at 15:33
  • 1
    $\begingroup$ @fgrieu Here's an example of a model that admits a clear method of supervision for a particular failure mode of decay: crypto.stackexchange.com/a/51878 (practical considerations of handling polonium-210 left as an exercise for the reader) $\endgroup$ Commented Mar 20, 2019 at 15:55
  • 2
    $\begingroup$ @Paul Uszak 1) my "deeply entrenched in literature and standards" targets AIS 31: its example uses a FIPS test, incorrect math, and flawed chi-squared table. 3) "DCSSI emphasizes the need for a cryptographic post-processing". +) The question includes "safe enough" and "evaluate the security". +) AIS 31, me, and others, consider that meaningful test of an entropy source requires some form of model. $\endgroup$
    – fgrieu
    Commented Mar 20, 2019 at 16:08
  • 2
    $\begingroup$ All measurement has underlying modeling assumptions. If you generate a stream of bits that deterministically alternates between 0 and 1, then a measurement of the fraction of 0 bits will give 50%, the best possible, highest-entropy answer for a sequence of independent random bits. Measurement of the alternating 0/1 model under the assumption of the independent random model gives a completely useless answer. Only an idiot would consciously ignore domain knowledge of the physics and engineering of the device; in cryptography, we do not have the luxury of choosing our adversaries to be idiots. $\endgroup$ Commented Mar 20, 2019 at 17:35
  • 2
    $\begingroup$ No on-line casino uses a model, etc... They all measure. As someone who actually worked for an online casino, I can say that is completely wrong. $\endgroup$
    – forest
    Commented Mar 21, 2019 at 19:42

So, you need to do a two-part work. First, you need to make 2+ hardware sensors of an entropy of a different kind. Use the Geiger tube counter [ http://kripton2035.free.fr/geiger-repositor.html ] , avalanche noise generator [ http://www.cryogenius.com/hardware/rng/ ] and when you'll make an ARM microcontroller act as a USB device - make an AM(NOT FM) radio and de-tune it and attach it to the controller's ADC input. Use STM32F4 chips if you need a cheap implementation. Second part of work - the algorithm itself. Use your mathematical skills, but at first I do recommend you to make all the sensors available as a raw inputs via COM port protocol via STM ARM chip. Use raw data to play with mixing algorithm on your PC and try to run some open randomness benchmarks aka "white noise benchmarks" ( use /dev/google to find them ). Feel free to contact me if You have any further questions - we're making a PCB now with full HWRNG onboard

  • $\begingroup$ In my plan (part of the question) I do have two random sources: Zener noise and electron tunnelling; I also have planned the microcontroller and USB: ATtiny85 microcontroller and CH340G USB UART interface. $\endgroup$ Commented Jan 7, 2015 at 9:56
  • $\begingroup$ It will be a way better result if you will use a full-featured ARM microcontroller chip. It's in the same segment by price, it has built-in USB device support, so you will have no problems implementing the RS-232 interfaces for host PC in the microcontroller itself. And also - when you will settle with an algorithm on your host PC - you can add an external memory chip and put your algo in the microcontroller itself :) and with a battery-bacjup power it will be capable of gathering random data even while the host is off. AVR will be too tiny-featured here, I'm afraid $\endgroup$ Commented Jan 7, 2015 at 15:40
  • $\begingroup$ ATTiny85 have enough computational power for mixing the streams, and the microcontroller plus the entropy sources consumes very little power and can be powered by a small Li-Po directly for years. CH340G is turned on only when USB is plugged in. ARM is just too big for this. Also try beat the US$1/each price for ATtiny85 $\endgroup$ Commented Jan 8, 2015 at 17:36
  • $\begingroup$ ATTiny is a good chip, I agree, but the point is that on servers or PC's under some load the need in entropy is not equal through time. You may need no more entropy for some seconds, but after that you may be in need of 16K of it. ATTiny lacks an external memory support as far as I know. And the ability to store your collected entropy and give it by request as many as needed is a big feature nowdays. IMHO $\endgroup$ Commented Jan 14, 2015 at 15:47
  • $\begingroup$ ATtiny85 have quite a bit of memory on its own, and I do have the option to go to a bigger chip like ATmega328P which have even more memory on chip, as well as more IO, speed and external memory options. Both ATtiny85 and ATmega328P is dirt cheap here if ordered from Shenzhen. $\endgroup$ Commented Jan 14, 2015 at 16:48


XORing the two bitstreams should be fine for mixing, by the piling-up lemma.

XORing the output of that with the PRNG in the library above (or any other CSPRNG) would provide whitening. Or just send blocks of the output to Skein (or Keccak if you can find a fast implementation for AVR...)

One thing to be sure you do is continually test for correlation of the two input bitstreams. Correlation would indicate undesirable external influence, and would keep the bias through the XORing of the two bitstreams. That's potentially bad.


The general answer for rolling your own cryptographic primitives in a production system is "don't do it" because it's hard and success depends on long experience. I think the same principle applies here.

If you're doing this to learn something about HWRNG systems, do it, but don't use it for anything that matters. If you're doing it to use it in a real system that people might rely on, I have to question why you'd try to reinvent the wheel when hardware RNGs are widely available and cheap. Even those I've heard grumblings of how good a RNG source they are.

  • $\begingroup$ Existing wheels can be sabotaged. Remember the ECDRBG NSA Backdoor? I need to make sure my HWRNG is not rigged in a way against me. $\endgroup$ Commented Jan 7, 2015 at 9:51
  • $\begingroup$ Perhaps a better approach would be 2 hardware random number generators, made in two different countries. The Snowden leaks revealed the NSA tries to make arrangements with US companies to sandbag their encrption. It's not unreasonable other countries do this as well. Combining the outputs of multiple RNGs made by different companies would make it more difficult for a compromise by a single hacked HWRNG. Also, you have to weigh the risk of doing something wrong with the risk that the HWRNGs are compromised by govt. $\endgroup$ Commented Jan 7, 2015 at 18:19
  • $\begingroup$ I have a price point and try beat this: US\$5 per device at most. Try beat this with pre-made solution. ATtiny85 cost me \$1, CH340G is another \$1, and other parts are less than \$0.1 (maybe less than $0.01) each. $\endgroup$ Commented Jan 14, 2015 at 16:52
  • $\begingroup$ I'm sure you can win on price, if that's really a real constraint. But I don't understand how 5 dollars vs 100 dollars matters much for commercial applications. You might want to check out a group that's trying to make an open HWRNG: onerng.info $\endgroup$ Commented Jan 15, 2015 at 1:21

I've actually built such a thing myself, using a design based on the circuit given here:


As described there I used a MAX232 line driver to get the > 18V in the schematic, hooked it up to an Arduino and managed to get some good random numbers at 115200 baud over the Arduino's USB/serial interface. I couldn't get the random data out any faster though. I did whitening by using the von Neumann algorithm (get pairs of bits, throw away pairs which aren't the same). Managed to get very good random numbers that passed FIPS 140-2 and Robert G. Brown's dieharder suite of statistical tests (successor to George Marsaglia's original Diehard suite). Took a good, long time to get enough random data from the circuit to do the dieharder tests though, which need many megabytes of such data, and 14 kilobytes per second seems to be the absolute limit of an Arduino's I/O.

I tried to get the same circuit hooked up to a PIC microcontroller to make a standalone module that goes straight to USB, but figuring out how to program and wire up the PIC to make it look like a USB device when plugged into a host computer was more work than I had time or money to do. Modern PCs are hell for interfacing simple hardware. Here's the circuit I used there, showing how to hook up a MAX232:


There are good reasons to try to do this sort of thing yourself. The biggest problem with a hardware RNG is the matter of trust. How can you be reasonably certain that a "hardware RNG" you bought off the shelf isn't actually a phony one with output that statistically looks random, but is actually predictable to someone with the right keys? The only real way to make sure is to actually check the hardware and firmware. But how can you check anything if the hardware is sealed in epoxy, and full of tiny, inscrutable surface mount components?

  • $\begingroup$ Are reverse biased transistors stable? and reallyreallyrandom.com/about/golden-rules/… are suggested reads in this case. Also follow the Rob Seward link. You'll see that the backwards configuration isn't temporally stable, and the periods of (in)stability are pretty much unpredictable - an additional piece of entropy! Your last para is absolutely spot on. $\endgroup$
    – Paul Uszak
    Commented Mar 20, 2019 at 11:28
  • $\begingroup$ @PaulUszak 115,200 baud translates to more or less 14 kilobytes per second. $\endgroup$ Commented Mar 20, 2019 at 11:40
  • $\begingroup$ Be aware of ESP8266 and ESP32 devices. You program them as Arduinos in Arduino IDE but clock at up to 260MHz and cost £10. $\endgroup$
    – Paul Uszak
    Commented Mar 20, 2019 at 12:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.