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

Theoretically? Sure. By holding your response to a fixed deadline, you're still using a variable time operation under the hood, but turning it into a fixed time operation, being careful not to leak that timing information to an external observer. So, no problem.

Practically? It's a whole lot harder. Having done exactly this in a non-cryptography related situation (sleeping a timer while trying to get time bins as close as possible to a fixed size for binning events without special hardware), you run into all manner of interesting sources of variability. Using hardware is often far simpler if it's available.

Back in a cryptography context, it is exponentially harder yet because you now have to worry about what other side channels are exposing your timing information. For example, if you're "letting the OS do useful work with the rest of the time" - what is it doing? If it's off doing anything else that I can observe, then I can time that instead. And we're back to square one.

Eliminating side channel leaks is entirely non-trivial.



> If it's off doing anything else that I can observe, then I can time that instead. And we're back to square one.

Wouldn't these kinds of leaks always be present though? The scheduler can swap your process out at any time, regardless of whether it explicitly calls sleep() or not, so even with a constant time algorithm you'll have some variability.


The problem isn't variability in total.

The problem is variability based on a secret input.




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

Search: