The problems they're supposed to solve are entirely fictional and usually stem from a poor understanding of the real problems there are with random numbers (which can mostly be traced back to a few issues: boot time entropy, userspace RNGs and use of insecure RNGs by mistake).
Good one; how often has encryption (of any sort) been broken due to not enough randomness? I mean I'm a noob but I can imagine that it'd only become a risk over communications that were tracked for a very long time. or something.
There are no known issues with running out of randomness over time. The main reason to re-seed a CSPRNG is as a defense-in-depth against implementation flaws leaking state.
Also, it's not exactly unheard of of "good" prngs having bugs making them bad.
We hear about "good" CSPRNGs going "bad" all the time, but invariably these are instances of people adding new userland CSPRNGs to their systems as rubber chicken security measures that later blow up.
Yes, I have to place trust in the hardware random generator instead. From a user perspective it seems like the attack surface (from the perspective of bad configuration, start seed, misuse etc.) is much smaller with a hardware generator.
And, conceptually it sounds like a safer option. Is it? Well, we arrive at yet another "I don't know".
Note, I'm not advocating the use of a hardware random generator at all, I'm merely responding to the statement that they don't solve any problem at all.
Keep in mind that the issue was present in Windows 2000 yet remained undetected for 7 years after the release of Windows 2000.
I'm very comfortable with the validity of the argument I'm making, which is that we don't generally need to layer rube goldberg hardware onto our systems to hedge against the likelihood of the LRNG going bad.
And I'd argue that getting good seed values is one of the main things that is appealing with a hardware generator (especially at system boot).
You'd still have to use it though.
And, again, Debian's problem was in their version of the OpenSSL userland RNG. Applications that simply relied on /dev/urandom rather than OpenSSL's janky mess weren't impacted by the bug at all.
https://www.schneier.com/blog/archives/2008/05/random_number...
I think RDRAND is well worth the negligible cost of including it. It can give you entropy immediately, even during early boot (e.g. for ASLR); no need to wait or have any logic to deal with entropy not being ready yet (at least if you can rely on it being available, which should be true in the future). And compared to other approaches, it’s a lot harder to screw up or misuse, eliminating a whole class of potential vulnerabilities (especially if you use it directly rather than just seeding a kernel PRNG with it).
That's fine, but boot-time seeding problems are also a real source of RNG-related security problems, as described in the "Mining Your Ps and Qs" paper. (E.g. "The removal of IRQs as an entropy source has likely exacerbated RNG problems in headless and embedded devices, which often lack human input devices, disks, and multiple cores. If they do, the only source of entropy—if there are any at all—may be the time of boot.") Having a hardware TRNG for seeding in this case would presumably prevent these problems.
And it's not a theoretical problem either.
[1] http://forums.xilinx.com/xlnx/attachments/xlnx/EDK/27322/1/H...