Would buffering socket send resist timing attacks

Question

I have been reading and thinking about timing attacks on cryptographic systems. The answer to this question mentions the following:

"The way to defend against timing attacks is to make sure the time taken to execute cryptographic operations does not depend on any secret information."

My question is, assuming a model where an adversary is connected to an oracle via networking, would write buffering socket.send at the application level to only occur every x milliseconds protect against crypto operations that would otherwise leak data?

My idea is to use the select system call say, every .01 seconds, to handle any reads and writes. Since data would only leave the server at constant intervals, does it matter if short circuit comparisons or the like were used?

The most obvious downside I can think of is that it would add some latency to all application network requests, even non crypto related ones.

Is this a valid defense against side channel attacks in situations where networking delivers the queries/responses?

Answer 1

It will only help to a certain degree.

If you want to protect against ciphertext attacks you cannot just add random time. The reason for that is that the random time you add is probably in a range. Or in your case, the period between calls will be in a certain range.

This means that if you have a large enough sample set you can figure out the deviation of the calls. Say you find out the maximum timeout. If the call takes maximum + x then x will be the time that the cryptographic operation takes.

Of course, for this to become a problem, you need to have a bigger data set. Computers and networks are however insanely fast, so usually creating a bigger data set is often not a problem.

If you try to mess with things like buffering of networked data you may also have to protect against attackers trying to circumvent the buffering issue. The network is the initial interface for an attacker, so it will be the primary attack surface.

The network buffering and cryptographic computations are not directly related. This solution would tie the network implementations with the protection of cryptographic algorithms. This is probably not a relationship that you want to maintain.

Your solution will also not protect against DPA attacks or attacks on the CPU itself (using access to the CPU from user accounts). So the protection is limited to the networking interface.

Another issue is that CPU scheduling can be pretty obnoxious. Sometimes an operation may take much longer than average. In that case the timeout may not be sufficient.

All in all, this should definitely not be the only protection against side channel attacks, and the limitations of the approach should be well understood.