Hacker News Reader

Comment by solarexplorer | Hacker News Reader

What kind of connection is fast enough to detect the difference of a single loop iteration inside memcmp()? I get that this is type of attack is possible if you share the same machine with the attacker. But over the network? Are there any credible sources for this?

View on HN

You don't need fast — you need predictable latency, that's all. Once you have predictable latency, you can work out compute time. And latency can become predictable through a large number of samples.

Brumley and Boneh's 2003 paper ("Remote timing attacks are practical") on this is the typical reference: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

My point is that to receive a single packet, you have an external interrupt, you go through the device driver, the ip stack, etc. And in all that you are looking for a difference of a single cycle. That won't work. Even with a zero latency network. There is just too much code involved.

You can measure differences of thousands or maybe even hundreds of cycles, but not single cycles. That's below the noise level of a modern computer.

Noise can be filtered out by averaging many samples.

Go read the paper. They show (through doing it!) that it's practical.

You probably want to read this: http://codahale.com/a-lesson-in-timing-attacks/

Particularly the section titled "You can’t possibly measure that, can you?"

Thanks for the link. They claim that they can measure differences as small as 100ns, which is pretty impressive. A single iteration in memcmp is still a lot faster: about 1ns. I have a hard time to see how there is a realistic remote attack in this case.

> What kind of connection is fast enough to detect the difference of a single loop iteration inside memcmp()?

Any, really, if you hit it with enough copies of each potential input so that you can get enough results to separate the timing difference from the noise. Though the faster, the more samples you can do per unit time, and the closer in network topology, the less sources of variability in latency that make it take more samples you'll have. At least, that's my understanding.

No, there's a threshold below which you can't effectively distinguish noise from signal even with many samples; theoretically, you can try to overcome this problem with more samples, but there are practical limits, and often actual constraints on the number of samples you can collect and the window of time you have to collect them.

Read Crosby and Wallach's "Opportunities and Limits" paper; the shorthand result of the paper is that across Ethernet you have a window of 100ns, and across an IP network something closer to 30us. The memcmp distinguisher is well below the IP network threshold.

Reply on news.ycombinator.com