#13790: Refactor and add comments to new_route_len() -------------------------------------------------+------------------------- Reporter: dgoulet | Owner: | catalyst Type: enhancement | Status: | accepted Priority: Low | Milestone: Tor: | unspecified Component: Core Tor/Tor | Version: Severity: Normal | Resolution: Keywords: 026-deferrable, | Actual Points: tor-03-unspecified-201612 | Parent ID: | Points: Reviewer: | Sponsor: -------------------------------------------------+-------------------------
Comment (by dgoulet): I can confirm that nickm is right, the 3 cases mentioned are the one where we need at least 3 hops that tor picked. Replying to [comment:11 catalyst]: > Which is worse: a path that should be 4 hops becoming 3 hops, or a path that should be 3 hops becoming 4 hops? I would think the first is worse because it could compromise anonymity, while the second wastes resources, increases latency, and decreases reliability. Does that sound right? Or does using a longer path than is necessary introduce some security risk that I'm missing? A circuit that was suppose to be 4 hops but is 3 hops is _bad_. A 3 hops that instead become a 4 hops is "OK" but . Actually, that can happen in the code with circuit cannibalization which is when tor look for an existing circuits and then just re-extend to a 4 hops to the endpoint it's trying to connect (intro point, Exit, rendezvous point, ...). I believe tor has a hard limit of 8 hops for a circuit (`#define MAX_RELAY_EARLY_CELLS_PER_CIRCUIT 8`). I'm not aware of security risk of having long circuits like that but it definitely is very bad on the user experience and overall load of the network. Finally, to your question in comment:8, consider 1 hop to be 1 relay to go through. So if a client wants to open a circuit to an Exit node for instance (most common use case), you'll count Guard -> Middle -> Exit thus 3 hops. For an hidden service connecting to a rendezvous point, you count Guard -> Middle -> Middle -> RP. The service picks 3 hops and then extends to a fourth one. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13790#comment:12> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs