[openssl-dev] DRBG entropy

John Denker ssx at av8n.com
Mon Aug 1 13:33:59 UTC 2016


On 08/01/2016 02:17 AM, Leon Brits wrote:

> Am I correct to state that for a tested entropy source of 2b/B and
> the same assumptions as in the paragraph, I need to return 8 blocks
> of 16B each in my get_entropy() callback?

No, that is not correct, for the reasons previously explained.

> Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7).

That assumption is invalid, if we believe the LRS test.
Quoting from LRS.py:

>> # Length of the Longest Repeated Substring Test - Section 5.2.5
>> # This test checks the IID assumption using the length of the longest repeated
>> # substring. If this length is significantly longer than the expected value,
>> # then the test invalidates the IID assumption.

Accumulating 8 or more blocks might make sense if the data were IID,
but it isn't.  Either that or the LRS test itself is broken, which
is a possibility that cannot be ruled out.  By way of analogy, note
that the p(max) reported by the Markov test is clearly impossible
and inconsistent with the reported min-entropy.

Suggestion:  Modify LRS.py to print (in hex) the longest repeated
substring.  Then verify by hand that the string really does recur
in the data.
 -- If it doesn't, then the test is broken.
 -- If it does, then either the chip is broken or you're using it wrong.

Remind your boss that the whole point of the certification process is to
make sure that broken hardware doesn't get certified.

Also:
 *) Please stop using "entropy" as a synonym for randomness.  Some things
  have very little entropy but are still random enough for a wide range
  of purposes.  Meanwhile other things have large entropy but are not
  random enough.
 *) Please stop using "entropy" as a synonym for "min-entropy".  The
  latter is a two-word idiomatic expression.  A titmouse is not a mouse.
  Buckwheat is not a form of wheat.  The Holy Roman Empire was neither
  holy, nor Roman, nor an empire.

Just because openssl is sloppy about this doesn't make it OK.


More information about the openssl-dev mailing list