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

[Nick Mathewson]

[Fixed topposting so conversation can flow.]

On Fri, Apr 28, 2006 at 03:05:44PM -0700, Ringo Kamens wrote:
> On 4/28/06, Nick Mathewson <[EMAIL PROTECTED]> wrote:
> >I'd like to register a small objection: while (absent countermeasures)
> >correlation attacks work, it remains to be proven whether or not you
> >can improve security significantly while adding only a small,
> >tolerable, amount of padding and delay.
>
> Here's an example where cover traffic is good. If somebody has access to
> servers and is trying to correlate users to traffic, and some users have
> cover traffic then those users will ALWAYS show up as the users who are
> using traffic at the same time and thus it is harder to track them down.

I think you misread me; I didn't say, "cover traffic never helps." I
said, "nobody knows whether a little bit of cover traffic helps much."

This defense you describe (usually called "constant-rate padding")
works if the users in question are always sending at the same rate and
at the same pattern.  But this means that if they *ever* want, say, a
10kpbs download, they must *constantly* generate 10kpbs worth of
traffic, which is quite expensive for the network to deal with.

Also, if their computers sometimes crash, they're in trouble, since
they're not "always on" any more: see
http://freehaven.net/anonbib/#e2e-traffic .

Now, it is *possible* that there is a system like this where you can
get good effects with just a little big of extra cover traffic.  It is
also possible, however, that there isn't one.  Nobody has done the
experimentation and analysis to prove either way.

yrs,
-- 
Nick Mathewson


pgpP0IKVB4u6V.pgp
Description: PGP signature

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

[Ringo Kamens]

Perhaps you can do this:
firefox-->privoxy-->SOCKS proxy 1-->SOCKS proxy 2-->tor-->internet
This way, even if they could determine "your" ip, they would get the IPs of your proxy which is re-routing encrypted tor traffic. 
On 4/28/06, Paul Syverson <[EMAIL PROTECTED]> wrote:
On Fri, Apr 28, 2006 at 02:35:16PM -0400, Nick Mathewson wrote:>> You can find out more about the last 25 years of anonymity research at
> http://freehaven.net/anonbib/ .>To reinforce, most of what has been raised in this thread has beenraised (often years ago) and subjected to lots of published
analysis. The tradeoffs between anonymity and practicality continue toevolve, but if you have a thought off the top of your head, there's agood chance it's already reflected in the literature. Keep thinking
about it and raising questions/comments, but do also have a look atthe extensive research that's been done in this area.One paper that isn't posted in the anonbib (yet) shows some timingattacks confirmed via experiments on the Tor network and
countermeasures to them. Seehttp://www.onion-router.net/Publications.html#locating-hidden-serversThere were also a different sort of timing attack conducted on a
younger and much smaller Tor network. See"Low-Cost Traffic Analysis of Tor" in the anonbib.aloha,Paul

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

[Ringo Kamens]

Here's an example where cover traffic is good. If somebody has access to servers and is trying to correlate users to traffic, and some users have cover traffic then those users will ALWAYS show up as the users who are using traffic at the same time and thus it is harder to track them down.

On 4/28/06, Nick Mathewson <[EMAIL PROTECTED]> wrote:
On Fri, Apr 28, 2006 at 02:14:20PM -0400, Geoffrey Lewis Goodell wrote:[...]> 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.I'd like to register a small objection: while (absent countermeasures)correlation attacks work, it remains to be proven whether or not you
can improve security significantly while adding only a small,tolerable, amount of padding and delay.  Research on high-latencymix-nets seems to show that you can delay intersection attacks byincreasing latency variability and decreasing sender-frequency
variability; but nobody has done the numbers (yet, AFAIK) to tellwhether these techniques are useful on the low end of the latencyscaleThere are smart researchers with strong intuitions in either direction
on this; my intuition tells me that when so many clever peopledisagree, more experimental results are needed.Of course, nothing like this will go into Tor in the forseeablefuture.  We have a strong design policy: "No Voodoo."  In other words,
we try not to add "security" features unless someone can demonstratethat they actually improve security.(Anybody interested in doing something like this as a researchproject: first, check out the papers about traffic analysis on
http://freehaven.net/anonbib .  Many of the most 'obvious' ideas don'twork as well as you'd think they would; many of the recenttraffic-analysis techniques work better.)
--Nick Mathewson

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

[Paul Syverson]

On Fri, Apr 28, 2006 at 02:35:16PM -0400, Nick Mathewson wrote:
> 
> You can find out more about the last 25 years of anonymity research at
> http://freehaven.net/anonbib/ .
> 

To reinforce, most of what has been raised in this thread has been
raised (often years ago) and subjected to lots of published
analysis. The tradeoffs between anonymity and practicality continue to
evolve, but if you have a thought off the top of your head, there's a
good chance it's already reflected in the literature. Keep thinking
about it and raising questions/comments, but do also have a look at
the extensive research that's been done in this area.

One paper that isn't posted in the anonbib (yet) shows some timing
attacks confirmed via experiments on the Tor network and
countermeasures to them. See
http://www.onion-router.net/Publications.html#locating-hidden-servers

There were also a different sort of timing attack conducted on a
younger and much smaller Tor network. See
"Low-Cost Traffic Analysis of Tor" in the anonbib.

aloha,
Paul

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

[glymr]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
 
Nick Mathewson wrote:
> Congratulations; you just invented high-latency mix-nets. :)
>
> The problem is that nobody can prove that these "jumbling"
> techniques do any good in resisting an attacker until you increase
> the delay to the point where messages take a very long time to
> arrive.  When this happens, you wind up with a very low number of
> users, so you don't get much anonymity anyway.
>
> You can find out more about the last 25 years of anonymity research
> at http://freehaven.net/anonbib/ .
>
> yrs,
in the end the only way to give a major boost to the anonymity of tor
is to find some way to get more people running servers, and it is my
opinion that the way to do this is to make clients run a low bandwidth
link which is used to serve low bandwidth low latency streams. this
would increase the anonymity of users by mixing their streams up with
other users, which would have a damaging effect on the ability to do
timing attacks because of the mixing and the uniformity of packets
between servers and servers, and clients and servers. This will not be
practical without some kind of latency classification in the system,
because by and large streams are either high latency high bandwidth or
low latency low bandwidth (connectionless versus interactive streams).
the side effect is that it would probably help further reduce latency
for interactive users and increase anonymity for all clients.

i believe it says in the faq that running a server on a machine used
mainly for running a client helps anonymity because the node
participates in unrelated traffic to the user's traffic. i have been
complaining for quite some time about the arbitrary 20kb/s bottom end
of server bandwidth limiting - the reason being that only connections
with 256kbps upstream or better can do this, and mind you, are being
quite heavily loaded, and connections with 56, 64 and 128kbps upstream
links are excluded from participating unless a secondary program is
used to force the traffic of the server to below 50% of the upstream.

this is a very small modification with very big implications - it
could mean that when installing, the user could be queried about their
upstream bandwidth (or indeed there may be some way to directly
determine this without user interaction) and have half of it assigned
to server traffic as a top-end limit. it is not at all unreasonable to
ask that people using the network give something back, especially when
doing so will increase their anonymity.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUmYY+KihKRqTxu4RA6KuAKDKqcuD+YsKMPvYQzaPoiLYY/Oa5wCgvGO1
Jt5eiOO0g4cPW79RHkhab0w=
=xzDw
-END PGP SIGNATURE-

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

[Nick Mathewson]

On Sat, Apr 29, 2006 at 04:20:22AM +1000, glymr wrote:
 [...]
> 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.

Please, please, read the FAQ that Roger cited.  You don't need
alternating hops to do a correlation attack; you just need first and
last.

> 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.

Congratulations; you just invented high-latency mix-nets. :)

The problem is that nobody can prove that these "jumbling" techniques
do any good in resisting an attacker until you increase the delay to
the point where messages take a very long time to arrive.  When this
happens, you wind up with a very low number of users, so you don't get
much anonymity anyway.

You can find out more about the last 25 years of anonymity research at
http://freehaven.net/anonbib/ .

yrs,
-- 
Nick Mathewson


pgpZpHuAvr9Sg.pgp
Description: PGP signature

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

[Nick Mathewson]

On Fri, Apr 28, 2006 at 02:14:20PM -0400, Geoffrey Lewis Goodell wrote:
 [...]
> 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.

I'd like to register a small objection: while (absent countermeasures)
correlation attacks work, it remains to be proven whether or not you
can improve security significantly while adding only a small,
tolerable, amount of padding and delay.  Research on high-latency
mix-nets seems to show that you can delay intersection attacks by
increasing latency variability and decreasing sender-frequency
variability; but nobody has done the numbers (yet, AFAIK) to tell
whether these techniques are useful on the low end of the latency
scale

There are smart researchers with strong intuitions in either direction
on this; my intuition tells me that when so many clever people
disagree, more experimental results are needed.

Of course, nothing like this will go into Tor in the forseeable
future.  We have a strong design policy: "No Voodoo."  In other words,
we try not to add "security" features unless someone can demonstrate
that they actually improve security.

(Anybody interested in doing something like this as a research
project: first, check out the papers about traffic analysis on
http://freehaven.net/anonbib .  Many of the most 'obvious' ideas don't
work as well as you'd think they would; many of the recent
traffic-analysis techniques work better.)

-- 
Nick Mathewson


pgpZrZHINoWKN.pgp
Description: PGP signature

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

[glymr]

-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-

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

[Geoffrey Goodell]

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



signature.asc
Description: Digital signature

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

[Anthony DiPierro]

On 4/28/06, glymr <[EMAIL PROTECTED]> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160

On Fri, Apr 28, 2006 at 11:47:07AM -0400, Anthony DiPierro wrote:
>> If there is an attack that can be made, for example, over a 9 hop
>>  chain where an attacker only has two nodes compromised, I'm not
>> sure what it is.  I suppose there could be some sort of timing
>> attack, one that can't be easily mitigated by cover traffic.
>> Maybe that's what I'm missing.
what you are missing is that more hops results in a hell of a lot of
cover traffic, but does nothing about compromised nodes. killing
responsiveness with so many hops defeats the point of tor tho, since
its main purpose is for low and medium latency applications.


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.


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.

Thanks for your help and information.

Anthony

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

[Anthony DiPierro]

On 4/28/06, Roger Dingledine <[EMAIL PROTECTED]> wrote:

On Fri, Apr 28, 2006 at 11:47:07AM -0400, Anthony DiPierro wrote:
> If there is an attack that can be made, for example, over a 9 hop
> chain where an attacker only has two nodes compromised, I'm not sure
> what it is.  I suppose there could be some sort of timing attack, one
> that can't be easily mitigated by cover traffic.  Maybe that's what
> I'm missing.

Exactly:
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#VariablePathLength

--Roger



I'm going to have to delve deeper into the design and other docs.  I
thought I understood what was going on to some extent, but the more I
think about it the more questions I have.

Thanks for bearing with me and my semi-newbie questions.

Anthony

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

[glymr]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
 
On Fri, Apr 28, 2006 at 11:47:07AM -0400, Anthony DiPierro wrote:
>> If there is an attack that can be made, for example, over a 9 hop
>>  chain where an attacker only has two nodes compromised, I'm not
>> sure what it is.  I suppose there could be some sort of timing
>> attack, one that can't be easily mitigated by cover traffic.
>> Maybe that's what I'm missing.
what you are missing is that more hops results in a hell of a lot of
cover traffic, but does nothing about compromised nodes. killing
responsiveness with so many hops defeats the point of tor tho, since
its main purpose is for low and medium latency applications.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUj6h+KihKRqTxu4RAysgAJ9Q+H3xiS5IfIOnLRtq0NudsMBefgCgoYbx
KhGy8xwV89OwOnkW35Utom8=
=2+vr
-END PGP SIGNATURE-

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

[Roger Dingledine]

On Fri, Apr 28, 2006 at 11:47:07AM -0400, Anthony DiPierro wrote:
> If there is an attack that can be made, for example, over a 9 hop
> chain where an attacker only has two nodes compromised, I'm not sure
> what it is.  I suppose there could be some sort of timing attack, one
> that can't be easily mitigated by cover traffic.  Maybe that's what
> I'm missing.

Exactly:
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#VariablePathLength

--Roger

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

[Anthony DiPierro]

On 4/28/06, glymr <[EMAIL PROTECTED]> wrote:

Anthony DiPierro wrote:
> 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.


The way I understand it, an attacker would need to compromise all the
nodes except for the exit node (and the start node, of course) - *not*
that they need to compromise any two nodes in the chain.

If there is an attack that can be made, for example, over a 9 hop
chain where an attacker only has two nodes compromised, I'm not sure
what it is.  I suppose there could be some sort of timing attack, one
that can't be easily mitigated by cover traffic.  Maybe that's what
I'm missing.

Anthony

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

[glymr]

-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-

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

[Anthony DiPierro]

On 4/28/06, glymr <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
> Anthony DiPierro wrote:
> > On 4/27/06, Ringo Kamens <[EMAIL PROTECTED]> wrote:
> >> I don't really see anything wrong with it if you really want to do it. It
> >> doesn't really increase anonymity, but it sounds good to me. I'm assuming
> >> that tor2 sees the ip address of the tor 1 exit node.
> >>
> >
> > The way I picture it it would basically be equivalent to adding extra
> > hops.  I remember reading this is possible to hack into the standard
> > tor software, but I believe it requires a recompile and not just a
> > config file tweak.
> >
> > Anyway, it is my understanding that the current default implementation
> > uses three hops.  Now am I correct that that includes the exit node?
> > Does it also include the entry node which is generally on the same
> > computer?
> this is incorrect, the entry node, middleman node and exit node are
> 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?

> > If so, it seems that in the current default implementation only one
> > compromised node, the middle node (working with the destination site),
> > is needed to significantly impact your anonymity.  The IP address of
> > the exit node is generally recorded in web logs along with the time
> > and date.  So if the middle node records the incoming and outgoing
> > node IP addresses, that can then be matched up with the web logs.  If
> > someone is using three hops the way I described it above, then the
> > incoming IP address would be the address of the tor user, right?
> > Sure, you'd have a little bit of plausible deniability, as there's no
> > proof your system was set up this way, but that's it.
> >
> > Now hopefully I'm just wrong about what constitutes three hops (or
> > that the default setting is three hops).  Or maybe I'm missing
> > something as to why this type of attack isn't possible.
> >
> > One thing seems almost certain, adding hops does increase the security
> > against a compromised node attack.
> >
> > Anthony
> 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

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

[glymr]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
 
Ringo Kamens wrote:
> Well, that 1/3 statement is if every circuit were to be
> compromised. I have noticed that there are some servers on the DoD
> Information Network (Kind of like how NRC runs freenet nodes). I
> also noticed some servers at nato c3. (They were blocked by
> peerguardian while I was trying to connect). I do believe 5 is a
> good amount, and I'm interested on how to change it.
>
> On 4/28/06, *glymr* <[EMAIL PROTECTED]
> > wrote:
>
> Anthony DiPierro wrote:
>> On 4/27/06, Ringo Kamens < [EMAIL PROTECTED]
> > wrote:
>>> I don't really see anything wrong with it if you really want
> to do it. It
>>> doesn't really increase anonymity, but it sounds good to me.
> I'm assuming
>>> that tor2 sees the ip address of the tor 1 exit node.
>>>
>
>> The way I picture it it would basically be equivalent to
> adding extra
>> hops.  I remember reading this is possible to hack into the
> standard
>> tor software, but I believe it requires a recompile and not just
>> a config file tweak.
>
>> Anyway, it is my understanding that the current default
> implementation
>> uses three hops.  Now am I correct that that includes the exit
> node?
>> Does it also include the entry node which is generally on the
>> same computer?
> this is incorrect, the entry node, middleman node and exit node are
>  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
>> If so, it seems that in the current default implementation
> only one
>> compromised node, the middle node (working with the
> destination site),
>> is needed to significantly impact your anonymity.  The IP
> address of
>> the exit node is generally recorded in web logs along with the
> time
>> and date.  So if the middle node records the incoming and
>> outgoing node IP addresses, that can then be matched up with the
>> web
> logs.  If
>> someone is using three hops the way I described it above, then
> the
>> incoming IP address would be the address of the tor user, right?
>> Sure, you'd have a little bit of plausible deniability, as
> there's no
>> proof your system was set up this way, but that's it.
>
>> Now hopefully I'm just wrong about what constitutes three hops
>> (or that the default setting is three hops).  Or maybe I'm
>> missing something as to why this type of attack isn't possible.
>
>> One thing seems almost certain, adding hops does increase the
> security
>> against a compromised node attack.
>
>> Anthony
> 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.
i think that it would be useful if someone would make a peerguardian
list of possibly suspect nodes so people could run them with tor to
help defend against this problem
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUgZ9+KihKRqTxu4RA4yAAJ4rYJ0arxYzasMGHTEZoqcqH5AtsACffQZ/
p7BBiuDfV9nGKz9PYBmNGaA=
=3ti/
-END PGP SIGNATURE-

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

[Ringo Kamens]

Well, that 1/3 statement is if every circuit were to be compromised. I have noticed that there are some servers on the DoD Information Network (Kind of like how NRC runs freenet nodes). I also noticed some servers at nato c3. (They were blocked by peerguardian while I was trying to connect). I do believe 5 is a good amount, and I'm interested on how to change it.

On 4/28/06, glymr <[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-Hash: RIPEMD160Anthony DiPierro wrote:> On 4/27/06, Ringo Kamens <
[EMAIL PROTECTED]> wrote:>> I don't really see anything wrong with it if you really want to do it. It>> doesn't really increase anonymity, but it sounds good to me. I'm assuming
>> that tor2 sees the ip address of the tor 1 exit node. The way I picture it it would basically be equivalent to adding extra> hops.  I remember reading this is possible to hack into the standard
> tor software, but I believe it requires a recompile and not just a> config file tweak.>> Anyway, it is my understanding that the current default implementation> uses three hops.  Now am I correct that that includes the exit node?
> Does it also include the entry node which is generally on the same> computer?this is incorrect, the entry node, middleman node and exit node areseparate from the client. if one is running a tor server the entry
node is indeed the same node but remember a tor server is shufflingevery other packet from other circuits mixed in with yours, and thusit seems logical that it would improve anonymity> If so, it seems that in the current default implementation only one
> compromised node, the middle node (working with the destination site),> is needed to significantly impact your anonymity.  The IP address of> the exit node is generally recorded in web logs along with the time
> and date.  So if the middle node records the incoming and outgoing> node IP addresses, that can then be matched up with the web logs.  If> someone is using three hops the way I described it above, then the
> incoming IP address would be the address of the tor user, right?> Sure, you'd have a little bit of plausible deniability, as there's no> proof your system was set up this way, but that's it.>
> Now hopefully I'm just wrong about what constitutes three hops (or> that the default setting is three hops).  Or maybe I'm missing> something as to why this type of attack isn't possible.>
> One thing seems almost certain, adding hops does increase the security> against a compromised node attack.>> Anthonya compromised node attack, on average, has to compromise 1/3 of theentire tor network to get somewhere approaching good odds of being
able to identify the endpoints of circuits. possibly 2/3, but i'd say1/3 of nodes being compromised would give usable violation of thesystem... as you may know, there is something like 300-400 servers inthe tor network now, to compromise it they'd have to put up like
150-200 new compromised nodes, or hack and compromise 100-150, eithertask is not trivial at all.-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.3 (MingW32)Comment: Using GnuPG with Mozilla - 
http://enigmail.mozdev.orgiD8DBQFEUgFR+KihKRqTxu4RA+URAKC1iSF0Rqfd8MfWvheWJCvRdKI1XwCgn2YOx1xJp+DsGT/Oz9Shq63yr+A==QTPX-END PGP SIGNATURE-

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

[glymr]

-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
 
Anthony DiPierro wrote:
> On 4/27/06, Ringo Kamens <[EMAIL PROTECTED]> wrote:
>> I don't really see anything wrong with it if you really want to do it. It
>> doesn't really increase anonymity, but it sounds good to me. I'm assuming
>> that tor2 sees the ip address of the tor 1 exit node.
>>
>
> The way I picture it it would basically be equivalent to adding extra
> hops.  I remember reading this is possible to hack into the standard
> tor software, but I believe it requires a recompile and not just a
> config file tweak.
>
> Anyway, it is my understanding that the current default implementation
> uses three hops.  Now am I correct that that includes the exit node?
> Does it also include the entry node which is generally on the same
> computer?
this is incorrect, the entry node, middleman node and exit node are
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
> If so, it seems that in the current default implementation only one
> compromised node, the middle node (working with the destination site),
> is needed to significantly impact your anonymity.  The IP address of
> the exit node is generally recorded in web logs along with the time
> and date.  So if the middle node records the incoming and outgoing
> node IP addresses, that can then be matched up with the web logs.  If
> someone is using three hops the way I described it above, then the
> incoming IP address would be the address of the tor user, right?
> Sure, you'd have a little bit of plausible deniability, as there's no
> proof your system was set up this way, but that's it.
>
> Now hopefully I'm just wrong about what constitutes three hops (or
> that the default setting is three hops).  Or maybe I'm missing
> something as to why this type of attack isn't possible.
>
> One thing seems almost certain, adding hops does increase the security
> against a compromised node attack.
>
> Anthony
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.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
iD8DBQFEUgFR+KihKRqTxu4RA+URAKC1iSF0Rqfd8MfWvheWJCvRdKI1XwCgn2YO
x1xJp+DsGT/Oz9Shq63yr+A=
=QTPX
-END PGP SIGNATURE-

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

[Anthony DiPierro]

On 4/27/06, Ringo Kamens <[EMAIL PROTECTED]> wrote:
>
> I don't really see anything wrong with it if you really want to do it. It
> doesn't really increase anonymity, but it sounds good to me. I'm assuming
> that tor2 sees the ip address of the tor 1 exit node.
>

The way I picture it it would basically be equivalent to adding extra
hops.  I remember reading this is possible to hack into the standard
tor software, but I believe it requires a recompile and not just a
config file tweak.

Anyway, it is my understanding that the current default implementation
uses three hops.  Now am I correct that that includes the exit node? 
Does it also include the entry node which is generally on the same
computer?

If so, it seems that in the current default implementation only one
compromised node, the middle node (working with the destination site),
is needed to significantly impact your anonymity.  The IP address of
the exit node is generally recorded in web logs along with the time
and date.  So if the middle node records the incoming and outgoing
node IP addresses, that can then be matched up with the web logs.  If
someone is using three hops the way I described it above, then the
incoming IP address would be the address of the tor user, right? 
Sure, you'd have a little bit of plausible deniability, as there's no
proof your system was set up this way, but that's it.

Now hopefully I'm just wrong about what constitutes three hops (or
that the default setting is three hops).  Or maybe I'm missing
something as to why this type of attack isn't possible.

One thing seems almost certain, adding hops does increase the security
against a compromised node attack.

Anthony