<div class="gmail_quote">On Wed, Sep 8, 2010 at 1:05 PM, Mads Lindstrøm <span dir="ltr"><<a href="mailto:mads.lindstroem@gmail.com">mads.lindstroem@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi David<br>
<div class="im"><br>
On Mon, 2010-09-06 at 13:50 -0700, David Anderson wrote:<br>
<br>
><br>
><br>
> - Simple timing attacks: If code path A takes longer than code path B<br>
> to execute, an attacker can use that information to reverse engineer<br>
> the outcome of branching tests, and from there possibly recover secret<br>
> key material. This is particularly nasty because the attack can be<br>
> carried out remotely, by repeatedly executing the protocol in a way<br>
> that exercises the vulnerable code path.<br>
><br>
><br>
<br>
</div>I do not know much about cryptography, so I may be writing nonsense<br>
here, but it seems to me that it should not be too hard insuring that<br>
all wrongly encrypted data takes equally long to process. One could use<br>
an algorithm like:<br>
<br>
* make interrupt/timer that will finish in one second<br>
* process data from client<br>
* If data is correctly encrypted, stop interrupt/timer and return<br>
information to the client<br>
* If data is wrongly encrypted, prepare error-result, (busy) wait for<br>
interrupt/timer to finish, return result to client<br>
<br>
That will mean that all clients, that uses a wrong key, will take one<br>
second to finish. But as clients, with a correct key, finishes fast I do<br>
not see any problems.<br>
<br>
What am I missing here?<br></blockquote><div><br></div><div>Not much, that is an acceptable option. It's also nice in the sense that it tarpits the attacker, slowing him down (assuming the server only allows one in-flight auth attempt per IP or something to that effect). The downside is that you're keeping resources open longer than necessary for attacking connections, which makes it easier to DoS the service. Normally, a failed authentication should kill the connection as quickly as possible, to not waste resources on attackers.</div>
<div><br></div><div>You are correct though that inserting a long-ish delay on failure is a good way to screw with timing attacks, but it does need to be balanced against increasing the risk of resource exhaustion attacks. And either way, it would be nice to have crypto primitives that are tamper-resistant by themselves, rather than rely solely on the application designer to implement attack resistance.</div>
<div><br></div><div>- Dave</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
<br>
/Mads<br>
</font><div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br>