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. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
