First, David, thank you for participating in this discussion. To orient people, we're talking about whether Intel's on-chip hardware RNGs should allow programmers access to the raw HRNG output, both for validation purposes to make sure the whole system is working correctly, and if they would prefer to do their own whitening and stretching of the output.
On Sun, 08 Sep 2013 21:40:34 -0700 David Johnston <[email protected]> wrote: > > 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. That seems like a misguided rationale. In particular, given that virtually all crypto software and existing kernels already have to cope with hardware that does not provide this capability, it is probably better that a hardware RNG not be a cryptographic PRNG. It should be a source of actual hard-random bits that feed in to the commonly used software mechanisms. If you can't generate enough of them to satisfy all possible demand, then I think it is architecturally far safer to allow software to make the decision about how to stretch the scarcity, and in any case, the software needs to exist anyway because other hardware does not have the capability. As it stands, the major consumers of your RNG, like the Linux kernel, already end up mixing it in to a software RNG rather than implicitly trusting it. It would be better to go further than this, I think. A far greater concern than non-Intel engineers being bad at building a random number generator in softare is that a fabrication flaw, a post-manufacturing failure, or an intentional fabrication failure induced by a paid agent would reduce the security of the system. It is difficult to test such things as the system is constructed. > #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. I think the same counterarguments hold. In any case, making it impossible even for a privileged process like the kernel to test the thing before returning it to its normal state seems like an unfortunate choice. > #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. There is, however, excellent reason here. > #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. Could you be more explicit about that? Please note we are not asking this sort of thing out of malice. There is now a document in wide circulation claiming multiple chip vendors have had their crypto hardware compromised by intent. Regardless of your own personal integrity, there are others inside your organization that may very well be beneficiaries of the $250M a year the NSA is now spending on undermining security. Indeed, were I running that program, I would regard your group as a key target and attempt to place someone inside it. Do you not agree that you're a major vendor and that your hardware would be a very tempting target for such a program, which we now know to exist? > Access to the raw output would have been a massive can of worms. And yet, you will note that many, many security types would prefer raw output to a finished cryptographic random number source. Intel could always provide a standard C routine to do the conversion from the raw output into a suitable whitened and stretched output. > 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. But, forgive me for saying this, in an environment where the NSA is spending $250M a year to undermine efforts like your own it is impossible for third parties to trust black boxes any longer. I think you may not have absorbed that what a week or two ago was a paranoid fantasy turns out to be true. Perry -- Perry E. Metzger [email protected] _______________________________________________ The cryptography mailing list [email protected] http://www.metzdowd.com/mailman/listinfo/cryptography
