[Cryptography] Fwd: [IP] 'We cannot trust' Intel and Via's chip-based crypto, FreeBSD developers say

[Jerry Leichter]

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