Researchers crack the world’s toughest encryption
extremetech.comCan extremetech please be added to the list of websites blocked by default on HN.
There is never any original content from that site, it's always rehashed crap, littered with buzzwords and reeking of the dead corpse of journalistic integrity.
Research paper is here: http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
Edited to add: This is one hell of a hack.
Meh, sensationalist title.
Already commented on the first submission: https://news.ycombinator.com/item?id=6933678
Being hugely pedantic, the "world's toughest encryption" is a one-time pad, and they didn't crack that.
Would the same method not work against a one-time pad?
I was pointing out that they didn't, not that they couldn't. But I don't believe they could anyway. Deciphering a OTP is absolutely trivial if you have the key. You're just doing modular addition, and that's something computers do a great deal of during the course of running stuff. Even assuming a reasonably long ciphertext of 500 characters, that'd take only 1000 operations (an add and a mod 10) - any modern CPU could do that in fractions of a millisecond. The deciphering operation wouldn't even register above idling.
Additionally, there's the problem that there isn't a 'industry standard' OTP app, so there'd be no reference fingerprint to look for.
I would love to be proved wrong though. That'd be very cool.
Correct. The same method would not work against a one-time pad. The processor would do exactly the same operation for each and every byte of message and key. The power consumed would not change in any significant way.
Previous discussion on HN (270 points | 89 comments)
(Notably about why playing music does not mitigate the threat.)
There is a patch for that in GnuPG, available in both Debian and Ubuntu. Update your machines :)
FLOSS is amazing. One day since research paper and your machines are already patched. This means that probably no one had enough time to actually use this attack vector in the wild.
I wonder how the patch was vetted. And what it costs- more CPU time? Slower decryption by what factor? Or does it just defeat the current technique, requiring new measurements to pin down THIS code's characteristic sounds.
This is possible because of the electromagnetic signature generated by the processor's clock circuit while it is decrypting the data. The microphone is listening to the EM signal generated by the clock and timing the samples to reconstruct what the processor was doing. This type of attack is very difficult to carry out against a completely asynchronous or self-timed circuit that doesn't generate timed samples due to the lack of any central clock.
these people, to me, are indistinguishable from wizards.
>or you need to use a “sufficiently strong wide-band noise
>source.” Something like a swooping, large-orchestra
>classical concerto would probably do it.
Perhaps this can be thwarted by adding randomization to algorithm implementations so calculations are performed in different order every time.
I haven't had time to delve into the details of this attack, but I do want to note that adding randomization usually doesn't do much for security in these situations. Essentially, randomization usually just increases the number of samples needed for the attack, so it just ups the computational cost a bit. The same is true in timing attacks, for example, and I very strongly suspect that's the case here too.
The authors give some ideas for mitigation, however, in section 11 of their paper [1] (appropriately titled "Mitigation").
[1] http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf
So, would running something else on the same CPU (getting the load to 100%) mitigate this issue?
TL;DR: Paranoid? Turn on Metallica up to eleven when decrypting data
s/crack/bypassed/
They didn't bypassed it either. They just found a sidechannel that was leaking the key.