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

[Eugen Leitl]

----- 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