6

It is documented which node knows what.

I'm wondering if the nodes in the circuit know their own relative position. For normal three relay paths, they certainly can infer their position: the exit knows -since it's connecting outside- the middle knows since it's connecting two known nodes, the entry knows since it's connecting a (unknown) client with a known node.

Now, were you to build a 4-hop circuit, would the two middle ones know whether they're in position #2 or #3? My guess is that they would, specially since guards are only used as guards and exits are only used as exits.

From that, it follows you'd need at least 6 hops for some nodes not to know their position, but how is data framed? Can a node infer how many nodes are ahead of it, just from the encrypted payload size?

4

I will add that these statements are within the confines of the protocol. As you mentioned in your question/comment, a single node could use outside resources to determine entry and exit points. However, the number of hops between the two cannot be determined. The middle nodes only know that they're talking to other nodes within the Tor network, without any kind of distinction. They can't assume that the previous or next node will be the exit or entry.

Say you blind folded 4 people and linked them between two doors, but you don't tell them that there are 4 people total. The people holding onto the door handles would know that they're on the ends of the chain. The two middle people know that they're in the middle, but cannot determine how many people came before/after them.

When building a circuit each node is told to establish a link to another node in the network. Since the Tor protocol doesn't attach information that says, "Hey by the way there are 3 more hops", these middle nodes only know that a link exists to the next hop. The Tor design paper explains the control channel and the types of control messages it can send:

The relay commands are: relay data (for data flowing down the stream), relay begin (to open a stream), relay end (to close a stream cleanly), relay teardown (to close a broken stream), relay connected (to notify the OP that a relay begin has succeeded), relay extend and relay extended (to extend the circuit by a hop, and to acknowledge), relay truncate and relay truncated (to tear down only part of the circuit, and to acknowledge), relay sendme (used for congestion control), and relay drop (used to implement long-range dummies).

It's the relay extend messages that allow the Tor protocol to tell a node to extend the circuit without giving away how many hops have already been used in the circuit.


Nodes can't infer how many nodes are ahead of it based on payload size because encryption doesn't add data except padding. The padding would be added to the data prior to encryption. Each encryption layer doesn't change the payload size. Tor uses their own headers, but again the header size won't change from hop to hop.

  • 2
    Thank you for your answer, but keep in mind entry guards certainly know they're being used as an entry guard, as the list of all nodes is public. For the same reason you can infer you're a middle node if you're not entry or exit. The protocol might not make the distinction but it can be inferred easily. – John Aug 25 '15 at 11:36
  • All nodes are public, but there is no distinction among them that says specific nodes are entry/exit/middle. They're all just relays or bridges. How can the routers infer that they're an entry point or just a middle relay if the protocol doesn't? – RoraΖ Aug 25 '15 at 11:54
  • If you receive a connection from a node who is not in the list, you know you're acting as an entry. In fact, a protection was added for exit nodes where they don't allow connections from unknown nodes to prevent 1-hop circuits; which is the same thing: they're detecting their use as guard(+exit) and rejecting it. – John Aug 25 '15 at 12:06
  • @John Ah, I see what you're saying. I updated my answer. – RoraΖ Aug 25 '15 at 12:22
  • Ok, I'll mark as valid. However I feel you downplayed again the risk in your "blindfolded people" example: the persons can in fact see exactly who is before and after them, and have a list of everybody. There are more subtleties: to forbid long circuits, circuits can only be extended from "RELAY_EARLY" cells, and routers will only forward 8 of them per circuit. So I don't think there is a lot of effort to hide relative positions or length. Moreover, in practice, if guards or exits are scarce (<1/3, which is often the case), they'll never be picked up for middle (see dir-spec.txt section 3.8.3) – John Aug 25 '15 at 17:47
0

I'm wondering if the nodes in the circuit know their own relative position.

The simple answer is no. Otherwise your anonymity is broken.

Your question requires you to understand Onion Routing:

In an onion network, messages are encapsulated in layers of encryption, analogous to layers of the vegetable onion. The encrypted data is transmitted through a series of network nodes called onion routers, each of which "peels" away a single layer, uncovering the data's next destination. When the final layer is decrypted, the message arrives at its destination. The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes

From the Tor project, you can read the same thing:

The circuit is extended one hop at a time, and each relay along the way knows only which relay gave it data and which relay it is giving data to. No individual relay ever knows the complete path that a data packet has taken. The client negotiates a separate set of encryption keys for each hop along the circuit to ensure that each hop can't trace these connections as they pass through.

Add to this, the circuit your requests are taking within the Tor network is refreshed every a dozen of minutes.

  • The originator knows the entire path. How are all the nodes identified to the originator without any intermediary being able to read at least part of it? – WGroleau Aug 30 '15 at 2:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy