[146928] in cryptography@c2.net mail archive
Re: [Cryptography] [cryptography] Random number generation
daemon@ATHENA.MIT.EDU (James A. Donald)
Mon Sep 9 18:44:10 2013
X-Original-To: cryptography@metzdowd.com
Date: Tue, 10 Sep 2013 08:37:31 +1000
From: "James A. Donald" <jamesd@echeque.com>
To: cryptography@metzdowd.com
In-Reply-To: <522D5142.3040208@deadhat.com>
Reply-To: jamesd@echeque.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
>> 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.
On 2013-09-09 2:40 PM, David Johnston wrote:
> #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.
This assumes the DRGB is on chip, which it should not be. It
should be in sofware. Your argument is circular. You are
arguing that the DRGB should be on chip, because it is on
chip, that is has some of its menacing characteristics
because it has other menacing characteristics.
> #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.
You repeat yourself. Same circular argument repeated.
> #3 Any method of access is going have to be documented and
> supported and maintained as a constant interface across
> many generations of chip.
Why then throw in RDSEED?
You are already adding RDSEED to RDRAND, which which fails to
address any of the complaints. Why provide a DRNG in the
first place.
Answer: It is a NIST design, not an Intel design. Your design
documents reference NIST specifications. And we
already know that NIST designs are done with hostile intent.
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
