[jgrahamc]

All it has to do is detect the code sequence in question and XOR the output of RDRAND with the randomness from the other entropy sources before returning it.

How is that going to work? i.e. how is RDRAND going to 'detect the code sequence'?

[topynate]

RDRAND wouldn't, the control unit would. Whenever it sees the XOR macroinstruction it checks the second operand to see if it's RDRAND. If so, it doesn't order an XOR; rather it just copies the RDRAND value to the first operand address.

That's the straightforward way of doing it. The 'finesse' would be to leave RDRAND as a secure random source, but in the case of it being used as an operand of XOR, simply to ignore RDRAND entirely, substituting an insecure stream. The advantage, other than reduced risk of detection, would be that asynchronous access to RDRAND wouldn't scramble the otherwise breakable output.

[makomk]

Only Intel engineers know exactly how to do this and I doubt they're allowed to reveal hardware internals, but at the point RDRAND actually executes the next fewt instructions should have already been decoded and the data flow between them analyzed. In theory it's not terribly hard to use that information to change the behaviour of RDRAND.

[simias]

Honestly, and for lack of a more suitable expression, put up or shut up. If you think rdrand actually reads back the output of the RNG from RAM in order to nullify it, then show it.

It's actually possible, you can verify that the timing of the instruction conforms to what it's supposed to be doing, you can check for RAM access. RAM accesses are slow and easy to detect (I'm sure there even are hardware counters for that kind of thing on modern CPUs).

So unless you can get any kind of hard evidence that would even shed the base of the idea of a doubt about what rdrand is doing: this is pure FUD.

Finding out how rdrand is truly implemented is hard, but if it's truly the evil instruction of doom that sends images from your webcam to the NSA then it should be trivial to prove it's not behaving as it should.

[alfiejohn_]

Instead of saying put up or shut up, let's think if this is within the capabilities of Intel or an impossible feat.

First off, the RNG doesn't have to reside in RAM as it could already be in cache. So you're already not going to be detected by looking at RAM access. Also, it's not 1992. Modern architectures and modern operating systems are going to throw out instruction timings from Intel manuals. A cache miss and you're toast.

Now if you have a dedicated pipeline to executing a RNG within a code cache, all you would have to do is work out it's inverse. Very plausible.

Unless the above sounds magical, it does seem like this is a possibility. And as it's been shown that the NSA is using it's enormous budget to pay US companies to help do it's bidding, this does seem like it's within reach.

[alfiejohn_]

Aren't the next instructions going to be in the code cache? So "detecting the code sequence" would seem trivial.

[lambda]

Remember, this is a hardware implementation you're talking about. Nothing is ever "trivial". It would take a significant amount of extra silicon to add this kind of detection logic.

The reason for the basic paranoia about not trusting RdRand directly is that it's pretty easy and cheap to make it generate a random number stream that looks random, but is predictable (the RdRand function already is documented to use AES; all you would need to do is make it do AES of an incrementing integer sequence, rather than actual random noise, which is a pretty small change). And heck, if RdRand isn't backdoored (no one has presented evidence that is is; it's just a standard level of paranoia because subverting the random number generator is a favorite technique of the NSA), it might be in a future version, or AMD or ARMs implementation of a similar instruction in the future may be.

Detecting a code sequence and subverting it would be far more difficult. For one, there's the extra silicon. There's the extra chance of that change introducing other noticeable behaviors. There's the extra chance of discovery. It's just not worth the costs. And furthermore, if you really are worried about that, then there's no reason to limit your paranoia to the RdRand function; you may as well say you can't trust the chip to run any crypto code at all.

[alfiejohn_]

We can already rule out the extra silicon costs. Don't forget that a program like this one would be subsidised.

If you can't trust a chip with one instruction, why trust it with the others. I'm in no disagreement with you here. I was just responding to jgrahamc asking how it was going to work.