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-rdrand-and-rdseed > 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.
