The paper is interesting (they used an artificial neural network to filter the measurements), but the results aren't ultra-surprising; I think everyone expects more side channels to be discovered on x86 hardware in the coming years, especially since much of the microarchitecture is undocumented. (Note: this paper targets a very old processor, which probably improved their results).
The biggest issue with this branch of side channel study --- an issue not mentioned in the paper --- is that "getting on the same machine as an encryption process" is much less hard than it sounds in 2010: many encryption processes run on VMs inside hosting providers, where the cost of situating an attacker on the same metal as the target might be as low as $20.
But, long story short: this isn't the crypto attack you should be most worried about. My understanding is that OpenSSL has pushed back on fixing much more straightforward timing channels than this. There are remote attacks that are still worth attention.
Still, the speed with which this attack runs is impressive.
One concrete mitigation strategy has been realized in
OpenSSL 1.0 . There, only the substitution table S is
stored, and then the required multiplications within GF (28)
are computed by using the following relations, which can
be realized in a highly efﬁcient way using the PCMPGTB
| +- |
| | ff (int8_t) x > 0 |
2•x = (x << 1) ⊕ | 1b ∧ -+ |
| | 0 (int8_t) x ≤ 0 |
| +- |
= (x << 1) ⊕ (1b ∧ PCMPGTB(x, 0))
3•x = 2 • x ⊕ x
1) This is legit?
2) This can work in the real-world and not just in some very specific lab conditions?
Also this article title is slightly mis-leading, but not entirely.
In 2004, Adi Shamir and Eran Tromer demonstrated that it may be possible to conduct timing attacks against a CPU performing cryptographic operations by analysis of variations in its humming noise (that is, its high-frequency humming noise, not the louder low-frequency humming of its cooling fan).
Of course, electron microscopes and precisely-aimed laser pulses are more... geeky.
My experience has been that cryptographic systems fail in two ways:
1. Side channel attacks.
2. Key management attacks.
There is a whole conference (called CHES) which talks about ways to build/verify crypto hardware that will withstand side channel attacks and prevent the loss of keying material stored in a hardware device. It's a hard problem to get right and a lot of very paranoid people work very hard to anticipate how bad they might be at building a working cryptographic system.
The stuff that breaks most cryptosystems is much more basic than "side channels" and "key management". It's using ECB mode, encrypting without a MAC, inventing your own SHA1 MAC, leaking errors, colliding IVs or nonces, failure modes that collide session keys, not checking parameters; I could go on and on.
I'd hate for people to think that side channels is the thing they have to be on the lookout for. Writing their own crypto constructions is what they need to be on the lookout for.
I guess my point was that most of the cryptosystems /I've/ used over the years have seen significant vulnerabilities exposed in key management and side channel attacks. Insufficient entropy for key generation is another one. That said, I probably benefit from people like you weeding out the REALLY bad implementations.
I do agree that you're likely to see a lot of extraordinarily poorly designed cryptosystems if you regularly look at work product from people who are unfamiliar with attack methodologies in general.
Anyway, the findings are spectacular because most other attacks use time-memory trade-off brute-force methods.