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.

  • 1
    $\begingroup$ 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. $\endgroup$
    – kelalaka
    Feb 13, 2020 at 6:13

2 Answers 2


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.

  • $\begingroup$ 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? $\endgroup$
    – Chris
    Feb 14, 2020 at 6:01
  • 1
    $\begingroup$ @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). $\endgroup$
    – Faulst
    Feb 14, 2020 at 8:06
  • $\begingroup$ 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. $\endgroup$
    – Chris
    Feb 14, 2020 at 22:43
  • $\begingroup$ 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). $\endgroup$
    – Faulst
    Feb 15, 2020 at 14:23
  • $\begingroup$ What if you had a separate computer act as a proxy, which would time requests to the crypto function and return the result after 10 seconds (regardless of however long the actual function took)? Since it's a separate computer it would not branch based on the secret, nor would it have the secret anywhere in its own memory. $\endgroup$
    – Buttons840
    May 5, 2021 at 11:00

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.

  • $\begingroup$ What about trying to to add a sleep so that the total time is close to the same value (a predefined constant)? $\endgroup$
    – shumy
    Feb 13, 2020 at 11:17
  • $\begingroup$ You cannot predict the time of difference since each platform is different. $\endgroup$ Feb 13, 2020 at 13:40
  • $\begingroup$ 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). $\endgroup$
    – Chris
    Feb 14, 2020 at 6:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.