On Sun, 1 Aug 2010 23:02:53 -0400 Gregory Maxwell <gmaxwell@xxxxxxxxx> wrote: > 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. 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
Attachment:
signature.asc
Description: PGP signature