4 ms·
I think that you have extrapolated the legitimate concern around hardware random number generators to AES-NI, where it is not a legitimate concern. With random
by CHY872 12y ago
I think that you have extrapolated the legitimate concern around hardware random number generators to AES-NI, where it is not a legitimate concern.
With random numbers, the point is that there's no good way to tell exactly how random something is, and it's quite easy to generate deterministic stuff that looks random.
Furthermore, by changing a couple of transistors, you can destroy the randomness of Intel's generator.
So, you can mix in Intel's random data as part of your entropy pool (because it can't hurt if done properly), but don't use it as a sole source.
The difference with AES-NI is that the spec it's supposed to implement is well known and deterministic. In particular, if it somehow encrypts something wrong, then anyone who tries to decrypt it without AES-NI wouldn't be able to do so.
Then there'd be a public outcry and Intel would have to recall millions and millions of processors (see Pentium floating point bug) with massive cost to them.
So, the only way it could be bad would be if the instructions could somehow leak data to other contexts or devices. This is possible, but is probably not how you'd perform such an attack, and if Intel did that knowingly, you've probably got bigger problems.
tl;dr - It's hard to trust random data and very easy to break Intel's hardware random number generator (couple of transistors), so don't give it importance above current methods because you have no way to verify that it's working as advertised. Not being able to trust AES-NI on the other hand would cost Intel billions and billions and billions.
Furthermore, AES-NI is in principle more secure than a software implementation; not vulnerable to cache timing attacks, software bugs etc.
- xenophonf 12y agoThat's actually very reassuring. Thanks!
- vilhelm_s 12y agoIncidentally, D.J. Bernstein argues that hashing an additional randomness source sometimes _can_ hurt: http://blog.cr.yp.to/20140205-entropy.html http://blog.cr.yp.to/20140205-entropy.html I guess it would be difficult in practice to make a malicious hardware randomness source, but it's an interesting perspective; to have confidence in your algorithm you should carefully restrict where the randomness enters it.
- wtallis 12y agoYeah, I've always found it odd how proponents of various entropy combining methods think it's reasonable to be afraid of hardware smart enough to know when to sabotage the RNG, but think it's unrealistic to postulate that it would also know the right way to poison their entropy pool.
- CHY872 12y agoThis sort of attack would be easy to defeat, though. For example, one fix would be to precompute a few megs of randomness data from your hardware source, and only use it after a few minutes have passed since generation. If the malicious RNG can predict the contents of the rest of the pool after this time (without modifying them) then there are bigger problems with the randomness generation.
- nightcracker 12y agoI disagree. The risk is not that the hardware encryption module like AES-NI encrypts _wrong_, at all. The risk is that it's possible to escrow the last N used AES-NI keys within the chip, and extract them using custom non-public microcode or physical access.
- CHY872 12y agoThat's fanciful. If your hardware is vulnerable to such an extent, you might as well keel over and give up on any security. For example, such hardware could reasonably be expected to occasionally scan main memory for crypto keys in the first place, or perhaps install an SSH server and a root user, or... Again, the reason why people care (or rather, should care) about RNGs is because it's theoretically very easy to tamper with them and very hard to then detect such tampering unless you're actively looking for it: http://arstechnica.com/security/2013/09/researchers-can-slip-an-undetectable-trojan-into-intels-ivy-bridge-cpus/ http://arstechnica.com/security/2013/09/researchers-can-slip...
- nightcracker 12y agoNo, scanning main memory is very obvious and easy to detect. A small one kilobyte of escrow is a lot more nefarious and harder to detect.
- deleted 12y ago[deleted]