On Tue, Dec 30, 2008 at 11:45:27AM -0500, Steven M. Bellovin wrote: > Of course, every time a manufacturer has tried it, assorted people > (including many on this list) complain that it's been sabotaged by the > NSA or by alien space bats or some such.
Well, maybe it has. Or maybe it was just not competently implemented, or perhaps it has a failure mode that was not accounted for. The design might be perfect but the physical implementation that happens to be in your computer has a manufacturing flaw such that if the CPU core voltage is slightly low and the ambient temperature is above 95F, the raw output becomes biased from a uniform distribution in a subtle way - how do you detect something like that? I personally would not trust the direct output of any physical hardware source for anything, precisely because you cannot measure it, or test for failures, in any meaningful way. That does not mean it is not a useful thing to have. > It's not obvious to me that you're right. In particular, we need to > consider how such an instruction would interact with a virtual machine > hypervisor. Is it a bug or a feature that the hypervisor can't > intercept the request? Remember that reproducibility is often a virtue. We already have this problem with rdtsc and equivalent cycle counter reading instructions. ISTR that some architectures allow the kernel to forbid access to the cycle counter - if so, similar techniques could be used for a rdrandom instruction. For those that don't, the non-reproducability ship has already sailed (think of rdtsc as a rdrandom that has a very bad probability distribution). Reproducability is sometimes a virtue, but sometimes not. I recall discussions last year, I believe on this list, about how to design a PRNG that was able to safely deal with VM state rollbacks. A user-accessible RNG instruction would easily alleviate this problem. > The JVM could just as easily open /dev/urandom today. Except when it doesnt exist - in which case most Java software seems to default to things like seeding a PRNG with the timestamp, because the other alternatives that are feasible in Java, like interleaving counter reads among multiple threads, are slow, difficult to implement correctly, and even more difficult to test. -Jack --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [email protected]
