[Cryptech Tech] Suggested changes to TRNG

[Benedikt Stockebrand]

Hi Joachim and list,

Joachim Strömbergson <joachim at secworks.se> writes:

>> Anyway, what I've done with the ARRGH firmware was to wait until
>> I've seen all 256 byte values from the source and only then start
>> passing random data out.
>> 
>> This is probably a bit over the top, but it's still reasonably fast
>> to start up.  It's reasonably easy to do in an MCU; don't know about
>> FPGAs, though.
>
> Takes a 256 bit wide register and a big honking 256-1 AND gate. Done. ;-)

that's right.  But I'd still rather not make any unwarranted assumptions
about FPGAs---I've dealt more than my fair share with people doing that
and expecting me to make this annoyting thing called reality match their
ideas:-)

>> Using a fixed interval is a bad idea because a fixed interval won't 
>> adapt to tolerances of the components etc.
>
> That is true.

... despite the fact that it is somewhat inconvenient when building
realtime stuff, because you can't fully rely on power-up time.

> One would however also need to add a timer to be able to
> say that longer then XYZ ms before seeing all 256 bit values and the
> entropy source is probably dead. Otherwise you could wait indefinitely.

Correct.  In the ARRGH case I didn't bother because I left that to the
machine I connected the it to---if it was waiting "indefinitely" for the
first random bytes to appear then the TRNG was obviously broken.  But in
the Cryptech case the FPGA effectively *is* that machine, so I didn't
bother.

But anyway, this could have been done in the MCU as well, so if it
didn't finish that self-test within a given time it simply could have
signalled itself as faulty and not provided any output.

> Also, the warmup is just to give the noise sources time to properly
> start, not ensure that they operate correctly.

Right, and there are a number of alternative tests I've considered.  In
the end I decided they don't make much of a difference with regard to
their result, and in some cases they could even be shown to be
effectively equivalent, so I picked the one most convenient to
implement.

In any case, here are some of the alternatives I've considered:

- Don't check for byte size blocks, but some other suitable block size.
  Byte size blocks are convenient, I couldn't do much more in an MCU,
  and the time it took to complete the test was acceptable to me, but
  8 bit blocks aren't exactly set in stone.

- Wait for the number of 0 and 1 bits within a block of some chosen size
  to balance out.  (Involves some math to get the blocksize and
  threshold values right; I never bothered to work this through.)

- Wait for the speed at which output is generated to stabilize.

Anyway, if a 256 bit register and a big AND gate is as straightforward
to set up in an FPGA as you say, I guess you should be just fine with
that.


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/