This doesn't preclude RdRand from being _worse_ however.

If your software— by design— eliminates side channels and isolates out timing. Then your hypothetical evil AES() would have a hard time screwing you over— it still might, somehow, but the window may be very narrow.

The only way to narrow the exposure from a bad rdrand is to never use it directly (e.g. without whitening via a CSPRNG with other truly random inputs).

This is a good point, but only if your attacker has access to cpu_state somehow. To do this, they would need to do one of the following:

1) Run code directly on the secure machine. Personally, I normally assume that if an attacker can run code, it's already Game Over. This includes running Java bytecodes and supplying data to media codecs, all of which can potentially be escalated to running code, and then further escalated to root.

2) Gain external access to cpu_state without running code, perhaps via a back-doored network card that colludes with the CPU. This would be pretty impressive, but it would also require some degree of network access. You can protect against this by sticking your whole computer behind a serial line and writing an extremely simple custom protocol in Go. This would make perfect sense for a credit card vault, for example.

3) Run a really exotic attack, such as the ones described in Reflections on Trusting Trust. For example, if the chip is willing to pattern-match on certain instruction sequences in the Linux kernel and replace them with compromised microcode, then we're in trouble. But if Intel ever got caught doing something this blatant, it would be a first-rate PR nightmare.

The nasty thing about a bugged hardware RNG is that it could silently compromise most of your encryption even if you had amazing perimeter security. And even if the attack were revealed, your chip vendor could claim it was just a dumb mistake.

No, this 1-3 list is not comprehensive; it ignores the entire literature on side channels and covert channels.

Have you read any of these papers? I respectfully guess that you haven't. You're in luck. Go read Boneh's "Remote Timing Attacks Are Practical", and Osvik & Tromer's local spy process paper.

My apologies for summarizing things a little too casually, and thank you for the excellent papers. I'm especially impressed by the cross-campus timing attack in Boneh.

My knowledge of convert channel attacks and timing attacks mostly dates to the 90s. Here's what little I know, for whatever it might be worth:

1. If your crypto primitives take variable time and your attacker can see that, you're hosed. Any encryption system with variable time encryption is useless unless you can somehow quantize it safely.

2. Eliminating covert channels is very nearly impossible. The literature on this goes way back, and it's ugly.

Should most users defend against these attacks? The timing attacks, yes. But I would assert that if a hardware encryption module appears to operate in constant time, most users should trust it. But as always, it depends on your threat model.

For something like a serious credit card vault, I still think your best bet is to get it off the network, build and audit a custom protocol that only passes a known set of messages, rate limit those messages, and quantize message timings. At that point, your biggest problems are bribery, insiders and physical security.

But if you do all that, I can't imagine why you would want to generate your encryption keys using somebody else's black-box hardware. Entropy pools are a good idea, even if you decide to trust your hardware AES implementation.

(And yes, I'm still oversimplifying. Hacker News is no substitute for a real threat analysis and security audit, nor for a conversation with whoever regulates or insures your business.)

One of the main threats that people have been worried about recently is global-scale passive attacks by the NSA. We know that they are gathering and retaining vast quantities of data; that they don't consider it illegal to simply gather and retain data without a warrant of any sort, and only actually look at it later once they have a warrant or have a 51% confidence that at least one of the parties in the communication is foreign.

For this threat, most active attacks are not particularly useful. They may capture encrypted data at a different point in transit than the one that originated it, making most side channel attacks difficult or impossible.

But a compromised RNG can be almost impossible to detect, and yet render almost any crypto system trivially breakable offline after the fact. The NSA has already once created a DRBG for which there could be a secret key that could determine the internal state of the generator with only 32 bytes of its output http://www.schneier.com/essay-198.html

I agree that being too wary of your hardware can lead you down a rabbit hole of paranoia, and that on the whole, we have much bigger problems to solve than hypothetical backdoored hardware random number generators (I have not seen any evidence that Intel has included a backdoor, merely people saying that because it's a black box we can't tell that they haven't). But since a good RNG is absolutely essential to so much crypto, and a compromised RNG would make it so easy for an adversary who passively monitors all communications and would like to have the option to decrypt them at their leave at a later date, I think that this is more worth worrying about than problems with the AES instructions.

They could try sneaking in a timing-based covert channel but surely that would be externally observable? The expected latency of those instructions is specified down to the last cycle, and since encryption is often performance-critical code people will be looking at their behaviour in detail.

Your argument is just smart-ass argument for the sake of argumentation.

Having CPU state that somehow leaks information past operating system is not realistic road for take. It would be known for thousands of Intel engineers.

Having tiny feature in chip that contains purposefully but not obviously vulnerable design that needs high level cryptographic knowledge to understand and compromises security is completely different matter.

EDIT comparing potential side channel attack to the possibility of weaken practically all ssl keys that use Intel chips is error in scale. Side channel attacks would work against specific targeted people. Weakening random numbers would work at the mass surveillance level.

This is a baffling comment given that researchers have alrady found multiple side channels in Intel CPUs that have created viable key leaking attacks. It's possible to have this problem merely by accident.

Such side channels can be avoided in a proper implementation by avoid things like table lookups and conditionals based on secret data.

Comparing potential side channel attack to the possibility to weakening practically all ssl keys that use Intel chips makes massive error in scale.

Side channel attacks would work against specific targeted people. Weakening random numbers would work at the mass surveillance level.