On Fri, Nov 19, 2010 at 03:25:01AM -0500, Michael Cozzi wrote: > On 11/18/2010 11:03 PM, Roger Dingledine wrote: >> attack, which doesn't care how many hops your path has (as long >> as it's at least two). You can read more about it from the various >> freehaven.net/anonbib/ links in this blog post about a related topic: >> https://blog.torproject.org/blog/one-cell-enough >> > > Roger, > > I'm not sure as a career sys admin that I am qualified to really > comment on this. But in order for this attack to work, you have to > correlate the input data to the entry node to the output data to the exit > node (as you have said). That can be done by measuring timing and size of > the data. > > Getting around this seems to me to be easy. All that has to happen is > the addition of garbage data from the client which is then stripped out on > the exit node. That way the data going into the network has a false size, > always larger than what is actually being transported, this happens in the > first layer of the "onion". So the data in, never equals the data out and > vice versa.
Sorry. This doesn't work. Besides the tremendous overhead added to the network of full-length padding to whatever perceived maximum across all client or destination flows go in either direction on circuits and/or the performance hit of adding delay to smooth flows that are too high a data rate on a network already perceived as too slow by many of its users, it is trivial for the entry node to induce a timing signature whatever the client has done. And this signature will be discernible by the exit node. Lots of work has gone into trying to do something to deal with this question (my own last contribution in the area is here http://www.cs.yale.edu/homes/jf/FJS-PETS2010.pdf) So far all of it is merely theoretical. And I believe that will always be true for the majority of use cases. > > At that point *timing* is the only correlating factor. And with the > latency of the tor network, that would be very hard to track, with the > perceived security going up on busier guard and exit nodes. Also, some > slight random latency could be introduced (smallish factor, 1 to 10 ms) for > all middle nodes, muddying the waters even more. As hinted above, adds overhead that is not affordable on a usability level, and is easily defeated by trivial active attacks. > > Like I mentioned before, I'm not really qualified to comment on this. I > use tor as an IT tool for security and offsite testing. Your reactions are good. It's just that many people have had the same reactions so we've explored this, and nobody in all of the research done has yet produced a viable version of what you suggest. aloha, Paul *********************************************************************** To unsubscribe, send an e-mail to [email protected] with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
