[Haskell-cafe] Tor project

[Tobias Dammers]

Yeah, hadn't read your message yet.

This practice is actually pretty much common knowledge in the security
industry.

On Fri, Aug 01, 2014 at 12:04:48PM +0200, Tobias Florek wrote:
> hi,
> 
> >However, if we add noise that depends on the input, the filtering won't
> >remove it, because for each given input it is constant. Instead of
> >removing the noise component from `code(input) + system_noise()`,
> >leaving `code(input)`, the attacker now deals with `code(input) +
> >hash(input) + system_noise()`, leaving them with `code(input) +
> >hash(input)`. Without cracking the hash, I don't know how you'd remove
> >the hash-based delay from the sample; possible mistakes would be
> >insufficient granularity in the hash-based delay (e.g. if the difference
> >between code paths is 1ms and our delay has a 100ms granularity, it's
> >still trivial to filter out the hash noise), insufficient range (if the
> >difference between code paths is 100ms and our delay is between 0 and
> >25ms, we still have two distinct groups), a weak hash function, and
> >probably a bunch more.
> 
> just a note, that that's what sebastian schinzel's "Deterministic and
> Unpredictable delay padding" is about. see the talk (i linked to earlier):
> 
> talk from sebastian schnitzler on 29c3:
> 
> http://media.ccc.de/browse/congress/2012/29c3-5044-en-time_is_not_on_your_side_h264.html
> 
> slides:
>  http://sebastian-schinzel.de/29c3/download/29c3-schinzel.pdf
> 
> abstract:
>  http://sebastian-schinzel.de/_download/cosade-2011-extended-abstract.pdf
> 
> cheers,
>  tob
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe