1

Let's say you're using a library that you know is vulnerable to timing attacks. Short of switching libraries all together it seems to me that putting a sleep in the code for a random number of microseconds (or seconds or whatever) would be sufficient to obscure the time it took?

Like why do RSA blinding when you can just sleep for a random number of seconds before or after the RSA decrypting code is ran?

neubert
  • 2,927
  • 1
  • 28
  • 54
  • 1
    A sleep will trigger a system call, which will trigger a context switch. A timing attack will be able to easily tell when an application has performed a context switch (and it's actually visible explicitly in /proc, at least on Linux) and ignore it. Not to mention, most side-channel attacks will abuse the cache, and a simple sleep will not use the cache in the same way that actual computation will. – forest Sep 26 '18 at 22:46
  • @forest - It seems like a lot of languages - node.js, Python, PHP, etc - don't provide a low enough level API to protect against cache timing attacks so idk that cache timing attacks for those languages is a big deal? And if not a random sleep what about a for loop with a random end or start? – neubert Sep 27 '18 at 00:51
  • 1
    I believe those higher-level languages will be written with their cryptographic routines designed to be side-channel resistant, or at least they should be. As for using a for loop, that won't put the same kind of pressure on the L1d cache, so it would still be possible to tell that a loop is occurring. – forest Sep 27 '18 at 00:52

1 Answers1

1

Let's talk with an example, RSA modular exponentiation where the timing of square $T_s \approx x$ and square and multiply is $T_{sm} \approx 2x$. Assume that we have $n$ operation that can be square or square and multiply.

Here we assume that the attacker knows everything about the random sleep;

  • Let the random values named $y_i; \; 1 \leq i \leq n$. If the $y_i < x$, then the timing attack will work. So, first rule; $ \text{upper bound of } y_i > x$.

  • Let $ 0 \leq y_i \leq 2x$. Clearly, any timing value greater then $3x$ is a square and multiply. If the attacker, capture the timings for the same key more than once, due to the randomization, it will reveal more square and multiply.

  • Let $ 0 \leq y_i \leq (t \gg x)$. Here the randomization much bigger than $x$. It does not much differ from the previous, same idea. Only the attacker will need to capture more timings.

The result, direct randomization doesn't help.

If needed, one can talk about the required timing captures with probability.

What about an interesting one; that is adding a random wait according to average timings.

  • Let $ x \leq R_s < 2x $ be random delay for square and $ 0 \leq R_{sm} < x $ be random delay for square and multiply. So the randomized timings are $ 2x \leq R_s + T_s \leq 3x$ and $2x \leq R_{sm} + T_{sm} \leq 3x$

This method prevents the attacker from distinguishing the timings.

Update: Actually, The last method may fail,too, since the random delay won't use any cpu at all ( There is an issue about C++ delay it is not supporting microseconds, POSIX does.).

kelalaka
  • 48,443
  • 11
  • 116
  • 196