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

David Johnston dj at deadhat.com
Mon Sep 9 00:26:24 EDT 2013

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 

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.


More information about the cryptography mailing list