3 ms·
Adding random sleeps does not prevent timing attacks. It just adds noise making them a bit more work to pull off.
by MichaelGG 12y ago
Adding random sleeps does not prevent timing attacks. It just adds noise making them a bit more work to pull off.
- e12e 12y agoI suppose one (not very good) approach to "patching-in" constant run-time, would be to limit the runtime of every iteration to be that of the upper bound (possibly +some constant). I suspect that's pretty hard to actually do, and even if accomplished, would open up to other side-channel/timming attacks (eg: check cpu load, and infer timing).
- robryk 12y agoBut, if you have an upper bound on the time of the operation, you can wait until the bound elapses, so that your operation always takes that long.
- TheLoneWolfling 12y agoThe problem is: good luck getting an upper bound. What happens if the process is paged to disk, for instance? No matter what upper bound you set you'll still end up with it going over at some point - and as soon as you go over the upper limit you're leaking timing information again. This also ups RAM requirements, drastically in some cases. And it isn't even necessarily secure against timing attacks! Because the thread scheduling by the OS changes depending on how much work is being done, and so it could take less or more time to retrieve the saved response depending on how long another request takes to process.