[openssl-dev] DRBG entropy

[John Denker]

Let's play a guessing game.  I provide a hardware-based random number
generator of my choosing.  It produces a stream of bytes.  It has
an entropy density greater than 2.35 bits per byte.  This claim is
consistent with all the usual tests, but it is also more than that;
it is not just "apparent" entropy or an upper bound based on testing,
but real honest-to-goodness Boltzmann entropy.  The bytes are IID
(independent and identically distributed).  The design and 
implementation are open to inspection.

On each move in this game, I try to predict the exact value of the
next byte.  Every time I succeed, you pay me a dollar; every time
I fail, I pay you a dollar.  We play at least 100 moves, to minimize
stray fluctuations.

The point is, if you think entropy is a good measure of resistance
to guessing, then you should be eager to play this game, expecting
a huge profit.

Would anybody like to play?


On 07/28/2016 12:40 AM, Leon Brits wrote:
> Thanks for the helping me understand the whole entropy thing better.
>  It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct. I am probably just 
> bringing the math down to my level - sorry.
> 
> With that said for validation I still need to be sure that I give the
> required entropy back from the OpenSSL callback. Now since I am not
> allowed to use a hash with the DRBGs (FIPS lab and SP800-90B section
> 8.4), can you please confirm that, with a source of raw 2b/B entropy
> data, I need to return 4 times the data from the callback function?

That depends on what the objective is.  The objective is not
obvious, as discussed below.

> According to FIPS test lab the lowest value from all the tests are 
> used as the entropy and 2 is too low.

  1a) I assume the idea that "2 is too low" comes from the FIPS lab.

  1b) I assume the designer's boss doesn't directly care about this,
   so long as the FIPS lab is happy.

  1c) This requirement has little if any connection to actual security.

> I must however make use of this chip.

  2a) I assume the FIPS lab doesn't care exactly which chip is used.

  2b) I assume this requirement comes from the boss.

  2c) This requirement has little if any connection to actual security.

> I am not allowed to use a hash with the DRBGs (FIPS lab and
> SP800-90B section 8.4),

Where's That From?  Section 8.4 says nothing about hashes.  It's about
health testing.  The hash doesn't interfere with health testing, unless
the implementation is badly screwed up.

Furthermore, in sections 8.2 and 8.3, and elsewhere, there is explicit
consideration of "conditioning", which is what we're talking about.

  3a) Does this requirement really come from the FIPS lab?  It 
   certainly doesn't come from SP800-90B as claimed.

  3c) This requirement has nothing to do with actual security.

> It is still get the feeling that this is a "best effort" thing and 
> that nobody can actually proof what is correct.

Where's That From?

Proofs are available, based on fundamental physics and math, delineating
what's possible and what's not.

> can you please confirm that, with a source of raw 2b/B entropy data, 
> I need to return 4 times the data from the callback function?

Two answers:
 -- My friend Dilbert says you should do that, in order to make the
  pointy-haired boss happy.
 -- You should not, however, imagine that it provides actual security.

> 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

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

The mfgr has not analyzed the thing properly, and nobody else will
be able to analyze it at all.  The block diagram in the datasheet
is a joke:
  http://www.fdk.com/cyber-e/pdf/HM-RAE106.pdf#Page=9

> I must however make use of this chip.

My friend suggests you XOR the chip output with a decent, well-
understood HRNG.  That way you can tell the pointy-haired boss
that you "make use of this chip".



------------

Bottom line: consider the contrast:
-- I'm seeing a bunch of feelings and made-up requirements.
-- I have not yet seen any sign of concern for actual security.

Under such conditions it is not possible to give meaningful advice
on how to proceed.