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

Wed Apr 18 00:10:41 BST 2018

What's the best TRNG architecture now days for a USB TRNG, just in case
there is a OneRNG2?

It is almost certainly not a "quantum" TRNG.  I'll leave it at that.
Here's what IMO is the best TRNG architecture for both USB sticks and
on-chip applications.  No, it actually isn't my Infinite Noise multiplier :)

The best TRNG architecture, IMO, is a simple digital circuit that you can
implement in any cheap configurable logic device, even a PAL.  Here's the
PALASM/Verilog-like equations for the logic:

n1 = !(n10 & en);
n2 = !n1;
n3 = !n2;
n4 = !n3;
n5 = !n4;
n6 = !(n5 & en);
n7 = !n6;
n8 = !n7;
n9 = !n8;
n10 = !n9;

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.

These raw counter values should be the output of the TRNG.  They need to be
accessible for health testing on all platforms that use such a TRNG.  Many
runs should in theory form a Poisson distribution
<https://en.wikipedia.org/wiki/Poisson_distribution>.  The health checker
should verify this, which gives a good indication that the TRNG is healthy
and can be trusted to generate secret keys.

To generate secret keys, simply initialize a CPRNG with enough
unpredictable bits.  For example, use ChaCha20, or just SHA256
over-and-over, where the output is the SHA256 of one of the SHA256 chain
values.  This faster than the TRNG, and more secure, so long as you
initialize the CPRNG with enough counter values from the TRNG.  The number
of counter values needed is easy to compute from the Poisson distribution
formed during the health check.

Virtually all TRNGs should eventually migrate to this architecture, unless
a better one is discovered, IMO.

WARNING: I am not allowed by my employer to search for patents covering
ideas like this.  The fact that almost no one uses this architecture leads
me to believe that patents covering this area likely exist.  This is why I
say most TRNGs should *eventually* use this architecture.  It has to
eventually be free for all to use.

On Wed, Apr 11, 2018 at 5:49 PM, Jim Cheetham <jim at gonzul.net> wrote:

> OneRNG <http://lists.onerng.info>
>
> [image: Photo of Jim Cheetham] <http://lists.onerng.info/p/jimc>
> *The NIST QMRNG* <http://lists.onerng.info/r/topic/22XdQEFuX7qKcrRLNrMq9k>
> by *Jim Cheetham* <http://lists.onerng.info/p/jimc>
> in *OneRNG Talk* <http://lists.onerng.info/groups/onerng-talk>
> ------------------------------
> I just came across an article discussing NIST's recent work on a
> "guaranteed random" generation mechanism.
>
> https://*www.theregister*.co.uk/2018/04/11/nist_
> random_numbers_quantum_mechanics/
> <https://www.theregister.co.uk/2018/04/11/nist_random_numbers_quantum_mechanics/>
>
> The paper is published in Nature, 11 April 2018:
> https://*www.nature.com*/articles/s41586-018-0019-0
> <https://www.nature.com/articles/s41586-018-0019-0>
>
> The idea seems to be that entangled photon can have their polarisation
> states measured in such a way that violates the usual expectation that
> "experimental outcomes are governed by pre-existing local attributes
> of particles being measured"
>
> This apparently leaves us with a randomised state that is not
> dependent on pre-existing conditions; i.e. one that is actually
> random, rather than the standard that we usually use, which is "the
> state is predictable but we don't have sufficient measurements to be
> able to do the prediction".
>
> It's easy to see how tossing a coin or a die could be predicted given
> sufficient information about how the toss was performed, for example.
> In a similar way, the thermal and electrical properties of OneRNGs
> diodes might be predictable - although I've not heard anyone suggest
> that this is a practical procedure, except in the extreme case of
> malfunctions.
>
> But NIST's approach might be significantly 'better', except that with
> the current implementation you'd need the USB stick to be a triangle
> over 100m on each side, which isn't exactly going to fit in the post
> from China ...
>
> -jim
> ------------------------------
> ⮪ Reply <onerng-talk at lists.onerng.info?subject=Re%3A%20The%20NIST%20QMRNG>
>   🖂 New topic <onerng-talk at lists.onerng.info>   View topic…
> <http://lists.onerng.info/r/topic/22XdQEFuX7qKcrRLNrMq9k>
> Unsubscribe
> <onerng-talk at lists.onerng.info?subject=Unsubscribe&body=Hello%2C%0A%0APlease%20remove%20me%20from%20OneRNG%20Talk%0A%3Chttp%3A//lists.onerng.info/groups/onerng-talk%3E%0A%0AThank%20you.>
>  •  Switch to a daily digest
> <onerng-talk at lists.onerng.info?subject=Digest%20on&body=Hello%2C%0A%0APlease%20switch%20me%20from%20receiving%20one%20email%20per%20post%20to%20the%20daily%0Adigest%2C%20which%20summarises%20the%20all%20the%20posts%20made%20each%20day%20in%0AOneRNG%20Talk%0A%3Chttp%3A//lists.onerng.info/groups/onerng-talk%3E%0A%0AThank%20you.>
>
>    - Privacy <http://lists.onerng.info/policies/privacy/>
>    - Acceptable Use <http://lists.onerng.info/policies/aup/>
>    - Terms of Service <http://lists.onerng.info/policies/tos/>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/discuss/attachments/20180417/9fed4596/attachment.html>