On Mon, Aug 14, 2017 at 8:16 PM, Hubert Kario <hka...@redhat.com> wrote: > the difference in processing that is equal to just few clock cycles is > detectable over network[1]
The post you reference actually says the opposite; "20 CPU cycles is probably too small to exploit" ... and even today with very low latency networks and I/O schedulers it remains very difficult to measure that kind of timing difference remotely. But per the post, the larger point is that it is prudent to be cautious. > When you are careful on the application level (which is fairly simple when you > just are sending acknowledgement message), the timing will still be leaked. There are application-level and tls-implementation-level approaches that can prevent the network timing leak. The easiest is to only write TLS records during fixed period slots. For example, suppose your process can handle 100 connections concurrently, then you can divide 1ms into 100 slots of 10 microseconds each. Every 1ms you have a writer thread or process 'visit' each connection (you may use an epoll/kqueue driven I/O loop or similar for this) during its fixed slot and send its pending output. -- Colm _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
