[148521] in cryptography@c2.net mail archive
Re: [Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Thu Dec 19 11:28:38 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <52B152D9.1080507@iang.org>
Date: Thu, 19 Dec 2013 07:42:30 -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 18, 2013, at 2:46 AM, ianG wrote:
>> Ultimately, if you need to live at that level of paranoia, you'll need
>> to build your own CPU out of TTL logic chips --- something which I
>> learned how to do when I was a freshman at MIT. It won't be a
>> terribly fast computer, though....
>
>
> No such is necessary. Just don't elevate RDRAND to a superior position as a post-RNG XOR phase. Be happy with it as a collector.
>
> Just get rid of these lines:
>
>
> for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
> unsigned long v;
> // arch_get_random is RDRAND.
> if (!arch_get_random_long(&v))
> break;
> hash.l[i] ^= v;
> }
I don't believe the proposed attacks are plausible. On the other hand, making them much, much harder - to the point where they are clearly far harder than any number of other attacks - is so simple, and has such low costs, I can see no reason *not* to do them.
If you don't like the idea of mixing RDRAND into the pool rather than XOR'ing it at the end, an easy fix is to move the RDRAND instruction to any point before the value that the existing RNG will output has been computed, save the value in memory, then read it and XOR it in at the end. This will produce exactly the output you are getting today, at the additional cost of one memory read and write, but puts a spiked RDRAND implementation in the position where it cannot determine what value its output will be combined with. (Well, if you believe the "spike" can extend to keeping track of the memory location where the RDRAND value went and later modifying what a memory->register transfer or an XOR does based on a recent read of that location ... what can I say.)
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
