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

[Robert Ransom]

On Sun, 1 Aug 2010 23:02:53 -0400
Gregory Maxwell <gmaxwell at gmail.com> wrote:

> On Sun, Aug 1, 2010 at 9:07 PM, Steven J. Murdoch
> <tortalk+Steven.Murdoch at cl.cam.ac.uk> 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.

Assuming the user can't just make his Tor node a relay and wait for
other random people to start stuffing their data through it, I would
suggest the following padding strategy:

* Limit the Tor client's download bandwidth to about 10 kB/s or less,
  to reduce the amount of padding needed.

* Limit the Tor client to one TLS connection, so that all incoming
  traffic is roughly indistinguishable to the attacker we're
  considering (a passive eavesdropper on the user's link to the Tor
  network).

* If possible, introduce delays into outgoing non-RELAY_SENDME cells to
  mask keystroke timing.

* To pad your connection, download a large, useful file through Tor in
  the background.

A higher-latency anonymity service within Tor would be a Good Thing,
but we doesn't seem to have one at the moment, and it's probably not
necessary to block this attack.

Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20100801/d202597a/attachment.pgp>