How Tor Clients Use Directory Authorities to Build Circuits

Tor clients rely on a trusted directory system to discover active relays and securely construct multi-hop circuits through the network. This article explains the role of directory authorities, how network consensus documents are created and distributed, and the exact cryptographic and routing process a Tor client executes to establish an anonymous circuit for web traffic.

What Are Directory Authorities?

Directory authorities are a small set of trusted, geographically distributed servers maintained by independent operators within the Tor ecosystem. Their primary purpose is to maintain a unified, verifiable view of the Tor network.

Instead of relying on a centralized database that could be easily compromised or censored, these authorities continuously measure the state of the network, including: * Which relays are online and reachable * Available relay bandwidth and uptime * Relay flags (e.g., Guard, Exit, Fast, Stable, BadExit) * Cryptographic identity keys and supported protocols

The Network Consensus Mechanism

To provide clients with a consistent directory of nodes, directory authorities periodically create a signed document known as the consensus.

1. Descriptor Upload: Every Tor relay periodically sends a descriptor containing its IP address, public onion keys, exit policies, and self-reported bandwidth to the directory authorities.
2. Voting: Once per hour, the authorities test the relays, generate their own individual votes on the state of the network, and exchange these votes with each other.
3. Consensus Signing: The authorities compile the votes and calculate a single consensus document. If a majority of authorities agree on the list and sign it, the consensus becomes valid.

Clients download this consensus, along with microdescriptors (condensed versions of relay information), typically from distributed directory caches rather than querying the main authorities directly to avoid overloading them. The client validates the cryptographic signatures of the directory authorities before trusting any relay information.

Selecting Relays for a Circuit

Once the client has a valid, verified consensus, it chooses the path for a standard three-hop circuit:

• Entry Node (Guard Relay): The client selects a relay with the Guard flag. Tor clients use persistent “Entry Guards” over several months to mitigate traffic analysis and profiling attacks.
• Middle Node: The client selects a relay with the Fast and Running flags that is not in the same family or subnet as the Guard or Exit node.
• Exit Node: For traffic destined for the public internet, the client selects an Exit relay whose exit policy permits the intended traffic (such as port 443 for HTTPS). For Onion Services, the third hop does not need exit capabilities.

Clients weight their random selection of relays based on bandwidth estimates provided in the consensus to ensure balanced network load.

The Telescoping Circuit-Building Process

Tor builds circuits incrementally using a process called “telescoping,” where each hop is negotiated through the previous hops so that no single node knows both the origin and destination of the connection.

Step 1: Establishing the Guard Hop

The client connects to the Guard node using TLS and sends a CREATE2 cell containing a public key handshake (using the ntor key exchange protocol). The Guard responds with a CREATED2 cell. The client and Guard now share a symmetric encryption key.

Step 2: Extending to the Middle Node

The client encrypts an EXTEND2 cell using the Guard’s shared key and sends it to the Guard. This cell instructs the Guard to connect to the chosen Middle relay. The Guard forwards the nested CREATE2 payload to the Middle relay. The Middle relay responds, and the payload is returned to the client via the Guard. The client and Middle relay now share a second, distinct symmetric key. The Guard cannot read the keys negotiated with the Middle relay.

Step 3: Extending to the Exit Node

The client creates another EXTEND2 cell targeting the Exit relay. This cell is doubly encrypted: first with the Middle relay’s key, then with the Guard relay’s key. It is sent through the Guard to the Middle node, which un-wraps its layer and forwards the payload to the Exit node. The Exit node completes the handshake, returning the response back through the Middle and Guard to the client. The client and Exit relay now share a third symmetric key.

Final Circuit Structure

Once all three hops are negotiated, the circuit is fully operational. The client applies three layers of encryption to outgoing packets (cells):

1. Outer layer: Decrypted by the Guard relay.
2. Middle layer: Decrypted by the Middle relay.
3. Inner layer: Decrypted by the Exit relay.

Because the client obtained authentic relay keys from the directory authority consensus, it is protected against man-in-the-middle attacks, and each relay in the circuit only knows its immediate predecessor and successor.