This was his post on Sept. 2013: https://plus.google.com/+TheodoreTso/posts/SDcoemc9V3J
I am so glad I resisted pressure from Intel engineers to let /dev/random rely only on the RDRAND instruction. To quote from the article below: "By this year, the Sigint Enabling Project had found ways inside some of the encryption chips that scramble information for businesses and governments, either by working with chipmakers to insert back doors...." Relying solely on the hardware random number generator which is using an implementation sealed inside a chip which is impossible to audit is a BAD idea.
This was Intel's statement on Nov. 2012: https://software.intel.com/en-us/blogs/2012/11/17/the-difference-between-rdr...
In contrast, RDRAND is the output of a 128-bit PRNG that is compliant to NIST SP 800-90A. It is intended for applications that simply need high-quality random numbers. The numbers returned by RDRAND have additive prediction resistance because they are the output of a pseurandom number generator. If you put two 64-bit values with additive prediction resistance togehter, the prediction resistance of the resulting value is only 65 bits...
I feel increased confidence in the Linux team's efforts to provide security. Keeping track of dependencies is hard.