How secure is Linux's random number generator?

Even reversing the silicon won't likely help— and, uhh. Reversing a state of the art CPU is not do-at-home stuff.

The reason it won't help is that the design is _explicitly_ microcoded. E.g. RDRAND triggers running loadable microcode which is supposed to read the real RNG and AES it. Maybe there is an unrelated "bug" that allows that microcode to be corrupted after some particular instruction sequence happens. All your investigation would turn up everything looking like normal.

Lame answer I know but: recompile kernel (or patch) out this crappy Intel HW support then ? And IIRC the Linux pseudo random generator was quite good. The only problem is exhausting the entropy pool.

It looks like the microcode is also encrypted. But perhaps that encryption could be reverse engineered from silicon? The Silicon Zoo tutorial noted that Pentium I-era chips were "easily viewable" [1], probably with optical microscopes. So perhaps some parts of some newer Intel processors can be done at home. So, the "plan of attack" (ha!):

* decap an Intel CPU and scan it

* decode the microcode encryption

* figure out how the hardware RNG works with the microcode (it's AES? ok.)

* and then analyzing the system of microcode and hardware for robustness and security.

Yeah, this is hand-wavey and probably incredibly implausible. But it seems like an interesting and challenging project or three.

[1] http://siliconzoo.org/tutorial.html

The best approach to have is IMHO here:

http://en.wikipedia.org/wiki//dev/random

Gutterman, Pinkas, & Reinman in March 2006 published a detailed cryptographic analysis of the Linux random number generator[5] in which they describe several weaknesses. Perhaps the most severe issue they report is with embedded or Live CD systems such as routers and diskless clients, for which the bootup state is predictable and the available supply of entropy from the environment may be limited. For a system with non-volatile memory, they recommend saving some state from the RNG at shutdown so that it can be included in the RNG state on the next reboot. In the case of a router for which network traffic represents the primary available source of entropy, they note that saving state across reboots "would require potential attackers to either eavesdrop on all network traffic" from when the router is first put into service, or obtain direct access to the router's internal state. This issue, they note, is particularly critical in the case of a wireless router whose network traffic can be captured from a distance, and which may be using the RNG to generate keys for data encryption.

It shouldn't be a religious but an engineering problem. If you manage keep some state between reboots and use it after the next reboot, you're making it hard enough for anybody not having the physical access to that state. Then you can also use RdRand to mix it with the output of your stream based on your state, and with other sources of entropy if you have them. If RdRand turns out to be suspicious, you're at least much better off than using only hard coded states.

Anybody knows if some kind of described state is used now?

Calculate how many bits intel could fit on a chip. Apply statistical tests until you're sure the output contains more than that much entropy?