It's also nice to see a more EE oriented post on hacker news now and again.
The reality is that it's just not that hard to generate quality random numbers after a few seconds have passed after bootup on a busy system. Nothing needs gigabit rates of random numbers.
The cases where applications have had lousy random numbers have all been boneheaded implementation bugs (like the early 90s Netscape one the reference).
There are two reasons why this had not been implemented until now:
1. Low demand. It's entirely practical for applications to generate random numbers in software, especially with help from the kernel. With a hardware RNG on some chips, a fallback implementation would still have to be available and people who care about their CSPRNGs in software wouldn't fully trust Intel's numbers anyway.
2. Additional design, documentation, and testing burden. Every feature has a cost. The cryptographic qualities of random numbers are nearly impossible to test as a black box.
For example, adding a tiny amount of film grain to the final rendered image would most easily be done with RNG.
Another example: it's common for renderers to accumulate the scene's illumination into a HDR texture, and then radially blur it. The goal is to approximate the halo you observe around light sources at night time. The problem is, a Gaussian blur is perfectly smooth --- so the resulting glow typically ends up being a perfectly smooth blurry circle of light. But a real photograph of the same scene rarely has smooth glows. The image exhibits all kinds of subtle noise in the light's corona. After all, a photograph results from interaction of light with the camera lens, multiple scattering in outdoor scenes, chromatic dispersion, interaction between polarized light and certain materials, ... and many, many more phenomena.
So rather than try to model each of those physical lighting effects in realtime, it would be wonderful to have a "RNG()" shader function to simply add a smidgen of unpredictability to our realtime rendering techniques. The closer your final image resembles nature, the better it looks --- and nature is many things, but she is not a perfectly smooth BRDF lighting model!
So yeah... It would be frickin' sweet to have this RNG on a GPU.
Consider a Monte Carlo algorithm on a 2 GHz processor, with a 50 instruction cycle inner loop, using a 64 bit random value per loop: it needs 2.5 Gb/sec of random bits.
Edit: It just occurred to me that you're probably referring to the implementation, not the existence of a hardware RNG in x86. Doh!
I assume they're controlling the system to ensure that the thermal noise dominates, and that the de-bias feedback loop and signal conditioner can strip out any low frequency thermal changes (like, temperature forcing through heavily loading CPU).
There are some really neat attacks that use thermal system properties to leak or force information. A submission from a while back: http://news.ycombinator.com/item?id=2872274 struck me as particularly sneaky.
[1] https://secure.wikimedia.org/wikipedia/en/wiki/Metastability...
Why not generate a random #, and index to a random customer, and re-seed? One extra DB lookup and you've got a whole lot more randomness (like a private lava-lamp) to access.
Non-DH-based exchanges are even worse - the entire exchange hinges on a random number generated by the _client_. The server effectively doesn't even have a chance to generate a random number at all.
One interesting story about exploiting a poor RNG in Online Poker: http://www.cigital.com/papers/download/developer_gambling.ph...
https://webcache.googleusercontent.com/search?q=cache:AdC18Y... is another one, where the PRNG seed for a shared Nethack server wasn't random enough, and could be discovered and synchronised for fun and cheaty profit.
http://en.wikipedia.org/wiki/40-bit_encryption
Seems to agree with me.
They link to this page with more details: http://www.cs.berkeley.edu/~daw/papers/ddj-netscape.html
Another reason to disable SSLv2 on servers, BTW.
