>> 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 [email protected] http://www.metzdowd.com/mailman/listinfo/cryptography
