Researchers crack the world’s toughest encryption

Researchers crack the world’s toughest encryption(extremetech.com)

52 points by Aurel1us 12 years ago | 19 comments

tobiasu 12 years ago |

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.

rb2e 12 years ago |

Research paper is here: http://www.tau.ac.il/~tromer/papers/acoustic-20131218.pdf

Edited to add: This is one hell of a hack.

kken 12 years ago |

Meh, sensationalist title.

Already commented on the first submission: https://news.ycombinator.com/item?id=6933678

onion2k 12 years ago |

Being hugely pedantic, the "world's toughest encryption" is a one-time pad, and they didn't crack that.

eterm 12 years ago | |

Would the same method not work against a one-time pad?

onion2k 12 years ago | | |

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.

upofadown 12 years ago | | |

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.

nmc 12 years ago |

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

exo762 12 years ago |

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.

JoeAltmaier 12 years ago | |

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.

dazam 12 years ago |

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.

gfodor 12 years ago |

these people, to me, are indistinguishable from wizards.

drblast 12 years ago |

  >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.

andr 12 years ago |

Perhaps this can be thwarted by adding randomization to algorithm implementations so calculations are performed in different order every time.

ReidZB 12 years ago | |

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

Tepix 12 years ago |

So, would running something else on the same CPU (getting the load to 100%) mitigate this issue?

ozh 12 years ago |

TL;DR: Paranoid? Turn on Metallica up to eleven when decrypting data

lucb1e 12 years ago |

s/crack/bypassed/

venomsnake 12 years ago | |

They didn't bypassed it either. They just found a sidechannel that was leaking the key.