[openssl-dev] DRBG entropy
Leon Brits
leonb at parsec.co.za
Fri Jul 29 08:00:17 UTC 2016
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
More information about the openssl-dev
mailing list