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

[Aymeric Vitte]

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