But for any other purpose than generating private keys one should NEVER use /dev/random. If you're not sure use /dev/urandom.
I've had to painstakingly explain to certain people why, as an example, erasing a HDD from /dev/urandom is allright. And why their program that simulates some random input should use /dev/urandom.
But no, they babble about true randomness and then complain why they get like paltry few hundred bytes per second.
Even if you have a server running casino games just use /dev/urandom/. It requires a total compromise of the server to get the internal state out of that, and in that case it's easier just to change urandom into /dev/zero.
You should be careful when using word like quality in this context. Some might think that by quality you mean any kind of statistical property. E.g dice rolls generated by either of them are somehow statistically different, which they are not.
What does this mean in practice: If I give you 10 10MB files. 5 of them created with urandom and 5 of them created using hardware RNG there is practically no chance that you could differentiate which came from which, barring knowledge of the urandom entropy pool.
But it is true that HW RNG could be useful just to keep CPU load down. By now we know that those are backdoored by NSA, so you should still use /dev/random as a source for private keys. So HW RNG is useful just to keep the load down. Not to avoid any attacks.
This is so important that I'll have to repeat it again: The only difference between urandom and random is that urandom is theoretically suspectible to an attack which could allow prediction of the output values if the attacked knows the internal entropy pool state. The statistical properties of both are the same.
Agreed that some (e.g. RDRAND) are potentially untrustworthy, but others aren't - for example, linux has daemons available that can source entropy from audio or video noise.
A growing number of chipsets have them built in and accessible.
Many new Intel chips do (though off the top of my head I can't tell you how easy to access it is).
The SoC used in rPis units has one that can be read from at over half an Mbit per second via /dev/hwrng (once the relevant module is loaded), so you can either use it directly or (better for portability) keep reading from /dev/urandom and use rngtools to feed the entropy into the kernel's pool as needed.
In both the above cases there is a trust issue as exactly how the RNGs work is not publically documented, but unless you are extremely paranoid (by neccesity or "issues"!) I woudl consider them decent sources of entropy.
I've had to painstakingly explain to certain people why, as an example, erasing a HDD from /dev/urandom is allright. And why their program that simulates some random input should use /dev/urandom.
But no, they babble about true randomness and then complain why they get like paltry few hundred bytes per second.
Even if you have a server running casino games just use /dev/urandom/. It requires a total compromise of the server to get the internal state out of that, and in that case it's easier just to change urandom into /dev/zero.