So I built a HRNG - how do I know if it's any good?

Out of curiosity, and to use up some of my big bunch of quad op amps, I decided to build a hardware random number generator. It is comprised of 16 individual 12V-Zener-Diode noise generators, which feed into 8 comparators to generate 8 output bits at once. Those 8 bits can be sampled as a single byte by a microcontroller and then sent over UART to a PC. The principle is based on the Lampert circuit, where two uncorrelated noise sources are fed into a single comparator, to avoid biasing problems due to a shifting operating point in the Zener noise sources.

This is how it looks

To avoid having to use an ADC, I decided to simply sample the 0's and 1's that the comparator outputs provide. Lest I have to wait for 8 samples to fill a whole byte, I simply made 8 individual and uncorrelated noise generators that can be sampled at once. With a UART transmit baud rate of ~0.9 megabaud, the generator's outputs are sampled at ~90kHz, which is easily handled using jellybean op amps and comparators like the TL074 and LM339. The "big red button" allows to divide the baud rate down in steps of two, down to only 3600 baud, and thus reduce the sample rate accordingly.

The most important part of the schematic

The Zener generators are powered by ~15V, which are generated by a boost converter from the 5V USB supply, which powers the whole shebang. The booster is not shown on the schematic, but it is a bog standard MC34063 affair. With a correctly chosen current limit resistor, it is electrically silent and fairly efficient, too. No need for the latest fancy SMD stuff here.

The hardware is actually finished for more than a year now, but I haven't used it for anything serious since. Just yesterday my interest was piqued again though by the following article:

https://milksad.info

I am totally not into anything cryptocurrency-related, and probably never will (in fact, I firmly reject Bitcoin and similar stuff), but I am interested in generating strong cryptographic keys for SSH, PGP and LUKS. One time pads are interesting, too, but I haven't had any use for them to this day.

Sample output

For testing, I have recorded 20MiB of data. The histogram of a resulting image file looks like this:

./histogram_raw.png

The result of ''ent'' is this:

Certainly not perfect. So I fed little chunks of 128 raw bytes into SHA512, to get 64 ''whitened'' bytes out. Here's the resulting histogram:

./histogram_white.png

And the ''ent''-result:

Looks quite useable to me, now - but then again, what do I know?

What do you think? Any opinions, please reach out and let me know!

mailto:gemini@preamp.org

Update 2023-08-14

Ruminating about the performace of the HRNG for another two days, I came up with a little firmware update. Like any security related microcode updates these days, it came with a big hit in performance - a drop of about 12% in throughput, down to 73,7 kB/s at 921600 baud. Previously I would just read in the whole hardware port (1 clock cycle) and immediately put it out on the UART (20 clock cycles all-in-all). Now I am XOR-ing the newly acquired byte with the previous one, and then put that result out on the UART. This brings three more clock cycles to the table, one for the XOR and two for rotating through the buffer, yielding 23 clock cycles for 10 baud instead of only 20 from before. The resulting histogram looks a lot nicer though:

./histogram_new_raw.png

And the ''ent''-result:

And I guess throwing 1024 bits at SHA-512 is a little overkill; 768 bits ought to be enough, maybe even less than that.

Another Update 2023-12-08

Squashed a serious bug. I really messed up the serial transmit routine on the AVR. Until a couple of days ago, I didn't realize that CBI and SBI actually take two clock cycles to execute on the processor that I chose, and not just one cycle as I wrongly assumed. This introduced a timing error on the stop bit, amounting to a whopping 5%. That would work okay for a couple of characters, but since I'm banging out bytes as fast as possible, that would lead to an error every couple of bytes. Those errors probably occurred somewhat regularly and thus contributed the sawtoothy-ness that is easily seen on the histograms. Now that I have fixed the baud rate error (and finally double-checked it with a logic analyzer), the histogram looks much better, with the top much more like random noise and no regular sawtooth anymore.

Things I've read:

https://reallyreallyrandom.com

Robust, low-cost, auditable random number generation for embedded system security

preamp's gemlog on 2023-08-12,

an overcast saturday in august

back to the index