Tor Consensus and Directory Authorities Explained

The Tor network relies on a fundamentally decentralized circuit-building model: clients select three independent relays to route traffic without relying on a centralized intermediary to broker each hop. However, to construct circuits safely, every Tor client requires an authentic, universally uniform view of all operational relays across the globe. If an adversary could manipulate an individual user’s network view, they could execute target-deanonymization attacks by serving a fabricated relay list consisting entirely of malicious nodes. To resolve this tension between decentralized routing and the need for a verified global state, Tor employs the Directory Authority system and an hourly consensus mechanism governed by the Tor Directory Protocol Version 3.

The Directory Authority Architecture

The network relies on a small, geographically distributed set of trusted nodes known as Directory Authorities (often abbreviated as DirAuths). As of current deployments, there are nine directory authorities operated by historically trusted volunteers, academic entities, and nonprofit organizations. Unlike standard relays, the cryptographic long-term identity keys and IP addresses of these authorities are hardcoded directly into the Tor source code (defined within the src/app/config/auth_dirs.inc file in the C Tor codebase and corresponding configuration in Arti).

Directory Authorities maintain an authoritative view of the network by executing four core responsibilities:

Relay Registration and Reachability: Periodically probing declared relays to verify that their ORPorts (Onion Routing Ports) and DirPorts are open, reachable, and responsive over TLS.
Bandwidth Measurement: Ingesting measurements generated by Bandwidth Authorities (scanners running software such as sbws—Simple Bandwidth Scanner) to assign objective bandwidth weights rather than relying entirely on relays' self-reported capacities.
Flag Assignment: Evaluating relay performance metrics (such as uptime, latency, and throughput) to algorithmically assign functional status flags.
Consensus Generation: Participating in an hourly threshold voting ceremony to emit a single, cryptographically signed network status consensus document.

A Tor client never relies on a single directory authority to construct its path. Trust is distributed across a mathematical quorum: an absolute majority of active authorities must agree on the network state and co-sign the consensus document before a client accepts it as canonical.

The Tor Directory Protocol Version 3: Hourly Voting Mechanics

The creation of the network status consensus takes place continuously in a rigid, deterministic multi-phase protocol executed on an hourly cycle. This state machine ensures that network drift is minimized and all synchronized authorities produce identical documents despite latency and transient network partitions.

Phase 1: Status Observation and Vote Generation (Minute :00)

At the top of the hour, each authority compiles its local observations into a signed document called a vote. To generate a vote, the authority reads the individual descriptor documents uploaded to it directly by relays. The authority checks whether each relay is responsive, calculates its consensus weight using bandwidth scanner inputs, and applies flags. It then signs this vote using its Directory Authority signing key and publishes it via HTTP to the other authorities.

Phase 2: Vote Exchange and Consensus Computation (Minute :20)

Twenty minutes past the hour, authorities download the votes published by every other accessible authority. Each authority independently executes a deterministic algorithm against the collection of received votes to calculate an unsigned consensus:

Relay Inclusion: A relay is included in the consensus if and only if a quorum (a strict majority) of the voting authorities include that relay in their votes.
Flag Allocation: For each flag (such as Running or Guard), an authority grants the flag if a threshold majority of voting authorities granted it in their individual votes.
Weight Calculation: Bandwidth values are determined by computing the median value of all measured bandwidth lines present in the qualifying votes, rendering the system resilient to anomalous or manipulated outlier values from a compromised authority.

Phase 3: Signature Exchange and Finalization (Minute :50)

Because the consensus generation algorithm is strictly deterministic, every non-divergent authority generates the exact same consensus byte array. At fifty minutes past the hour, each authority computes the cryptographic digest (SHA-256) of this unsigned consensus, signs the digest with its authority key, and publishes this signature. The authorities collect these signatures, append them to the consensus document, and publish the final result. At the start of the next hour, this finalized document becomes the valid consensus used by all clients.

[ Relays Upload Descriptors ] 
              │
              ▼
[ Phase 1 (:00) ] ──> Authorities generate individual, signed Votes
              │
              ▼
[ Phase 2 (:20) ] ──> Authorities exchange Votes & compute Unsigned Consensus
              │
              ▼
[ Phase 3 (:50) ] ──> Authorities sign digest, exchange Signatures, and produce
                      the final Network Status Consensus (Quorum-signed)

Consensus Flavors: Full Networkstatus vs. Microdescriptors

Historically, the consensus document contained complete descriptors for every relay, including exit policy summaries, RSA onion keys, and operational parameters. As the Tor network expanded to thousands of relays, downloading this multi-megabyte document hourly imposed severe network overhead, particularly on mobile connections.

To optimize throughput, Tor introduced microdescriptors and the microdescriptor consensus flavor:

The Full Consensus (NS Flavor): Contains complete summaries of relay metadata, long-term identity fingerprints, IP addresses, ports, directory flags, and bandwidth weights. It is primarily consumed by directory mirrors, authorities, and specialized monitoring infrastructure.
The Microdescriptor Consensus: Omits ephemeral relay data and lists only stable elements: the relay identity key fingerprint, the digest of its current microdescriptor, its IP/port, and assigned flags.

Microdescriptors isolate the components of a relay’s configuration that change rarely (its public identity key, curve25519 onion keys, and IPv4/IPv6 exit policy) from components that change frequently (such as uptime or bandwidth weights). A client downloads the lightweight microdescriptor consensus hourly, but only downloads a specific relay's microdescriptor when that relay's configuration actually changes. This architecture reduced consensus-related bandwidth overhead by over 60% across the global network.

Algorithmic Assignment of Relay Flags

Authorities classify relays through algorithmic criteria rather than subjective discretion. Relay flags directly influence how Tor clients construct circuits via the path selection algorithm. The critical flags include:

Running: Denotes that the relay responded to an active connection check within a short latency window. Relays lacking this flag are omitted from path selection.
Valid: Indicates that the relay's descriptor is correctly formatted and its cryptographic keys are structurally sound.
Fast: Assigned to relays whose estimated bandwidth falls within the top tier of all operational nodes (or exceeds a dynamic threshold determined during the voting process, often 100 KB/s or higher). Crucial for mid-hop and exit roles.
Stable: Assigned based on the relay's Weighted Fractional Uptime (WFU). Nodes must demonstrate long periods of uninterrupted availability to qualify for use as entry guards or long-lived hidden service circuits.
Guard: Requires both Fast and Stable status, alongside high bandwidth capacity. Only relays holding the Guard flag can be selected by clients as the first hop (Entry Guard) in a 3-hop circuit, defending users against persistent profiling attacks.
Exit: Assigned to relays whose descriptors declare an exit policy permitting connections to public internet ports other than standard directory or internal routing ports (e.g., port 80 or 443) without broad rejections.
HSDir: Designates that the relay is authorized to store and serve hidden service (v3 onion service) descriptors within the distributed hash table (DHT).

Threat Models, Sybil Resistance, and Attack Mitigations

The directory authority architecture serves as Tor's primary defense against catastrophic routing attacks. Analyzing the defensive properties of the consensus reveals how the design handles adversarial environments.

Sybil Attacks and Bandwidth Spoofing

In a pure peer-to-peer network without centralized validation, an attacker can launch thousands of virtual relays on minimal hardware (a Sybil attack). If routing weight were determined by self-reported statistics, an adversary could claim massive bandwidth and instantly attract a dominant share of global traffic, trivially deanonymizing paths through correlated entry and exit observation.

Tor prevents this through Bandwidth Authorities. Multiple independent measurement nodes continuously pull test payloads through every relay in the network via two-hop circuits. These empirical speeds override the self-reported capacity in the final consensus via median calculations. A Sybil actor cannot simply announce arbitrary capacities; they must physically provision and sustain measured throughput to capture traffic share.

Split-World Attacks

If an adversary compromises an edge router or controls local DNS/BGP routing for a client, they might attempt a split-world attack: serving the client an outdated, specialized consensus containing only adversary-controlled relays. Tor incorporates defensive mitigations against this vector:

Consensus Lifetime Window: Every consensus specifies three strict timestamps: valid-after, fresh-until, and valid-under (typically a 3-hour envelope). Clients strictly reject any consensus if the current local time falls outside this validity window.
Quorum Signatures: A consensus is only valid if signed by a majority of the known, hardcoded authority identity keys. A localized attacker cannot construct a valid alternative consensus without compromising a quorum of the offline or isolated authority master keys.
Fallback Directories: When a new Tor client bootstraps and has no consensus, it does not query an arbitrary relay. It relies on a hardcoded list of several hundred Fallback Directories (curated relays with static IPs and stable keys) to fetch the initial consensus safely, mitigating bootstrap poisoning.

Authority Key Separation

To defend against the physical or remote compromise of a Directory Authority server, the Tor Project employs strict operational security practices. Each authority separates its long-term Directory Identity Key from its Directory Signing Key. The long-term identity keys (which are compiled into client software) are kept completely offline on air-gapped storage media or hardware security modules. The operational directory server only maintains an intermediate signing key, typically valid for only a few months or a year, signed by the offline identity key. If an active authority server is compromised, the attacker only acquires a transient signing key, which can be rapidly revoked without requiring emergency software updates to all active Tor clients.

Conclusion

The Tor consensus mechanism represents a pragmatic compromise between absolute decentralization and strict cryptographic verification. A fully decentralized routing discovery model—such as an unstructured DHT—remains vulnerable to Sybil, Eclipse, and routing manipulation attacks at scale. Conversely, relying on a single directory server introduces a single point of failure and systemic exposure to coercion.

By relying on an hourly, deterministic voting quorum executed by a diverse body of Directory Authorities, the Tor network ensures that every client independently selects circuits from an authentic, globally uniform, and peer-measured view of the network. This shared cryptographic consensus remains the core structural foundation that makes onion routing resilient against localized surveillance and network manipulation.