Padding again Was: Practical web-site-specific traffic analyses

[Gregory Maxwell <gmaxwell@xxxxxxxxx>]

On Sun, Aug 1, 2010 at 9:07 PM, Steven J. Murdoch
<tortalk+Steven.Murdoch@xxxxxxxxxxxx> wrote:
[snip]
> To fix this attack, systems can add dummy traffic (padding), delay
> packets, and/or drop packets. Tor adds a bit of padding, but unlikely
> enough to make a difference. Tor doesn't (intentionally) drop or delay
> traffic.
>
> More research is needed before we will know how to best to use and
> combine these traffic analysis resistance techniques. I co-authored a
> paper on some aspects of this problem, but while the combination of
> delaying and padding is promising, more needs to be done before this
> can be deployed in a production system:
>
> Âhttp://www.cl.cam.ac.uk/~sjm217/papers/pets10topology.pdf

The overhead of padding schemes that I've seen, either end to end
type, or hop-based for free routed networks as presented above, are
simply too large to be practical.

I'd also guess that there might also be a negative social effect where
people would be less inclined to run relays if they knew that only a
small fraction of the traffic was actually good-put.

I think this makes a good argument for combining tor with a
high-latency higher anonymity serviceâ so that the "padding" for the
most timing attack vulnerable traffic can still be good traffic
sourced from high latency mixes stored at nodes. ... but this wouldn't
be simply accomplished, and I'm not aware of any ongoing research
along these lines.
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/