Hacker News Reader

Comment by jqueryin | Hacker News Reader

Would implementation of a very minute, random delay (if you give it a range) be an acceptable fix for some of these timing attacks? I'm thinking along the lines of adding a config param to /usr/lib/ssl/openssl.cnf (Ubuntu).

View on HN

No; if you add a random delay, your adversary can just repeat the attack multiple times and the timing data will average out to the real value, removing your added noise. It might increase the time/number of observed messages needed to perform the attack, but it won't defeat it.

(Not at all confident about this.)

AngrySkillzz aside, I think there's another reason this won't work. From the sound of pimterry's explanation, the timing effects happen in your own code, not OpenSSL's. It's not "hit the cache to slow down OpenSSL", but "hit the cache and see if OpenSSL slows me down". Adding random delays to OpenSSL wouldn't help guard against that.

This is unlikely to help against a determined adversary. The reason is that the bias introduced by the timing differences can still be detected using statistical methods, provided you have enough samples. (In general, I would expect that you'd need more samples when the randomness is large relative to the timing attack difference)

See this blog post [1] for examples of how differences as small as 20 microseconds over the Internet could be detected, despite the effect of latency. Latency can be considered a random variable, albeit maybe not with the same distribution as a RNG, but the same principles likely apply.

1. http://rdist.root.org/2010/07/19/exploiting-remote-timing-at...

Reply on news.ycombinator.com