[Haskell-cafe] ANNOUNCE: secure-sockets version 1.0

[David Anderson]

On Wed, Sep 8, 2010 at 1:05 PM, Mads Lindstrøm <mads.lindstroem at gmail.com>wrote:

> Hi David
>
> On Mon, 2010-09-06 at 13:50 -0700, David Anderson wrote:
>
> >
> >
> >  - Simple timing attacks: If code path A takes longer than code path B
> > to execute, an attacker can use that information to reverse engineer
> > the outcome of branching tests, and from there possibly recover secret
> > key material. This is particularly nasty because the attack can be
> > carried out remotely, by repeatedly executing the protocol in a way
> > that exercises the vulnerable code path.
> >
> >
>
> I do not know much about cryptography, so I may be writing nonsense
> here, but it seems to me that it should not be too hard insuring that
> all wrongly encrypted data takes equally long to process. One could use
> an algorithm like:
>
> * make interrupt/timer that will finish in one second
> * process data from client
> * If data is correctly encrypted, stop interrupt/timer and return
> information to the client
> * If data is wrongly encrypted, prepare error-result, (busy) wait for
> interrupt/timer to finish, return result to client
>
> That will mean that all clients, that uses a wrong key, will take one
> second to finish. But as clients, with a correct key, finishes fast I do
> not see any problems.
>
> What am I missing here?
>

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.

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.

- Dave


>
> /Mads
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100908/5d45aab4/attachment.html