----- Forwarded message from David Johnston <dj@deadhat.com> ----- Date: Sun, 08 Sep 2013 21:26:24 -0700 From: David Johnston <dj@deadhat.com> To: cryptography@randombit.net Subject: Re: [cryptography] [liberationtech] Random number generation being influenced - rumors User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 On 9/7/2013 6:11 PM, James A. Donald wrote:

On 2013-09-07 9:14 PM, Eugen Leitl wrote:

...

That's the claimed design, yes. I see no particular reason to believe that the hardware in my server implements the design. I can't even test that the AES whitening does what it is documented to do, because Intel refused to provide access to the prewhitened input.

On chip whitening is extremely suspicious behavior. Since the need for random numbers is low bandwidth, on chip whitening is a waste of silicon.

Despite repeated requests, the decision to do whitening on chip has never been explained.

I answered this once before many months ago, the last time you asked. There is no 'whitener'. It is a CBC-MAC based entropy extractor, as per the spec in the current SP800-90B draft. You can call it a whitener, but that would risk confusing it with things like the Von Neumann or Yuval Peres whiteners, which are a different class of algorithm with different constraints. The reasons for it are: #1) Maintaining a strong security boundary. We don't want an attacker to be able to infer the seed values by exposing them to all sorts of classes of attack by letting the values get into the system state accessible by the microprocessor SW. #2) FIPS compliance. Which is more or less #1 restated. It wants stuff to happen within a well defined boundary. #3) Robust engineering. Our goal is to make the lack-of-entropy problem go away on intel based products. Reseeding the DRBG 2 million times a second is a good way of making it hard to infer the state of the DRBG. This is one of several stages of mitigation design, intended to make the DRBG robust even if a problem should arise with any one of the stages. You can't do that in software. In general, once attackers have got a foot in the door of a software system, it is game over. #4) Software solutions have been a demonstrable failure. At least this hardware solution remains robust. #5) A non-goal is making James A Donald satisfied. Sorry, but no solution compatible with security and manufacturing realities is going to satisfy the demands you have made. DJ _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5