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
 
Anthony DiPierro wrote:
>> separate from the client. if one is running a tor server the
>> entry node is indeed the same node but remember a tor server is
>> shuffling every other packet from other circuits mixed in with
>> yours, and thus it seems logical that it would improve anonymity
> OK, thanks for the correction.  So the standard implementation
> (using privoxy and firefox, for instance), would be:
>
> firefox (local) -> privoxy (local) -> tor client (local) -> tor 1
> (remote) -> tor 2 (remote) -> tor 3 (remote, exit node) ->
> webserver?
yep that's the way it works as far as i understand it
>> a compromised node attack, on average, has to compromise 1/3 of
>> the entire tor network to get somewhere approaching good odds of
>> being able to identify the endpoints of circuits. possibly 2/3,
>> but i'd say 1/3 of nodes being compromised would give usable
>> violation of the system... as you may know, there is something
>> like 300-400 servers in the tor network now, to compromise it
>> they'd have to put up like 150-200 new compromised nodes, or hack
>> and compromise 100-150, either task is not trivial at all.
>
> Well, it's a matter of what type of odds are acceptable to you.  If
>  1/100th of circuits are compromised, I'd consider that too high.
> Now under the diagram I drew above, that'd require about 1/10 of
> the nodes to be compromised.  If you add in another hop, then
> 1/10th of the nodes being compromised would mean only 1/1000th of
> circuits were compromised.
>
> Or am I calculating something wrong?
>
> Anthony
yes, in fact more hops means almost nothing relative to the number of
compromised nodes. remember, the proportion of compromised nodes is
the pool the client picks its hops from, and thus given a random
distribution, the amount of compromise risk reduction accelerates
quickly to nothing with extra hops, and increases latency
unacceptably. The only way to defend against compromised nodes getting
two hops in your circuits would be to implement some kind of system to
register suspect nodes and instruct the client not to use them.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUhgz+KihKRqTxu4RA2amAJwIJ5laBigwUv5n5bLZ2eHSIOzJ4ACfXTp7
6FVKx274WC+tIJeVaAQr/r8=
=CThs
-----END PGP SIGNATURE-----