←back to thread

176 points saikatsg | 2 comments | | HN request time: 0.417s | 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 #
jack_pp ◴[] No.42208951[source]
or you could benchmark the functions that compare secrets to user input and figure out how much time it's supposed to take, add 0.5s to the average and always add time before responding to get to that target so essentially your response time is constant regardless of input
replies(1): >>42209246 #
1. tptacek ◴[] No.42209246[source]
Important to keep in mind here that the timing attacks Kettle is talking about generally do not take the form of "providing secret input to a function with variable timing".
replies(1): >>42211707 #
2. jack_pp ◴[] No.42211707[source]
He says this exact same thing in the Defense at the end:

> Finally, yes I do recommend using constant-time functions when comparing user input with secret keys. Just ask anyone who says this is an actual threat to provide a proof of concept.