[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] I have a quick question about security of tor with 3 nodes



OK, I still think two hops makes sense in the context of Peersm for example (target phase with WebRTC), the basic circuits are using two peers but can be extended to others, there is no concept of guards and I believe it's not easy for bad peers to continuously return compromised peers since they must be close to the requesting peer and they can not choose their ID/fingerprint, which are ephemeral.

And I still think it does matter somewhere that the first node knows it is the first one, because it knows for sure the IPs it could potentially deanonymize.

Let's imagine the Tor network is choosing 2 or 3 nodes, the first node would not be able to know it is the first one (because it does not know if the path is 2 or 3 nodes), it could check that the IPs are not belonging to the Tor network and then find out that it is the first one, but these IPs could be secret bridges, so it might not be really sure it is the first one.

But maybe the benefit of such proposal (if proven safe) would be too small in the context of the Tor network compared to the traditionnal three nodes selection.

I don't really get since the begining the concept of the CREATE_FAST cells and their systematic use when it's not mandatory for an advantage that does not really seem fantastic, except for bridges, I think I read that you are getting rid of it but did not keep the link, thanks if someone can forward it to me (something more detailed if this exists than what is in the spec "The CREATE_FAST handshake is currently deprecated whenever it is not necessary.")

Regards,


Le 31/08/2014 00:40, Roger Dingledine a écrit :
On Sun, Aug 31, 2014 at 12:28:06AM +0200, Aymeric Vitte wrote:
Two is probably enough, assuming the first one does not know it is
the first one, ie is not triggered by a CREATE_FAST request.
No, I don't think this makes sense. It doesn't matter if the first
hop knows it's first. It only matters if the two relays don't collude
to share notes -- since of them sees the user, and the other sees the
user's destination.

The reason Tor uses three hops rather than two is because the first hop
serves as an entry guard. The entry guard defends against the "over time,
if you didn't use one, the chance of getting screwed would go up every
time you switch circuits" issue. But the downside of sticking with the
same first hop is that it acts as a sort of identifier for the user.

If you only used two hops, and the first stayed static, then the exit
relay could build a profile of the sorts of things users do when they come
from that guard. How bad is that? I don't know, but the safe answer is to
put another dynamic (i.e. not associated with the user) relay in between.

For more reading on path selection, you might like
http://freehaven.net/anonbib/#ccs2011-trust
and
https://www.petsymposium.org/2010/papers/hotpets10-Bauer.pdf

Le 29/08/2014 09:55, John Doe a écrit :
Surely this is not as simple as that which you said. Why have even
a middle node if it is only the first and last nodes that count? I
cannot believe this is a simple thing of the first and last nodes giving
people up.
For a summary of some of the "first-last" correlation attacks and pointers
to the papers behind them, see
https://blog.torproject.org/blog/one-cell-enough

--Roger


--
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk