[openssl-dev] DRBG entropy

[John Denker]

In the context of:

>> I have a chip (FDK RPG100) that generates randomness, but the
>> SP800-90B python test suite indicated that the chip only provides
>> 2.35 bits/byte of entropy

On 07/28/2016 09:08 AM, I wrote:

> That means the chip design is broken in ways that the manufacturer
> does not understand.  The mfgr data indicates it "should" be much
> better than that:
>   http://www.fdk.com/cyber-e/pdf/HM-RAE103.pdf

To be scientific, we must consider all the relevant hypotheses.

1) For starters, let's consider the possibility that the python
 test suite is broken.  Apply the test suite to a sufficiently
 random stream. 
  -- An encrypted counter should be good enough.
  -- /dev/urandom is not a paragon of virtue, but it should be
    good enough for this limited purpose.

1a) If the test suite reports a low randomness for the truly random
 stream, then the test is broken.  Find a better test suite and
 start over from Square One.

1b) If the test suite reports a high randomness for the random stream
 but a low randomness for the chip, the chip is broken and cannot be
 trusted for any serious purpose.
  -- You could derate it by another factor of 10 (down to 0.2
   bits per byte) and I still wouldn't trust it.  A stopped
   clock tells the correct time twice a day, but even so, you
   should not use it for seeding your PRNG.
  -- It must be emphasized yet again that for security you
   need a lower bound on the randomness of the source.
   Testing cannot provide this.  A good test provides an upper
   bound.  A bad test tells you nothing.  In any case, testing
   does not provide what you need.  Insofar as the chip passes
   some tests but not others, that should be sufficient to prove
   and illustrate the point.

 Seriously, if the FIPS lab accepts the broken chip for any
 purpose, with or without software postprocesing, then you
 have *two* problems:  A chip that cannot be trusted and a
 lab that cannot be trusted.


2a) We must consider the possibility that the bare chip 
 hardware is OK, but there is a board-level fault, e.g.
 wrong voltage, wrong readout timing, or whatever.

2b) Similarly there is the possibility that the bare chip
 hardware is OK but the data is being mishandled by the
 system-level driver software.  This should be relatively
 easy to fix.

===========

It must be emphasized yet again the entropy (p log 1/p) is
probably not the thing you care about anyway.  If the entropy
density is high (nearly 8 bits per byte) *and* you understand
why it is not higher, you may be able to calculate something
you can trust ... but let's not get ahead of ourselves.