[tor-talk] I have a quick question about security of tor with 3 nodes
vitteaymeric at gmail.com
Sun Aug 31 10:51:35 UTC 2014
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
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.")
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
>> 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
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
More information about the tor-talk