What is the origin of side-channel attacks? Is it related to the algorithm or to the implementation? In other words, is the software responsible for the attack or the hardware?

Is there a cryptographic algorithm that is resistant to side-channel attacks on system A, but is not on System B?

Can we call algorithms side-channel resistant?

5 Answers 5


Side Channel attacks leverage information gained from observing or interacting with a system in a way other than anticipated by its creators. Often this is done to infer information about encryption keys or other secret information.

Some of the most common side channel attack vectors are:

  1. Timing
  2. Power monitoring
  3. Error handling analysis

Examples for the mentioned include:

  1. AES cache timing attack to determine encryption keys (very good paper by DJ Bernstein)
  2. Differential power analysis against DES to determine encryption keys (famous paper by P Kocher)
  3. RFID passports' error handling is exploited to infer nationality -> privacy breach (link)

While Wikipedia states that:

... a side-channel attack is any attack based on information gained from the physical implementation of a cryptosystem ...

I would argue (along with Bernstein and others) that side channel weaknesses may also emerge from design. In the AES example this is due to the fact that it is pretty much infeasible to write constant-time performing code for general computing while maintaining efficiency.

So to come back to your question; while you exploit a side channel attack in an implemented system, the root cause for its existence cannot generally be attributed to implementation only. You will have to look at a specific system and its implementations, and you may find that the answer to the question depends largely on where you place the boundary between design and implementation.

(If the design of AES had guaranteed static computing times, the timing attack would not have been feasible on any correct implementation as an example...)

You may, however, have differing implementations of AES which are or are not vulnerable to a timing attack, to answer your question about systems A & B (System A may enforce static computing times while B does not).

With a well-defined attacker model I would say that you could define a side channel resistant algorithm. Please clarify that question tough - not sure I understood you fully..

Edit: Some more fun and interesting reading in this brief and easily readable article. :)

  • So.. I'm not an expert in this area, so I'm unsure of the context of where this vulnerability exists... Can someone use a timing or differential power analysis attack on any web server to discover the SSL key? Feb 10, 2015 at 17:34
  • @CuriousWebDeveloper that's an important question you are asking! Side channels very much depend on both the system setup and the attacker. Although it may be possible to perform a differential power analysis attack e.g. say on a TPM which holds a server's private keys, a standard attacker would not be able to exploit this over the Web due to the physical presence requirement. Mitigations therefore often try to deny access to side channel information (e.g. casing, em-shielding, etc.) rather than eliminating any kind of leakage. As so often in security, all depends on your attacker model...
    – Karl Hardr
    Feb 10, 2015 at 18:09

The term "side-channel" may refer to two different things: one is hinted by the other answers (accidental details of implementation which leak out via non-deliberate data stream). The term may also refer to a potentially-deliberate inclusion of cryptographic secrets within what should be random parts of a data stream. For example, a program which is supposed to pad a small secret (e.g. an AES key) with random data and RSA encrypt it might if maliciously designed, change the implementation slightly:

  Pad secret with random data
  Encrypt it
  Interpret bits 151..181 of the resulting crypto stream as a number I
  Examine bit (I mod RSA_keylength) of the RSA secret key
  If the aforementioned bit doesn't match bit 504 of the crypto stream, goto Loop

If this evil implementation is used to exchange very many secrets, an attacker will be able to find out most of the bits of the RSA secret key entirely through easy passive observation. Someone who didn't know about the hidden side channel, however, would notice nothing unusual about the messages. Indeed, even someone who did know about the side channel would be unable to tell whether any particular message included it. Only by examining many messages would the side channel be detectable even for someone who knew what to look for.


Side channel attack is definitely due to the implementation (clarification, I do not mean that the implementation is wrong, see below).

They originate from the fact that a mathematical computation needs a computer to process things. So to speak, the side channel information of an encryption process is the impact of the physical activities that are deployed to compute it. They are a consequence of the physical world.

To be resistant to side-channel attacks you have to :

  • reduce the amount of data leaked
  • make the leaked data unrelated to the secret data

And this can be do both by hardware and software. Eventually, all relates to the physical particularity of the system used.

Example: measuring the power consumption during key generation.

The excess power needed to process a 1 (instead of a 0) is a side-effect of the tools used to do the calculations. Like if I'd use an EEG to see if you're thinking of a 1 or a 0. They are problem that aren't coming from the algorithm design, but by the reality.

  • 1
    Aren't side channels based upon communications, where the existence of a main channel is the primary mode of communication, but side bands / side channels are side effects that come about from the main communication channel itself? There are occurences of the use of channels to describe protocol communication in the 1985 rfc on ftp, whose original main control channel was a telnet session.
    – munchkin
    Feb 10, 2015 at 12:28
  • I'm not sure that I agree that side channel attacks are the result of a bad implementation considering physical measurements are needed. It's not AES's fault that you might be able to observe 16 rounds. A bad implementation might stand out more, but that would probably point out the weakness in the implementation.
    – RoraΖ
    Feb 10, 2015 at 12:28
  • Well, I might have been unclear. I not saying that it's the result of a bad implementation (that's why I used quotes in the first place). It's really a consequence of the implementation itself. If we could do the coding with no implementation, there would not be side-channel.
    – M'vy
    Feb 10, 2015 at 13:11

Side channel attacks are those based on exploiting certain aspects of the implementation and not due to mathematical weaknesses in the cryptographic algorithms.

Some are exposed due to hardware implementation choices. For example, a CPU may draw more power at a certain point in execution in the case where bit 1 of the key is true, and less power when bit 1 of the key is false.

Others may be exposed due to timing choices that occur in the software implementation of the cryptographic algorithm. There was a successful attack on the Bouncy Castle implementation of TLS because a MAC algorithm's implementation took a faster path through the code in the case when a certain bit was set to a certain value. (I think this was the root cause of CVE-2013-1624.)

In many cases, especially those due to timing, one common way to address a side channel attack is by changing the software implementation. By ensuring all branches take a constant amount of time regardless of the value of the bits, such information leakage can be prevented. In a high-level language implementation, compiler optimizations can be an unwitting cause of leakage, which is yet another reason that a "roll-your-own" approach to cryptography can be a problem.


Like i pointed out, side channel/side bands are side effects that arise from the main carrier band/implementation. The term originates from radio transmissions & communications, and so without trying to attack the problem head on by dealing with the main implementation, you analyse side channels instead to gain insight into the problem.

It's kind of like how you can track power consumption to determine whether the extra round of decryption means your brute force password tries are working.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .