It might not be clear from the title without context that the setting for this attack is a local cache-timing attack, which can work cross-VM on the same physical hardware. So if you have an attacker running code on your physical machine, but not necessarily in the same process, account, or VM, you would be vulnerable to private key recovery.
Although the researchers describe mitigations that will dramatically reduce the information leakage, this is further evidence that it's quite dangerous to do software crypto on hardware that may be shared with an adversary.
In addition to stress testing (for cooling/overheating and functional testing), we use MemTest86 v7 Free Edition (which does row hammer tests too) on all new computers: desktops, laptops and servers.
The advice is clearly good. Given the context, it sounds like something that someone at a VPS provider might say, which was what made me curious. In any case, it's relatively rare in my experience here to run across the first-person plural without any antecedent at all, be it ever so vague - which also struck me as curious.
I'm not looking to either discount or treat as axiomatic anyone's arguments based on their apparent position along some authority gradient, if that's what you are getting at. What would be the point?
Thanks heaps for the scope summary. I really do wish papers with such 'scary' titles would clearly indicate how regular users of the software are affected currently and how the security guarantees have been violated for them in the past and under what circumstances. Ideally they'd also say exactly what to do to remedy the problem, at least from the perspective of a user of say libgcrypt/GPG. Doing that would prevent a large amount of needless panic and scrambling.
The people who are in position to fix the issue can extract that information easily from this paper; the paper is targeted towards this audience and academics, not the general populace
Aren't they expressly focused on 1024 but keys? It sounds like 2048 doesn't share the same issue yet.
Wouldn't your statement imply that we should not be terminating TLS on AWS nodes? Is it even practical these days to not use cloud based, shared hardware?
Again, RSA 1024, we've known that's weak for a while now...
Is there a cheap alternative? I know there are a few vendors selling secure hardware USBs (though how secure I don't know) for various uses, but are there any SoCs to run arbitrary sensitive code without hardware sharing?
The details aren't completely spelled out here but SGX looks to be an interesting extension of the idea of "virtual machine per block of code"
https://software.intel.com/en-us/sgx
It appears a runtime per-site-per-use license is required though.
The latest SDM strongly suggests that some future CPU will change this. Also, certain Linux x86 developers think that SGX support is vastly more likely to be acceptable upstream if this changes :)
They give a partial answer aka right-to-left vs. left-to-right, but at the high level.
Make sure you do fixed computation regardless of data involved. This involves slowing things down and making sure the CPU/compiler does not optimize anything so things become unbalanced.
I am new about these things, but wouldn't just moving to fixed computation really fix this and a large number of forsee-able side-channel attacks? It sounds like the libgcrypt devs chose specifically not to do this because they thought it wasn't necessary.
Okay, I saw that, but thanks for saying it. What does right to left mean specifically? How would you compute it without a sliding window / or make it fixed time?
Straightforward implementation involves taking exponent bits from the MSB on and multiplicating by the base for 1 bits and then squaring the intermediate result.
Straightforward way to make this constant time is to do the multiplication always and discard the result for 0 bits.
Motivation of the sliding window algoritms is that they are faster and also believed to be "more constant time" than the straightforward square and multiply.
Dear moderators: Can you adjust the title? I misunderstood it, as I think many others will, as defeating all RSA-1024 by all GPG users done on any computer. It's actually about people who share a computer with someone doing a GPG decryption.
The paper's title is: "Sliding right into disaster: Left-to-right sliding windows leak". Standard HN practice is to use the page's title as the post title.
Alternative options that seem clear to me:
- "Local-machine side channel attack defeats RSA-1024 decryption using GPG (CVE-2017-7526)"
- "Complete break of RSA-1024 in GPG (CVE-2017-7526) for local attackers"
- "Sliding right into disaster: Left-to-right sliding window attack against local-machine RSA-1024 in GPG (CVE-2017-7526)"
I was an expecting an article about waterproofing differences between windows that open to the left and those that open to the right. Forgot this was HN.
Although the researchers describe mitigations that will dramatically reduce the information leakage, this is further evidence that it's quite dangerous to do software crypto on hardware that may be shared with an adversary.