[onerng talk] The best TRNG architectu Was: The NIST QMRNG

[Paul Campbell]

On Wednesday, 18 April 2018 11:10:41 AM NZST Bill Cox wrote:
> This is a ring oscillator with an *even* number of inverters.  Have two
> inverters at maximum distance from each other be NAND gates instead, so you
> can halt the oscillator.  When the "en" signal goes high, there are now two
> edges in the ring oscillator that will chase each other like children
> running around a kitchen island.  Eventually, due to unpredictable noise,
> one edge will catch the other, and the ring oscillator will stop
> oscillating.  Write code or use digital logic to detect when the oscillator
> halts.   The unpredictable output is the time it takes to halt.  Measure
> this with a microcontroller timer, or a free-running counter.

actually, putting on my "I used to design chips" hat I'd disagree - circuits 
like that are terribly hard to make consistent (by that I don't mean make 
identical noise, I mean reliably make random outputs - 90% might work and the 
rest might be tweeked a bit too much)

You're also measuring a metastable output, to make sure that the metastability 
doesn't corrupt the rest of the upstream logic you're going to have to trade 
accuracy in your measurement for the safety of your circuits (and of course 
with metastability nothing is EVER perfectly safe)

-----------------

On the big chips I used to build, one of my jobs was dealing with 
metastability - stuff moving across clock crossings (pixel clocks to memory 
clocks, pci clocks to memory clocks etc) - essentially you mitigate 
metastability issues by trading latency (multiple parallel synchonisers across 
fifos, chains of special high-gain metastability hardened  flip flops etc etc 

Mostly you want to avoid a large chunk of your chip turning from a bunch of 
flip flops running syncronously to the beat of a clock to a buzzy mess that 
literally melts down. Instead you make that really hard and give up some 
latency and performance and calculate statistically how often your chip is 
going to fail - our first we calculated would last a decade, at the time 
windows 95 couldn't stay up a week, we figured no one would notice

------------------

Having said that for random stuff some metastability is good - onerng's main 
noise generator is sampled metastably by design specifically for the added 
random it gives, I did a lot of testing to make sure the underlying die wasn't 
going to turn into a buzzy mess (I've never seen one do that, TI seem to know 
what they're doing) but I'm sampling a far lower freq than what Bill's design 
above will likely generate. I'd be very uncomfortable making a commercial 
product based on something like what Bill is suggesting without making custom 
silicon (designed for the heat dissipation at those arbitrary freqs, you can't 
let it run at an 'infinite' speed safely, you need something to slow it down 
or to get rid of the heat), carefully characterizing it and testing each die

In reality almost no one needs enormous amounts of random, you just need 
enough entropy to top up the entropy in the software PRNGS in places like /
dev/random at the rate that your system exposes it to an external attacker 
(which is likely really some fraction of a bit per transaction)

Personally I think OneRNG is overkill for 95% of the applications people use 
it for, but too much is better than too little.

Also I'd like to point out that OneRNG's secondary random generator makes far 
better quality random that its main one (that's obtained by scanning around to 
random spots in and around the wifi band for empty channels and grabbing the 
LSB of the raw qam data - essentially the noise, even on an interfering signal 
since we don't allow the recv PLLs to lock it's essentially more minor 
metastability in the RF sampling as well. Mixing that with the main random 
generator makes pretty much foolproof noise. The one down side of the freq 
hopping is that periodically it stops generating noise for a while as it 
moves.

	Paul