3 ms·
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 predict
by gsnedders 13y ago
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 http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
- solarexplorer 13y agoMy 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.