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