This is several years old now, but it is an overview of a (failed) attempt to replace Linux's existing random implementation with Fortuna, an improved variant of the Yarrow algorithm used by FreeBSD, and a comparison with Linux's existing random implementation.
This is a thread on LKML about adding support to Linux's random implementation for Intel's RdRand instruction. You have to read all the way through to see the extent of the insanity. ("We can't trust Intel because NSA backdoor government spying chemtrails HAARP fluoride wharrgarbl!")
I can't find the LKML thread to link to it, but earlier this year, there was a hullabaloo over a paper published at https://factorable.net/ regarding network-connected devices generating weak keys because of "insufficient randomness" at boot time. This led to a reworking of how/when/why entropy is fed into Linux's entropy pool.
Trust isn't binary. Backdooring or exploitably bungling the deterministic parts of the CPU without getting caught is much harder than doing the same for the RNG part. Black box RNG's are notoriously hard to evaluate.
Also, I don't remember anyone getting publicly bent out of shape about including AES-NI support in Linux's CryptoAPI. (I'm unsure why people would think Intel would backdoor RdRand but not the AES-NI instructions.)
http://jlcooke.ca/random/
This is a thread on LKML about adding support to Linux's random implementation for Intel's RdRand instruction. You have to read all the way through to see the extent of the insanity. ("We can't trust Intel because NSA backdoor government spying chemtrails HAARP fluoride wharrgarbl!")
http://thread.gmane.org/gmane.linux.kernel/1173350
I can't find the LKML thread to link to it, but earlier this year, there was a hullabaloo over a paper published at https://factorable.net/ regarding network-connected devices generating weak keys because of "insufficient randomness" at boot time. This led to a reworking of how/when/why entropy is fed into Linux's entropy pool.