[146891] in cryptography@c2.net mail archive
Re: [Cryptography] [cryptography] Random number generation
daemon@ATHENA.MIT.EDU (David Johnston)
Mon Sep 9 08:57:55 2013
X-Original-To: cryptography@metzdowd.com
Date: Sun, 08 Sep 2013 21:40:34 -0700
From: David Johnston <dj@deadhat.com>
To: cryptography@metzdowd.com
In-Reply-To: <20130908112746.GS29404@leitl.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 9/8/2013 4:27 AM, Eugen Leitl wrote:
> ----- Forwarded message from "James A. Donald" <jamesd@echeque.com> -----
>
> Date: Sun, 08 Sep 2013 08:34:53 +1000
> From: "James A. Donald" <jamesd@echeque.com>
> To: cryptography@randombit.net
> Subject: Re: [cryptography] Random number generation influenced, HW RNG
> User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
> Reply-To: jamesd@echeque.com
>
> On 2013-09-08 3:48 AM, David Johnston wrote:
>> Claiming the NSA colluded with intel to backdoor RdRand is also to
>> accuse me personally of having colluded with the NSA in producing a
>> subverted design. I did not.
> Well, since you personally did this, would you care to explain the
> very strange design decision to whiten the numbers on chip, and not
> provide direct access to the raw unwhitened output.
#1 So that that state remains secret from things trying to discern that
state for purposes of predicting past or future outputs of the DRBG.
#2 So that one thread cannot undermine a second thread by putting the
DRNG into a broken mode. There is only one DRNG, not one per core or one
per thread. Having one DRNG per thread would be one of the many
preconditions necessary before this could be contemplated.
#3 Any method of access is going have to be documented and supported and
maintained as a constant interface across many generations of chip. We
don't throw that sort of thing into the PC architecture without a good
reason.
#4 Obviously there are debug modes to access raw entropy source
output. The privilege required to access those modes is the same debug
access necessary to undermine the security of the system. This only
happens in very controlled circumstances.
>
> A decision that even assuming the utmost virtue on the part of the
> designers, leaves open the possibility of malfunctions going
> undetected.
That's what BIST is for. It's a FIPS and SP800-90 requirement.
>
> That is a question a great many people have asked, and we have not
> received any answers.
Yes they have. I've answered this same question multiple times.
>
> Access to the raw output would have made it possible to determine that
> the random numbers were in fact generated by the physical process
> described, since it is hard and would cost a lot of silicon to
> simulate the various subtle offwhite characteristics of a well
> described actual physical process.
Access to the raw output would have been a massive can of worms. The
statistical properties of the entropy source are easy to model and easy
to test online in hardware. They are described in the CRI paper if you
want to read them. That's a necessary part of a good entropy source. If
you can't build an effective online test in hardware then the entropy
source is not fit for purpose.
DJ
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography