Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Even adding some randomness to the timer tick just means you need more samples to suss the statistic out.

If each timer draws from the same random distribution then sure, you could work out the real tick with greater accuracy, but I don’t know if that is practical.

If the timers draw from different distributions then it is going to be much harder.

I imagine there is an upper limit of how much processing can be done per tick to before any attack becomes implausible.



> If the timers draw from different distributions then it is going to be much harder.

Again, I'm an amateur, but I think you just need to know that distribution, which I guess you usually do (open source vs. closed source barely matters there), law of large numbers and all.

Anyway, looking through literature, this article presents some actual ways to circumvent timers being made corse-grained: https://attacking.systems/web/files/timers.pdf

In that article, the "Clock interpolation" sounds vaguely related to what I was describing on a quick read, or maybe it's something else entirely... Later, the article mentions alternative timing sources altogether.

Either way, the conclusion of the article is that the mitigation approach as a whole is indeed ineffective: "[...] browser vendors decided to reduce the timer resolution. In this article, we showed that this attempt to close these vulnerabilities was merely a quick-fix and did not address the underlying issue. [...]"


I believe your understanding of the literature is correct (I too am an amateur when it comes to side channel attacks). My memory is vague here but I believe that while it still lets you exploit side channels, it still requires extra time to do so which lowers the throughput you get out of the gadget.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: