Re: Anonymity easily thwarted by flooding network with relays?

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

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 majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/