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: 
Yes, it can: see [http://people.umass.edu/gbecker/BeckerChes13.pdf [archived]](http://web.archive.org/web/20131016063744/http://people.umass.edu/gbecker/BeckerChes13.pdf) for how to backdoor the bare metal without it being detectable by optical microscopes.

On the other hand, adding Intel RDRAND output into a pool where it’s not the only entropy source is usually safe (always safe if it cannot dominate the output). That’s what is being discussed for Linux at the moment.

As a user-space application you should *never* use RDRAND directly, at least not without mixing it e.g. with a output from a stream cipher seeded from `/dev/urandom` or something like that.
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>