[openssl-dev] DRBG entropy

[Leon Brits]

John,

> 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?

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

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

Yes

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

Correct - it's about perception of the client

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

They did request information about its working which FDK where not willing to divulge.

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

Correct

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

Correct

> > 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.

I will ask them the question.
 
>   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?

My opinion (after working on this project)

> Two answers:
>  -- My friend Dilbert says you should do that, in order to make the
>   pointy-haired boss happy.

Wise old Dilbert

>  -- You should not, however, imagine that it provides actual security.

Understood.

> 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

Agreed. That is why it was selected (from what I heard).

> 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".

I wish I could, but my only option to solve this now is using software.

Thanks alot for your reply and time taken to help.
Much appreciated
LJB