[Cryptography] The best TRNG architecture, comming soon?

[Bill Cox]

On Mon, Aug 26, 2019 at 9:29 AM Jonathan Thornburg <jthorn4242 at gmail.com>
wrote:

> On Sun, Aug 25, 2019 at 06:14:11AM -0700, Bill Cox wrote:
> > The best, but patented IIRC, architecture for a TRNG is super simple.
> >
> [[ring oscillator with an even number of inversions in the loop,
> and two NAND gates at opposite points in the loop]]
> >
> > In real life, you probably want to add more inverters than this.  This is
> > like a traditional ring oscillator, but with an *even* number of
> > inverters.  You take two inverters at opposite ends of the ring and turn
> > them into NAND gates.  The other inputs of both NAND gates are tied
> > together to make the ENABLE input.  When ENABLE is low, OUT is low.  When
> > ENABLE goes high, two edges in the ring oscillator chase each other.
> > Eventually, due to thermal or other noise, one edge catches the other,
> and
> > they annihilate each other.  The oscillator stops oscillating at this
> point.
>
> Problem: what if the layout (& hence 0->1 and 1->0 propagation times)
> is such that (say) inverter #3 in the loop is a lot slower than the
> others *and* has asymmetric rise/fall?  The result could well be that
> when the first edge reaches inverter #3, it's slow to propagate, so
> the second edge catches up with it right there (inverter #3) resulting
> in the "TRNG" outputting a stream of constant values.  :(
>

Good point.   It is OK for rise/fall to be different, but the lower chain
needs to match the upper chain well.  This requires some manual constraints
in an FPGA/CPLD.  It is possible in some systems (the P&R tools I worked on
for Triad Semiconductor) to copy the place and rout result from instance A
to instance B, translated by some distance in the fabric.  That generally
causes the routing to match well.  I'm not sure if the major FPGA/CPLD
providers offer this functionality.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20190826/864c05de/attachment.htm>