Before the Circuit: How Tor Builds a Shared Network Map

The Client Arrives with a Starting Point

The client does not discover the directory authorities by asking a stranger. The Tor software release already contains a standard list of directory authorities.

A directory authority is a server with a special role: it observes relays, participates in a vote with other authorities, and signs the result. The client software already contains the necessary public information to identify and contact it. It’s not just a name: the critical data is its expected cryptographic identity.

This identity works like a verification root. The long-term identity key of the authority (identity key) certifies a shorter signing key. The authority then uses this second key to sign directory documents. The client can follow the chain to the identity it already knows. The private keys, of course, remain on the authorities.

This list is present before the first connection. Standard clients are encouraged to use the same list, because two groups of clients recognizing different authorities might receive incompatible views of the network.

The software also contains a second list: the fallback directory mirrors. These are servers from which the client can start downloading documents when it doesn’t yet know the normal directory caches indicated by the consensus.

The two lists have different functions:

• The list of directory authorities tells the client which identities can support the consensus with their signatures;
• The list of fallbacks tells the client from which addresses it can try to obtain a copy of the initial documents.

Before the first download: the client already knows the expected directory authorities and some starting points. It doesn’t yet have the current list of relays and doesn’t have a circuit guard → middle → exit ready.

A fallback can deliver the consensus, but it cannot authenticate it with its own authority. The client accepts the document only if it recognizes a sufficient number of signatures from the directory authorities it already knows.

The first server contacted provides a copy. It doesn’t define the truth and doesn’t automatically become the guard of the future circuit.

The phase in which the client moves from these embedded information to a sufficiently complete and recent map is called bootstrap.

Tor thus separates two problems: where to retrieve a document and how to establish that that document is the approved one.

A Relay Can Describe Itself, But Not Promote Itself

Each public relay generates a server descriptor signed. It’s a card with the relay’s identity, its keys, addresses, and other capabilities that Tor must know.

The signature shows that the descriptor comes from the owner of the relay’s key. It doesn’t show that every statement is true and doesn’t make the server automatically suitable for any role.

This difference becomes evident with the flags. A flag is a label published next to a relay in the consensus. The client uses these labels to understand if that relay can participate in a certain type of circuit.

The difference between position and flag is also seen in the writing: guard and exit in lowercase indicate the circuit positions; Guard and Exit in code style indicate the labels present in the consensus.

The most commonly named flags mean this:

• Guard: the relay is considered suitable as an entry relay;
• Exit: its exit policy allows exit to a sufficiently useful set of destinations and ports;
• Fast: the relay is considered suitable for circuits that require good transport capacity;
• Stable: the relay is considered suitable for circuits that might remain open for a long time.

Middle, instead, indicates first of all a position in the path. There is no rule that every intermediate relay must have a generic Middle flag. There is the special MiddleOnly flag, which indicates that the relay is not suitable for roles other than middle: among other consequences, it is not used as a guard, exit, HSDir, introduction point, or rendezvous point. It’s not the normal way to identify all middle relays.

A relay can declare an exit policy, i.e., the rules on addresses and ports to which it is willing to open connections. It cannot, however, self-proclaim as Guard, Exit, Fast, or Stable in the map used by clients. Directory authorities observe the network and produce the information that will contribute to the flags in the consensus.

The same physical server can have multiple flags and be suitable for multiple positions. Flags do not describe different types of machines. They describe properties and restrictions that the client will apply during selection.

The descriptor is thus a signed statement in entry. Flags, parameters, and weights usable by the client emerge from the consensus process.

More Views Become a Consensus

Each directory authority maintains its own view of the relays and produces a vote document (vote), also signed. Views do not need to be identical. A relay can be reachable from one authority and not from another; observations and measurements can arrive at different times.

Authorities exchange votes and apply common rules to calculate a network-status consensus. The resulting document contains the shared view that clients can use: listed relays, identities, flags, parameters, references to linked documents, and weights. These weights are numeric values that modify the probability with which relays can be chosen for different positions.

Sufficient signatures attest that the document is the accepted result of the voting process. This does not transform the listed relays into trusted relays and does not eliminate trust in the authorities. It does, however, make verifiable that the client is using the common view, instead of the private version proposed by the server from which it downloaded it.

Tor does not eliminate coordination. It makes it explicit and distributes it among multiple authorities.

Producing the Map and Distributing It Are Two Different Tasks

If every client were to download everything directly from the authorities, those machines would become the bottleneck of distribution.

To avoid this, the directory caches store and redistribute consensuses and other documents. A cache does not need to participate in the vote to offer a copy.

The reason is cryptographic. The client verifies the signatures of the consensus. Moreover, when the consensus indicates a descriptor or a microdescriptor via digest, the client can check if it received the expected document. A digest is a cryptographic fingerprint of the content: if the document changes, so does the fingerprint.

A malicious cache can refuse to respond, delay the request, or try to deliver unusable data. It cannot, however, silently substitute an arbitrary document and make it match the digest already authenticated by the consensus.

Authenticity and availability are different properties. Signatures and digests protect the content; they do not obligate a cache to serve it.

The Consensus Does Not Contain Every Detail Necessarily

A complete network map can become large. In the microdescriptor flow, the client uses a microdescriptor consensus: a compact view that also contains the digests of the necessary microdescriptors. Each microdescriptor is a reduced card with only a part of the necessary information on the relay. It is not an independent self-presentation: the directory authorities derive it deterministically from the available information on the relay.

The client verifies the consensus first. Then it uses the authenticated digests to request the smaller documents that describe the relays. The consensus thus works as a verifiable index: it indicates which details belong to the approved view.

This order is important. If the client downloaded arbitrary documents first and decided later which to believe, the download server could influence the set considered. Instead, the signed document establishes first which digests to expect; the download completes the information without redefining the map.

When Bootstrap Is Really Done

Receiving a file called consensus is not enough.

The document declares three moments: valid-after, fresh-until, and valid-until. These values separate a view not yet applicable, a fresh view, a view still usable, and a view expired. A document can thus be authentic but too old to describe the current network.

After verifying signatures and time, the client recovers the descriptors or microdescriptors missing. Only when it has a valid consensus in time and sufficient information on the usable paths does the client consider the bootstrap sufficiently complete to build circuits.

The necessary quantity depends on the configuration and parameters published in the directory information. The important transition is between two different states: «consensus received» and «client ready to build circuits».

If a source does not respond, the client can try another. When it knows the consensus, it can also use the directory caches listed by the network instead of always depending on the initial contacts embedded in the software.

The Map Influences the Path, But Does Not Assign It

The consensus determines the set of candidates, flags, parameters, and weights that the client must respect. In this sense, the directory system influences the choice concretely.

But the document does not contain a triplet guard → middle → exit. It does not order a user to use three specific relays and does not enter the next application path.

When bootstrap ends, the client has a verifiable view of the network. It will use this locally to filter and weigh the candidates based on the circuit’s purpose.

The directory has solved the problem «which relays can I choose?». The next problem is different: why will the client choose precisely those three, and in which order will it contact them?

Technical Sources

Tor Specifications: Directory protocol — Outline (“default list of authorities”, votes, consensus, and cache); Client operation (“Downloading network-status documents” and descriptor); Publishing the consensus (signature requirements); Computing a consensus (calculation); Consensus formats (flags); Computing microdescriptors (derivation); Uploading relay documents (descriptor); Tor Directory List Format (“Scope” and fallback); When we build (“enough directory information”). Consulted August 14, 2026; excludes historical notes.