Re: Is three hops enough? (was Re: Tor client over a SOCKS proxy, and Tor client running through another Tor Circuit)

[glymr <glymr_darkmoon@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
 
Geoffrey Goodell wrote:
> On Fri, Apr 28, 2006 at 12:51:35PM -0400, Anthony DiPierro wrote:
>> Well, if it only takes 2 compromised nodes in a circuit to
>> compromise that circuit, then Tor isn't really useful for
>> anything other than keeping your IP address out of server logs.
>> That's fine, as that's all I use Tor for anyway, and it works
>> well for that limited purpose. I just thought there was more
>> potential.
>
> Timing attacks are always possible in low-latency anonymity
> systems. This is a theoretical limit; without increasing additional
> latency (substantially degrading usability and thus the size of the
> anonymity set) or adding cover traffic near the source (requiring
> sources to stay connected for long periods of time, saturate their
> upstream link, starve their other applications, and break the
> business model of their ISPs), it is literally impossible to
> prevent an attacker from correlating the timing of traffic close to
> the source with the timing of traffic close to the destination.
>
> That said, Tor does what it can to eliminate identifying
> characteristics of the traffic; for example, it ensures that all
> cells are the same size.
>
> The reason for three hops rather than two is that in the case of
> two hops, an attacker in the vicinity of the source will be able to
> succeed if he controls the second hop, or an attacker in the
> vicinity of the destination will be able to succeed if he controls
> the first hop.  In the case of three hops, an attacker in the
> vicinity of the first hop will need to explicitly coordinate with
> an attacker in the vicinity of the last hop in order to succeed.
> Such coordination is a statistical attack at this point; further
> increasing the number of hops provides no qualitative advantage.
>
>> Anyway, as I've said in my other post, I need to delve a lot
>> deeper into the design information.  I should probably build my
>> own client while I'm at it - to really understand what's going
>> on.
>
> Good luck with the client.  Let us know if you manage to circumvent
> any theoretical limitations.
>
> Thanks,
>
> Geoff
>
i did some thinking and i figured out that with any number of hops,
one can compromise the data in the stream if one has alternating nodes
because each node can work out whether it is sending to the same node
as another is receiving, and knowing this information would enable
cryptanalysis, or at least would make timing analysis simple. it
certainly would increase the ability to determine a set of connections
to various sites and collate them together as an anonymous but
profiled user.

i think that the best way to increase robustness against timing
attacks is to create random delays or jumble up the order of streams
in a way that adds noise to the timing data gathered. this would
enable a relatively decent latency on average while increasing the
amount of observation required to get a positive correlation. to some
degree tor already has this problem/feature by being run near to
capacity most of the time anyway.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUlzm+KihKRqTxu4RA/EwAJ9M+vmx/jcf3WZT5t9KB10Ata4ZSACfeE8M
7RKhR5UQc8md942+XgQtYgM=
=xkY7
-----END PGP SIGNATURE-----