Edit: And BTW, yet one more argument for NaCl or libsodium, which boasts "no data-dependent branches."
I am still not entirely clear on how they are able to extract the key (does the victim computer need to process the provided encrypted payload? So if the victim never does that, they can't steal the key?), but it's still a fascinating read.
if ( password = "hunter2" ):
Attacks like the author are performing are a lot more complicated and use tricks like coercing the victim into signing distinctive plaintexts, but the example also works for more complex systems like ECDSA where people can derive the signing key by just knowing how long it took.
Instead of going to the effort of making the function run in a constant time, might adding a small random delay before it returns also mitigate against this type of attack?
Noise technically mitigates, but it's like covering your unlocked safe with a cardboard box.
That being the case, there are a lot of systems where that is easy to achieve. If you have GPG in your mail client, it will decrypt anything anybody sends you.
Another thing to keep in mind is that attacks always get better, they never get worse. So today's chosen ciphertext attack is tomorrow's zero-knowledge attack.
In general, it is like many other side channel attacks, where you can use the data to put constraints on the search space for a brute force attack.
"[...] If you are using a GnuPG version with a Libgcrypt version < 1.6.0, it is possible to mount the described side-channel attack on Elgamal encryption subkeys. [...]"
"We have disclosed our attack to GnuPG developers under CVE-2014-3591, suggested suitable countermeasures, and worked with the developers to test them. GnuPG 1.4.19 and Libgcrypt 1.6.3 (which underlies GnuPG 2.x), containing these countermeasures and resistant to the key-extraction attack described here, were released concurrently with the first public posting of these results."
Basically that Libcrypt 1.6.3 underlies GnuPG 2.x. But when I check my system:
foo@bar:~$ gpg2 --version
gpg (GnuPG) 2.0.22
So I'm wondering why GnuPG 2.0.22 isn't using Libgcrypt 1.6.x?
I can see from your reference that I can upgrade to Libgcrypt 1.6.x but that it requires a rebuild of GnuPG, which I'd rather not deal with right now.
Also: do LCD monitor leak so that someone can recreate the image on them some distance away?
http://www.hack247.co.uk/blogpost/van-eck-phreaking/ (unscientific/not peer-reviewed)
List of certified companies
CIS Secure Computing TEMPEST gear
Advanced Programs Inc TEMPEST gear
My guess is probably not at all. Because I've never seen the option in a notebook computer, and as the purpose is to pass emissions regulation, I assume it was enabled in the machines they tested. And that the difference in the emitted frequencies of various operations is much greater than any variation of the base clock.
Lasers have been used for 50+ years in the intelligence community to eavesdrop on voice conversations.
And yes, electromagnetic fields interact.
Can anyone confirm that?
As for smartcards there is no reason to assume they would do anything to mitigate this.
I guess another way of seeing it is that a Macbook is a large chunk of antenna which would be quite bad.
Now if you'll excuse me, I'm going to crawl into a ball and cry away the FCC testing tears.