Question: I was recently discussing the issue of RDRAND in Intel chips and the whole issue about how NSA could potentially be influencing Intel to weaken or create backdoors in their design. 

This [petition](https://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4) was posted asking Linus Torvalds to ignore RDRAND and not include it as a source of entropy in `/dev/random/`. You can see Linus' response [here](https://www.change.org/en-GB/petitions/linus-torvalds-remove-rdrand-from-dev-random-4/responses/9066). 

My main question is, would using RDRAND as one source of entropy (amongst many others) potentially compromise the 'randomness' of `/dev/random` by adding some predictability? Or is he correct in saying that It really does not make any difference as long as its not the only thing entropy is generated from?

Answer: 
I don't think that rigging the xor instruction and possibly others would be as hard as lxgr suggests.

What I would do if I were the hardware designer:

* add an extra bit to the output register of RDRAND. This bit means something like "unobserved". Until the user "opens the box" there could be anything in the register. (Think Schrodinger's Cat :-))
* update XOR, ADD, possibly other instructions to check if the value is observed. If not, change it as needed.

The cost of this solution would be around 30 extra transistors in a billion transistor chip.

If using the RDRAND output, it might be a good idea to move the output around a bit and do some computations so "it's wave function will collapse", and then using it
The way in which RDRAND's output is mixed into the /dev/random output buffers 

```
    linux drivers/char/random.c, extract_buf()

    /* ... compute a hash.l[i] PRNG ... */
    /*
     * If we have a architectural hardware random number
     * generator, mix that in, too.
     */
    for (i = 0; i < LONGS(EXTRACT_SIZE); i++) {
            unsigned long v;
            if (!arch_get_random_long(&v))
                    break;
            hash.l[i] ^= v;
    }
    /* ... pass hash.l to userspace ... */

```

seems vulnerable to microcode-based tricks to suppress the XOR mixing, and instead substitute vulnerable data. We'd never know it's there, because microcode is closed-source and updated whenever Intel likes.

Update: see also <http://www.metzdowd.com/pipermail/cryptography/2013-December/019065.html>