Is RNGCryptoServiceProvider as good as a hardware RNG?

Question

I'm attempting to work out whether a hardware RNG is actually any safer than RNGCryptoServiceProvider.

Given that randomness from RNGCryptoServiceProvider is provided using various system and user data such as the process ID, thread ID, system clock, system time, system counter, memory status, free disk clusters, and hashed user environment block along with international standard cryptography algorithms[ref], are there really any good reasons to use a hardware RNG for a security application, apart from speed?

EDIT: I would like to presume in all this that the computer on which the RNG is running is not comprimised - ie, there is no spying app on it.

Answer 1

No, RNGCryptoServiceProvider is not as good as using hardware.

But it is a lot cheaper and available on every machine. And good enough (and fast enough) for most use cases.

Answer 2

Its a great question, and I suspect the answer is (as Henk suggested) more theoretical. A hardware component could be employed to generate white noise, then sampled and used as a hardware RNG. In theory this would be 'more random' than using timings from the system.

In practice though, RNG's are put to the test when they go through FIPS certification. RNGCryptoServiceProvider has qualified through FIPS 140-2 certification (source: http://technet.microsoft.com/en-us/library/cc750357.aspx)

Some of the answers are based on a misconception that because the software RNG uses known sources for its input values, then those input values can be monitored and the seed discovered.

This isn't a true weakness (if it was the same could be said of the hardware RNG, we could monitor its current (single?) value and determine the seed)

The weakness (if any) is that most software RNG's use input sources that can be manipulated (to a degree) in software. This would allow spectacularly well crafted malware to manipulate the hardware to a point where the RNG outputs a predictable (ie non-random) number.

Answer 3

Whatever parameters the PRNG implementation uses as a seed, they have a limited amount of entropy - at most the length of the representations of the values, but in reality much smaller (for example, PIDs are easy to restrict to a likely range; system time is very easy to guess accurately, etcetera). No matter how much data you generate from a PRNG seeded this way, the amount of entropy remains the same, and thus the amount of work required to determine the seed remains the same.

With a hardware RNG, in contrast, the amount of entropy is the amount of data generated. There's no possibility of brute-force searching the set of possible seed values, because there's no state to exploit.