Theodore T'so was right

Ryan Carboni ryacko at gmail.com
Mon Nov 20 19:08:21 PST 2017


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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 2318 bytes
Desc: not available
URL: <http://lists.cpunks.org/pipermail/cypherpunks/attachments/20171120/f1c83efc/attachment.txt>


More information about the cypherpunks mailing list