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.
No, it only makes it take longer to get the underlying secret.
Timing attacks are already dealing with "noisy" data, task scheduling et al, so they all boil down to some level of statistical analysis on the response times. Adding noise to that slows you down, but the underlying bias on the timings is still there.
One thing that I’ve done where I previously had a random delay is implement a delay till a constant time from the start of the request. So all of the timing you get out is effectively how well sleep can target a time.
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
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".
A fun thing about this work is that it's following different threads than the remote timing attack research in cryptography follows; high-end remote timing in cryptography involves some signal processing work, which isn't really present here. Which means Kettle's attacks are likely to get more powerful.
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.
would adding random delays prevent this?
No, it only makes it take longer to get the underlying secret.
Timing attacks are already dealing with "noisy" data, task scheduling et al, so they all boil down to some level of statistical analysis on the response times. Adding noise to that slows you down, but the underlying bias on the timings is still there.
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.
One thing that I’ve done where I previously had a random delay is implement a delay till a constant time from the start of the request. So all of the timing you get out is effectively how well sleep can target a time.
It depends on the kinds of attacks you're thinking of. For the stuff Kettle is doing, probably yes. For cryptographic side channels, probably no.
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
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".
A fun thing about this work is that it's following different threads than the remote timing attack research in cryptography follows; high-end remote timing in cryptography involves some signal processing work, which isn't really present here. Which means Kettle's attacks are likely to get more powerful.
I look forward to James Kettle's yearly research results, he's the most incredible appsec researcher I know of.
I have never met James, but I agree his research is great. I always enjoy reading or watching his content.
I did some research few weeks ago on the topic of database lookup timing side-channels, conclusion is: They don't really exist (for SELECT FROM WHERE commands atleast). https://altayakkus.substack.com/p/timing-side-channel-on-sql...
I'm curious that he appears to completely ignore the network latency/jitter on the return path. How does this work?