Re: Padding again Was: Practical web-site-specific traffic analyses
On Sun, 1 Aug 2010 23:02:53 -0400 Gregory Maxwell wrote: > On Sun, Aug 1, 2010 at 9:07 PM, Steven J. Murdoch > 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 signature.asc Description: PGP signature
Re: Padding again Was: Practical web-site-specific traffic analyses
On Sun, Aug 1, 2010 at 8:02 PM, Gregory Maxwell wrote: > ... > 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. perhaps DLP with SFQ and datagram transport. could even add endpoint mobility / multi-path for resilience. (it sounds so easy ;) practical can be surprisingly forgiving if the protections are compelling. you could build it and find out... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Practical web-site-specific traffic analyses
Steven J. Murdoch writes: > Yes, this has been a known risk with all currently deployed > low-latency anonymity systems. One recent paper which looked at the > problem was discussed here: Thanks for these references. -- Seth Schoen Senior Staff Technologist sch...@eff.org Electronic Frontier Foundationhttps://www.eff.org/ 454 Shotwell Street, San Francisco, CA 94110 +1 415 436 9333 x107 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Padding again Was: Practical web-site-specific traffic analyses
On Sun, Aug 1, 2010 at 9:07 PM, Steven J. Murdoch 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 majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Practical web-site-specific traffic analyses
On Fri, Jul 30, 2010 at 12:32:43PM -0700, Seth David Schoen wrote: > The simplest threat scenario for Tor users would be when an > attacker in a position to observe a particular user's traffic, > but not any exit node traffic, hypothesizes that the user is > likely to visit a particular site and builds up a profile of > what web browsing traffic to that site will look like. The > attacker could then try to confirm the hypothesis that the > user is using that site and also try to infer some details of > what the user is doing. This is quite different from traffic > confirmation because the attacker only has to be present at > one end. Yes, this has been a known risk with all currently deployed low-latency anonymity systems. One recent paper which looked at the problem was discussed here: http://conspicuouschatter.wordpress.com/2009/11/13/in-real-time-from-ccsw09-more-website-fingerprinting/ and the full paper is here: http://www-sec.uni-r.de/website-fingerprinting/ccsw09_website-fingerprinting.pdf What they found is that single-hop proxies were easily broken (>95% accuracy), but multi-hop systems were more of a challenge. The attack against JonDo was about 20% accurate and against Tor it was only 3% accurate. This doesn't mean that multi-hop systems are safe though, because the attack assumed that the anonymity system didn't add any extra traffic. In fact, Tor and JonDo do add quite a bit of extra traffic, and it was probably this which confused the attack. Much of this traffic can be identified and if it were removed before the traffic analysis was performed, the accuracy would likely go up by quite a bit. 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 Steven -- http://www.cl.cam.ac.uk/users/sjm217/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Could somebody comment that information?
On Sun, 01 Aug 2010 20:50:57 + James Brown wrote: > http://www.boingboing.net/2010/07/31/wikileaks-volunteer.html > > Are those a new activity of the President Obama administration against > Internet anonymity and against the Tor-network? It's unclear. The simplest explanation is this detainment and interrogation are due to Jacob's volunteering with Wikileaks. As far as we know today, the US government still believes in anonymity. -- Andrew Lewman The Tor Project pgp 0x31B0974B +1-781-352-0568 Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject skype: lewmanator *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Could somebody comment that information?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://www.boingboing.net/2010/07/31/wikileaks-volunteer.html Are those a new activity of the President Obama administration against Internet anonymity and against the Tor-network? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkxV3jEACgkQV59uvM2EEnfUJwCgkf+4JFLg3qi0OtEcT7fwAm6N iHkAniwF8rCaJI9hkBrnQ6x0OP7btkAD =lsgM -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
