Hacker News Reader

Question: if you know the attacker doesn't have local access, is it sufficient to simply introduce random response delays to mitigate JVM-JIT level timing differences? Even if you only delayed responses by a few hundred micros on average (with randomness), I imagine all but the smallest amount of fast-path/slow-path entropy would be lost in the noise.

View on HN

It requires the attacker to acquire more data - perhaps so much data that the attack is not feasible - but it doesn't rule out a timing attack.

It's pretty easy to filter out the randomness using statistics.

As I understand it, the correct thing to do is to derive a sleep time from hashing the request content, along with some secret. This makes the delay "random" from the attackers point of view, but still deterministic and therefore impossible to filter out.

Note: I am not a security person, just an interested bystander. Take this half-remembered advice with a pinch of salt.

That won't work if there's an irrelevant parameter in the request that can be varied. Say spaces ignored somewhere or additional parameters ignored, for instance.

Reply on news.ycombinator.com