From Theodore Ts'o, 2012:
"Create a new function, get_random_bytes_arch() which will use the architecture-specific hardware random number generator if it is present. Change get_random_bytes() to not use the HW RNG, even if it is avaiable.
...
So it's much better to use the HW RNG to improve the existing random number generator, by mixing in any entropy returned by the HW RNG into /dev/random's entropy pool, but to always _use_ /dev/random's entropy pool."
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...
Re:Myths about /dev/urandom (2014)
by matt_wulfeck on Thursday January 05, 2017 @09:33PM
(#13333461)
I'm not sure I'd say it's better or worse. I think it's unnecessary. You only need like ~16 bytes of a random seed and your CSPRNG will run forever with unlimited unpredictable stream of bits.
Intels instructions perform the same as a HWRNG only it's built in to every chipset >= Ivy bridge. I actually think Linux's rng-tools incorporates it as a mix automatically.
I found interesting djb's blog post about a theoretical scenario where mixing entropy can actually be dangerous: https://blog.cr.yp.to/20140205-entropy.html
As of Kernel 4.8, Ted Ts'o has already switched /dev/urandom over to ChaCha20 (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux....), so I would say a good CSPRNG's already done.
With these instructions you'll always get a "good"[1] seed for your CSPRNG, and that includes virtual machines and clones.
[1] Of course that depends on how much you trust Intel. Don't ask the crypto mailing lists whether this is a good idea :-)