On Thu, Jan 3, 2013 at 1:45 PM, Nadav Har'El <n...@math.technion.ac.il> wrote:
> The whole point of the hardware random number generator is that it is > *not* a PRNG, but rather some special hardware which supposedly uses > sources of randomness (e.g., heat) not normally available for software. "Supposedly" is the operative word. As is clear from the Intel page Elazar supplied RDRAND *is* a PRNG. There is an additional instruction, RDSEED, that is "supposedly" truly random, but, as I mentioned, I have not seen an explanation of why it is or how it works. Typically, using only truly random sources is impractical. The entropy is limited and is replenished at a finite speed. If you always use a TRNG you will deplete your source of entropy quickly. Besides, accessing such an entropy source is usually slow - much slower than generating a new pseudo-random number. "Heat" that you mentioned is not very easy to use as a random source: it changes slowly, and measuring temperature (*IN* a CPU!) with high enough precision to use least significant bits is a hell of a problem. > Doing a normal PRNG in hardware instead of software would be kind of > pointless - what could it possibly gain you - improved performance of > the PRNG? Hardly nobody cares about that. Tell that to Intel. ;-) > Anyway, what Ted Tso was "worried" about was that theoretically, the > output of the random number generator *might* be a PRNG As mentioned, it apparently is. > returning a > sequence known to the NSA (or Intel), and there is no way to verify > that this is not the case. It is enough to return a sequence that NSA can crack - it does not have to be known. > In any case, I think what a normal user should do is to use > /dev/urandom - and that should (but I don't know if it does) use both > the hardware and software sources of randomness, as available. This is usable for seeding a PRNG. The entropy pool is small, and the access is very slow. Now, let's assume that Intel did an excellent job, and RDRAND+RDSEED give excellent random numbers. What Ted provided is an in-kernel API to access the thing. Now, all sorts of in-kernel and out-of-kernel things need to use it - SSL, TCP stack (sequence numebrs), etc., etc. -- Oleg Goldshmidt | p...@goldshmidt.org _______________________________________________ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
