💾 Archived View for lasse.nerdcamp.net › gemlog › 20230812.gmi captured on 2023-09-28 at 15:42:18. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

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:

Entropy = 7.885903 bits per byte.

Optimum compression would reduce the size
of this 20971520 byte file by 1 percent.

Chi square distribution for 20971520 samples is 3483056.84, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 110.9453 (127.5 = random).
Monte Carlo value for Pi is 3.469126841 (error 10.43 percent).
Serial correlation coefficient is -0.023079 (totally uncorrelated = 0.0).

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:

Entropy = 7.999982 bits per byte.

Optimum compression would reduce the size
of this 10485760 byte file by 0 percent.

Chi square distribution for 10485760 samples is 261.24, and randomly
would exceed this value 38.07 percent of the times.

Arithmetic mean value of data bytes is 127.5306 (127.5 = random).
Monte Carlo value for Pi is 3.140525490 (error 0.03 percent).
Serial correlation coefficient is 0.000154 (totally uncorrelated = 0.0).

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:

Entropy = 7.998592 bits per byte.

Optimum compression would reduce the size
of this 20971520 byte file by 0 percent.

Chi square distribution for 20971520 samples is 41064.68, and randomly
would exceed this value less than 0.01 percent of the times.

Arithmetic mean value of data bytes is 125.1412 (127.5 = random).
Monte Carlo value for Pi is 3.193315048 (error 1.65 percent).
Serial correlation coefficient is 0.020558 (totally uncorrelated = 0.0).

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

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