[148522] in cryptography@c2.net mail archive
Re: [Cryptography] [IP] 'We cannot trust' Intel and Via's
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Thu Dec 19 11:29:22 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <BCB02800-977F-4914-B35A-BA93499FB878@lrw.com>
Date: Thu, 19 Dec 2013 08:08:08 -0500
To: ianG <iang@iang.org>
Cc: John Kelsey <crypto.jmk@gmail.com>, cryptography@metzdowd.com,
Theodore Ts'o <tytso@mit.edu>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Dec 19, 2013, at 7:42 AM, I wrote:
> If you don't like the idea of mixing RDRAND into the pool rather than XOR'ing it at the end....
It's worth noting that treating RDRAND specially is not without justification. RDRAND produces 64 (allegedly good) random bits at a shot, at a very high data rate. Other sources that feed the mixing algorithm produce a few bits here and there, which have to be mixed and distilled over a period of time.
- If you count the 64 bits as 64 bits of entropy, RDRAND will swamp all the other sources. If RDRAND is spiked, it could spike the output of the mixer.
- If you count the 64 bits as no entropy, or only a little entropy, and RDRAND is actually good *but the Linux mixer or its other sources are bad*, then the mixer will effectively throw away the value RDRAND could have give you.
Linux mixer XOR RDRAND is strong if *either* of the two inputs is strong (modulo the active attacks we've been discussing, and which can be neutralized). You can't get that guarantee by making RDRAND "just another input" - it reduces you to relying on the strength of the Linux mixer.
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
