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