Researchers crack the world’s toughest encryption | Hacker News Reader

Researchers crack the world’s toughest encryption

extremetech.com

52 pointsAurel1us19 comments

Can 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?

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.

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.

Previous discussion on HN (270 points | 89 comments)

(Notably about why playing music does not mitigate the threat.)

https://news.ycombinator.com/item?id=6927905

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.

Unless you're standing next to a live orchestra that's playing the concerto on specially designed dog-whistles, you're going to have a pretty hard time masking anything near the 150 kHz range.

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.

Reply on news.ycombinator.com