HN Reader

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.

I look forward to James Kettle's yearly research results, he's the most incredible appsec researcher I know of.

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...

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'm curious that he appears to completely ignore the network latency/jitter on the return path. How does this work?