A very interesting Debian security advisory was released yesterday.

Genkin, Shamir and Tromer discovered that RSA key material could be extracted by using the sound generated by the computer during the decryption of some chosen ciphertexts.

How does this attack work? What are some possible mitigations?

  • 1
    Abstract here: nakedsecurity.sophos.com/2013/12/19/the-sound-made-by-your-computer-could-give-away-your-encryption-keys/
    – user13695
    Dec 19, 2013 at 12:18
  • Well, I guess that you might be right. My question is a bit broader though.
    – d33tah
    Jan 21, 2014 at 15:24
  • Somewhat late, but there’s also a related Q&A at Crypto.SE.
    – e-sushi
    Aug 7, 2014 at 13:36
  • hello, sorry to ask you as a comment here, what CMS did you use for your nice website ?
    – user45139
    Apr 3, 2015 at 8:03

2 Answers 2


The practical impact is nil... for now. The attack is of a type known as side channel in that it exploits an information leak, here sound emission which depends on the processed data, including the private key. Under certain conditions, the leak might be leveraged into a full key recovery, but the conditions are not easily achieved in practice. As the authors say:

To apply the attack to GnuPG, we found a way to cause GnuPG to automatically decrypt ciphertexts chosen by the attacker. The idea is to use encrypted e-mail messages following the OpenPGP and PGP/MIME protocols. For example, Enigmail (a popular plugin to the Thunderbird e-mail client) automatically decrypts incoming e-mail (for notification purposes) using GnuPG. An attacker can e-mail suitably-crafted messages to the victims, wait until they reach the target computer, and observe the acoustic signature of their decryption (as shown above), thereby closing the adaptive attack loop.

In other words it takes a rather specific context for the attack to do real damage, and it won't be discreet.

Protection against leaks is done by altering the software so that leakage no longer occurs, or, more accurately, no longer yields usable information. In the case of RSA, for modulus n, public exponent e and private exponent d, blinding is effective:

  • Before using the private key on input m, generate a random r modulo n.
  • Compute m' = m*re mod n.
  • Apply the core exponentiation on m', yielding t' (t' = m'd mod n).
  • Compute t = t'/r mod n. This value t is the actual result: t = md mod n.

Why blinding is effective against most side-channel leaks in RSA is a matter of subtlety; but, in a hand-waving way, let's say that the added randomness of the r value (called the "mask") hides the data by preventing the attacker from modelling it: the attacker no longer knows what enters the exponentiation. It is important that a new mask r is generated for each exponentiation (to some extent, there can be shortcuts to produce sequences of masks at a lower cost, but that's tricky and usually not worth the effort). The overhead implied by blinding remains small, because the public exponent e is small.

Blinding is not the only counter-measure; to avoid leaks, one should also take care to keep the sequence of operations as fixed as possible, regardless of the data (e.g. in a classical square-and-multiply exponentiation algorithm, don't multiply conditionally; instead, always multiply, but conditionally keep the result or discard it).

  • Are these blinding techniques already implemented and used in common versions of RSA, such as GPG keys and SSH keys? Apr 30, 2014 at 17:09
  • The RSA blinding technique I describe has been implemented in usual libraries since Timing Attacks were first described against RSA, back in 1996 or 1997. The interesting point here is that the side-channel attack we are talking about here is not impeded by the specific RSA blinding that I describe above (it seems my writing may have been a bit misleading on that point) -- but other similar techniques would work, and I suspect they will soon be implemented as well. Apr 30, 2014 at 17:17

This attack is a form of side-channel attack against RSA. The full details can be found in a paper published by Adi Shamir (one of three authors) of RSA fame.

The attack essentially works because a computer emits different sounds when performing different tasks. Using this information, it is possible to recover information about the RSA key during the process of encryption or decryption. When the same plaintext is encrypted with different RSA keys, the researchers were able to discern which key was used in the encryption process. This is a form of key distinguishing attack.

The interesting part about this is that the researchers were able to pull off the attack using mobile phones. This is troubling because this attack does not require specialized equipment to pull off.

While this attack is strictly theoretical at the moment, it is still interesting as side-channel attacks have been responsible for many of the attacks against RSA in the past.


Like the Debian advisory mentions, this attack is fixed in the newer versions of GPG.

For the oldstable distribution (squeeze), this problem has been fixed in version 1.4.10-4+squeeze4.

For the stable distribution (wheezy), this problem has been fixed in version 1.4.12-7+deb7u3.

For the unstable distribution (sid), this problem has been fixed in version 1.4.15-2.

Better yet, use the GPG 2.x branch which already employs RSA blinding that should protect against side-channel attacks.

  • What is new about this attack? Sound side channels have been known and demonstrated on PCs for a long time. Is the novelty that they could obtain results with a mobile phone rather than higher-quality equipment? Dec 19, 2013 at 12:38
  • What's new is that under idealistic conditions RSA's original developers could break the encryption, instead of just the theoretical possibility. Researchers still debate its applications in real life scenarios where atmospheric noise should render the side-channel ineffective. Dec 19, 2013 at 12:41
  • @Gilles What Rohan said. The paper is actually an improvement on a previous paper. cs.tau.ac.il/~tromer/papers/tromer-phd.pdf
    – user10211
    Dec 19, 2013 at 12:43
  • 1
    In regards to the recent duplicate, I'd like to add for future reference that this vector is not useful to manufacturers themselves as it would be much easier to hardcode malware into processing units than using this to break one specific type of encryption if the implementation matches (and the application is a non-updated legacy one). Dec 22, 2013 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy