[cronokirby]

Author here.

To illustrate my point further, let's say that your operation takes either 0.1ms or 0.0ms.

If you add in a uniform random delay of 100-1000ms, your expected random delay becomes 450ms.

The expected total runtime is thus either 450.1ms or 450.0ms. If you have a way to calculate this expected value with enough precision, you can completely recover the timing signal.

The amount of noise you inject can only make recovering the signal harder, not impossible. I also believe that the difficulty is only polynomial in the amount of noise, which limits the effectiveness of this strategy.

The reason why password hashes like PBKDF2 try and make the operation take longer is for a different reason, as far as I know. If you try and crack a password's hash by trying many different common passwords, until you can find a match, then it helps your attack if calculating a hash is very fast. Password hashes intentionally try and make calculating hashes more expensive, both in time, but also in memory consumption (in Argon2, for example), to limit the effectiveness of this attack.

[ghusbands]

This is a good place to ask without a top-level comment: Do people really tend to do it that way? Whenever I've considered using sleep to mitigate timing attacks, it has been to sleep an amount of time that makes the resultant time constant. That is, to make the operation in this case always take 450ms.

[cronokirby]

Sleeping just long enough to fill the remaining time-slot for an operation is actually a valid countermeasure; in theory.

The problem is figuring out how much sleep is necessary based on what variable time work has been done, and actually sleeping the right amount. This can be difficult with the granularity involved.

In practice, attempting to fill the remaining time is either not effective, or requires a level of instrumentation that severely degrades performances.

I'd recommend section 5 of https://eprint.iacr.org/2016/613.pdf for a survey of these ideas.