←back to thread

176 points saikatsg | 1 comments | | HN request time: 0s | source
Show context
miki123211 ◴[] No.42208092[source]
Timing attacks are such a pernicious idea.

You look at the code and see that there's an auth check in place, you test the code to verify that the auth check has no bugs, you make sure that information is never shared with people who don't have authorization to access it, and yet it turns out it can be accessed as if there was no auth check at all.

To make matters worse, everything can be fine for some time, and then some clever optimization in the CPU, the compiler, cache layer or the database engine introduces a completely unexpected side channel.

replies(2): >>42208294 #>>42214191 #
GoToRO ◴[] No.42208294[source]
would adding random delays prevent this?
replies(5): >>42208493 #>>42208931 #>>42208951 #>>42208997 #>>42209530 #
Filligree ◴[] No.42208997[source]
Random delays specifically do not, as they average out. Delays until a specific point in time do work, so long as the delay is never negative.
replies(1): >>42212098 #
1. bostik ◴[] No.42212098[source]
This particular case would be a fantastic fit for timer wheel.[0] Instead of writing a brittle implementation of "after a fixed time in the future" logic yourself, you queue the outgoing event to occur after N ticks [of granularity X], and let the dedicated data structure engine do the work for you.

0: https://www.snellman.net/blog/archive/2016-07-27-ratas-hiera...