Compare with NeuG and the BitBabbler

[waywardgeek]

I just took a look at the BitBabbler page.  From the How tab, it sounds like they're using Peter Allan's analog modular multiplier circuit (like I used in my Infinite Noise TNRG: https://github.com/waywardgeek/infnoise).  While on Wikipedia, their entry is listed as open hardware, I was not able to find any schematics.  TrueRNG pulled this same tactic, always claiming they were open, without ever offering schematics.

>From the scarce details describing they actually built, I have three concerns:

1) Where's the schematic?  This is a deal-breaker.
2) Why would they build one with 4 circuits?
3) It sounds like they multiply by 2X, which makes me think their circuit may not be reliable.

tl;dr There's really no reason to keep reading... the conclusion is obvious: don't buy a BitBabbler until we see evidence of an open design.

However, having built a modular analog multiplier based TRNG, I can make some more comments from what I've read.

They built a high-end version with 4 circuits.  This concerns me.  If they properly built an analog modular multiplier, then there is no good reason for having more than one circuit.  I carry one of my Infinite Noise TRNGs in my pocket, just for fun.  It has exactly the right number of noise sources: 1.  A properly designed modular analog multiplier noise source should be 100% trustworthy 100% of the time, except when they fail, and in that case, the health monitor should detect the failure with near 100% probability.

I can't think of any good reason anyone should want two TRNG sources in their TRNG package.  The single biggest issue, although minor, is that the OneRNG avalanche noise source is not quite trustworthy/reliable enough, so they added an RF noise source, which is also not quite trustworthy enough.  If they ever redesign the OneRNG circuit, I hope they will use a more trustworthy source, and reduce the cost and complexity of their design.  A modular analog multiplier is my favorite, but with good shielding and health monitoring, they could use traditional ring oscillators, which is even cheaper.

The BitBabbler, if done right, should not have any reason for wanting a second source.  The first one should be provably random, based on thermal noise that is always there.  Since they have 4 in their high-end device, I suspect they have not quite figured out the right way to build the TRNG noise source.

It is possible they just wanted higher bit-rates.  If so, this concerns me, since no one should need higher bit rates than a few hundred bits of unpredictability per second.  TRNGs do not need to be fast, because we only use them to seed the CPRNG in /dev/random (or some other CPRNG).  Once seeded, the only reason to ever read more bits from the TRNG is in case you are concerned that the CPRNG state may have been leaked, and you want to be able to recover.  Recovery every second or so should be often enough for even the most paranoid, and 512 bits of unpredictability seems to be enough for modern crypto, even post-quantum crypto.  Anything over about 512 bits per second of entropy is over-kill.

So... I worry they use 4 circuits because they find that some of their circuits either fail completely, or that they fail intermittently.  This leads me to my third concern...

Cheap modular analog noise multiplier based TRNGs should not multiply by 2X per stage, unless extra circuitry (thus less cheap) is added to deal with the following case:

A cheap modular analogue multiplier is built using a high-input impedance rail-to-rail CMOS op-amp.  Both Peter and I did independently in our designs.  In this circuit, you will find that using a gain of 2.0 leads to a circuit that sometimes gets stuck on one rail or the other.  Assume that the supply voltage is 1.0V.  If the input is about 0.25V, and the output of the op-amp is 0.5V.  If the comparator decides that the op-amp output is >= 0.5V, it subtracts 0.5V.  This leaves the analog signal at 0V.

In the next pass, when we multiply 0V by 2X, we still have 0V.  If there is some input offset in the right direction on the op-amp, you will stay stuck at 0V until a large enough noise spike knocks you out of that state.  If the input offset is in the other direction, you will find that the output can get stuck at 1V.

The simplest solution I found was to multiply by less than 2X.  I used 1.82X, because 8.2K and 10K Ohms are common resistor values.  This pulls the output voltage away from both supply rails.  The entropy per clock cycle drops, but that just means we get entropy at a bit lower rate, and it is still many times faster than we need.  You still need some way to get the circuit away from the rails in the first place.  I did this by adding a pull-down resistor on one of the op-amp outputs.  This makes it impossible for either 0V or VDD to make it through the loop without getting knocked away from the rails, at which point the circuit starts operating properly, and never returns to a voltage near the rails.

With this circuit, you can show there is enough thermal noise, and can show that the entropy per output bit is very close to log2(1.82).  I check this in the health monitor, and only accept the bits if this is true to within 3%.  The 3% is needed because of component tolerance.  The model otherwise is much more accurate than that.

Anyway, it sounds like BitBabbler used something close to my preferred circuit.  If they publish their design, I'd be happy to help them make it more reliable if they currently have issues.  Both Peter and I are glad to see others using this technique, and are happy to help.

Bill