[Haskell-cafe] Tor project

[Luke Clifton]

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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20140801/d1edeb6c/attachment.html>