Instead of a "minimum wait", could you implement a random wait? Some random number of ns/ms between calls. Something that's enough to make any timing attack measurements unusable?
Random waits only increase the number of measurements an attacker needs to make, they do not eliminate the side-channel leakage. Intuitively the attacker can take many measurements and average them out to eliminate the randomness introduced by the waits, then extract the bits of information from the side channel.
A random wait still leaks, but if you can guarantee a reasonable upper bound on the time required, always waiting until that upper bound has passed before responding does not leak.
Here's a secret number plus or minus 10: 98, 104, 101, 110, 93...
You'll never guess what the secret number is. /s
The entire purpose of statistics is to uncover that secret number, and it works if you have enough data. Changing the random plus or minus won't save you.
The time it takes for your function to complete is now a continuous random variable X + r where r is the real time it take for your function to complete.
E(X + r) = E(X) + E(r) = E(X) + r
E(X + r) is the sample mean which is easy to calculate
E(X) = 1/2 * (max(sample) - min(sample))
I never got round to trying it but I was wondering whether you could generate a Cauchy-distributed wait as a way of breaking badly written benchmarks/timing gadgets (i.e. the mean is indeterminate)
