But the delay caused by those buffers does not depend on the internal workings of your crypto algorithm.

The delay caused by potential cache misses could very well leak information. If your algorithm terminates early on a string comparison, and therefore doesn't end up evicting more pages out of the cache performing whatever operations would have come after had the strings matched, there could be real world measurable differences, even if you waited for the clock to hit some threshold before continuing on with execution.

Regardless of how much delay there is in other sources, if it is not directly correlated, it can be averaged out.

On Fri, Aug 1, 2014 at 3:38 PM, Wojtek Narczyński <wojtek@power.com.pl> wrote:

On 01.08.2014 09:27, Luke Clifton wrote:

Well, how about something like

inConstantTime :: timeBudget -> (functionToPerform :: CryptoResult) -> IO (Maybe CryptoResult)

I'm no expert, but aren't timing attacks also possible with something like that. If your `functionToPerform' touches the cache in funny ways, the program after resuming from the timeout might have different timings as there could be cache misses in one scenario, but not the other.

Oh come on, there is still a number of slow buffers in between: kernel, network cards, switches, routers.