# Mitigating timing attacks with a random sleep

Could you mitigate all timing attacks by putting a sleep(random()) with a naive crypto implementation? Eg if your implementation looks solid, but you're not sure what the next CPU cache vulnerability is around the corner, would this be a legitimate mitigation strategy?

To clarify, this would be a random delay measured from before the algorithm starts, so that you're not simply adding fuzz to the runtime.

• I think you need to put some limits on your random, otherwise, your code will be too much slower. If there is a limit, It isn't much help. For your clarify, some timing attacks are performed on subroutines like powers of RSA modulus. – kelalaka Feb 13 at 6:13

First, let's define what is usually meant when someone talk about "random delay" (correct me if I miss-understood what you actually meant). If you want to efficiently hide the real time execution of your function, you want to add $$x$$ seconds where $$x$$ is close to the average execution time (otherwise it will be easily noticeable). The way you stated your question, I will also assumed your $$random$$ function is uniform, i.e. all value have the same probability of being drawn.

With this setting, adding random delay will only slow down the attack since the average distributions will still be distinguishable. However, an attacker may need to collect more sample to be able to cancel the noise you introduced.

I invite you to take a look at this presentation (slides available here) which gives a well illustrated description of the problem, and go further to explore different countermeasure based on delay.

Considering an attacker able to probe your cache (namely for instruction), he would be able to determine when the real function was called, and when the sleep function was called, making this countermeasure useless.

In general, to avoid such vulnerabilities, it is recommended to make sure your code doesn't have any secret-dependent branch and memory access. A simple delay wouldn't do much, even if you use it to smooth the overall time execution (which may be quite tricky to do since as Yehuda Lindell said, the time would be platform dependent).

N.B.: If you want to consider CPU-cache vulnerabilities, you need much more than simple delay. Namely, you need to avoid secret-dependent branch and memory access.

• Hi, firstly thanks for your answer. If my random delay starts from before the algorithm starts, rather than from the end of the algorithm, would that solve the problem of the average distributions still being distinguishable? – Chris Feb 14 at 6:01
• @Chris Wherever you put your delay would not change the fact that gathering enough session trace would allow an attacker to recover the underlying time distribution (i.e. exploit a timing attack if there is a leak). – Faulst Feb 14 at 8:06
• I'm not sure i'm being clear enough. I'm suggesting that the random delay should subtract however long the algorithm took to run, so that the distribution wouldn't reflect the algorithm time. Eg running the delay on a separate thread to the AES algo. – Chris Feb 14 at 22:43
• I misunderstood the details of what you wanted to do, but considering cache attack it wouldn't be an effective countermeasure anyway (I edited the second part of my answer accordingly). – Faulst Feb 15 at 14:23

Adding random sleep may make it slightly harder, but not more than that. The problem with adding random noise is that the average time will still be different between the two measurements you are trying to make. So, you will need more measurements, but eventually will get the right thing, since the averages will stand out. This is how timing attacks can be done over the Internet (see Remote Timing Attacks are Practical), even though there is timing noise in networks.

• What about trying to to add a sleep so that the total time is close to the same value (a predefined constant)? – shumy Feb 13 at 11:17
• You cannot predict the time of difference since each platform is different. – Yehuda Lindell Feb 13 at 13:40
• Hi, firstly thanks for your answer. If my random delay starts from before the algorithm starts, rather than from the end of the algorithm, would that solve the problem of the average distributions still being distinguishable? (this is my same comment as per the other answer). – Chris Feb 14 at 6:02