[cryptography] [liberationtech] Random number generation being influenced - rumors

James A. Donald jamesd at echeque.com
Mon Sep 9 07:59:06 EDT 2013


On 2013-09-09 2:26 PM, David Johnston wrote:
> 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.

Software solutions are only a failure because software cannot create 
randomness.  Given a supply of colored noise, software can process it 
into white noise, as your on chip software is doing.

You are moving the software solution on chip - where we cannot know 
whether it is a failure or not.

You should have made the raw entropy source available to software, and 
let software do all that stuff.



More information about the cryptography mailing list