Tor Directory Protocol Overview

• Tor Directory Protocol is a control-plane mechanism that relies on nine directory authorities to aggregate, sign, and distribute an authenticated network consensus.
• It employs a four-phase, lock-step deterministic aggregation process with precise relay inclusion rules, ensuring timely updates each hour.
• Recent studies reveal vulnerabilities like DDoS-induced liveness failures and insider equivocation, prompting redesigns toward partial synchrony and enhanced Byzantine fault tolerance.

Searching arXiv for the cited Tor directory protocol papers to ground the article in the current literature. The Tor Directory Protocol is the control-plane mechanism through which Tor’s directory authorities collect relay information, exchange local views, and produce an authenticated network-status view for clients and relays. In the deployment described in recent work, a fixed set of nine directory authorities collectively maintains information about available relays and emits a signed consensus document once every hour. Because clients can download one consensus and verify it, rather than query every authority, the protocol is simultaneously the trust bottleneck and the availability bottleneck for the network. A consensus becomes stale after one hour, remains valid up to three hours, and is invalid beyond that; accordingly, sufficiently long failures in consensus generation can make the network effectively stop functioning (Luo et al., 12 Sep 2025).

1. Directory authorities, relay views, and the consensus document

Tor’s directory system is organized around nine directory authorities that maintain a fresh view of the relay population and its properties. Each authority maintains a local status document or vote containing relay information, including which relays it knows and the relay properties used when aggregating the network view. Authorities exchange these inputs and collectively produce a signed consensus document. Relays depend on this document because they are represented in that view, and clients depend on it because circuit-selection security requires a current relay set.

The scale of this control plane is nontrivial. One study reports that Tor had on the order of 7,100 relays on average over the measured period, with roughly 8,000 relays at the time of evaluation; the same study reports a historical average of 7141.79 relays from September 2022 to October 2024. This makes the directory protocol a recurring distributed aggregation problem over large vote files, rather than a small metadata exchange.

The consensus document is generated once every hour, and Tor clients are strongly encouraged to use the latest one. The validity rule is operationally stringent: a run of failed consensus generations lasting three hours can make the whole Tor network unavailable. This temporal structure makes the directory protocol a liveness-critical service, not merely a registry of relay descriptors (Luo et al., 12 Sep 2025).

2. Lock-step consensus generation and deterministic aggregation

The currently described Tor directory protocol is a four-phase, lock-step protocol. Each phase lasts 150 seconds, for a total of 10 minutes. The phases are: Perform Vote, in which each authority sends its vote to every other authority; Fetch Votes, in which an authority missing a vote tries to fetch it from every other authority; Send Signature, in which each authority aggregates the votes locally into a consensus document, signs the result, and sends the signature to every other authority; and Fetch Signatures, in which an authority missing a signature tries to fetch it from every other authority. The first two rounds are therefore devoted to vote dissemination, and the last two to signatures and publication (Luo et al., 12 Sep 2025).

Consensus formation is deterministic once enough votes are available. The relay-level aggregation rule reproduced in the literature is precise. A relay is included if it appears in at least $t \ge \lfloor n/2 \rfloor$ votes. If included, its name is chosen from the vote with the largest authority ID. Relay properties are selected by majority vote with Tor-specific tie-breaking rules: each flag is not set in case of a tie, the largest version and/or protocol is selected, and the lexicographically larger exit-policy summary is selected. The relay’s bandwidth is set to the median across votes that measure it. A run succeeds if authorities generate a consensus and receive at least 5 signatures in the nine-authority setting.

The protocol also exchanges signatures on the locally computed consensus separately from the consensus body. In that sense, the published result is effectively a consensus document together with a sufficient set of authority signatures over that document. A plausible implication is that safety depends not only on cryptographic validity of signatures, but also on whether the authorities agreed on the same input set before signing (Luo et al., 24 Mar 2025).

3. Bounded synchrony, bandwidth starvation, and the DDoS liveness attack

Recent analysis identifies the protocol’s central systems assumption as a steep synchrony assumption: any message sent by a correct authority is assumed to reach every other correct authority within a fixed, known bound instantiated as 150 seconds. This assumption is used directly for progress. In effect, the protocol interprets “not received by 150 seconds” as functionally absent, even though Internet conditions can instead reflect transient congestion, path failure, overloaded hosts, or induced bandwidth exhaustion.

Under the studied threat model, the attacker is an outsider who does not compromise any authority. The attacker knows the authorities’ public IP addresses and uses DDoS-for-hire stressor services to flood them, reducing effective bandwidth available for directory-protocol traffic. The attack is therefore an availability and liveness attack rather than an agreement attack: it does not attempt to forge inconsistent consensuses, but to prevent consensus generation from completing.

The attack leverages a timing asymmetry in the current protocol. All vote dissemination is concentrated into the first 300 seconds, namely the first two 150-second rounds. If 5 of the 9 authorities are bandwidth-starved during that window, the remaining authorities cannot gather enough votes in time to compute a valid consensus. The paper’s representative failure log captures this directly: an authority reports that it is missing votes from 5 authorities, repeatedly fails to download them, then reaches “Time to compute a consensus” and reports “We don’t have enough votes to generate a consensus: 4 of …”. The title claim that “five minutes” is enough is therefore tied exactly to the 2 $\times$ 150-second vote window.

The quantitative analysis is relay-count dependent. For the current network size of roughly 8,000 relays, each attacked authority needs about 10 Mbit/s during the first two rounds to participate successfully, whereas prior Tor DoS work estimated that a node under DDoS may have only 0.5 Mbit/s available. The same study infers a representative authority uplink capacity of about 250 Mbit/s; if an authority needs 10 Mbit/s for protocol traffic, then flooding it with 240 Mbit/s reduces residual capacity below the protocol’s requirement. Using a unit cost of \$0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$0.074 per disrupted consensus instance and \$53.28 per month for hourly repetition of the 5-minute attack. The demonstration was performed in a controlled Shadow environment rather than on the live public Tor network, so the result is a feasibility claim under realistic attack economics and bandwidth assumptions, not a claim of a live-network takedown (Luo et al., 12 Sep 2025).

4. Equivocation under minority compromise and the problem of hidden consensuses

A distinct line of work shows that the directory protocol is vulnerable not only to outsider liveness attacks but also to insider equivocation. In this attack class, a compromised authority sends different votes to different correct authorities while preserving local cryptographic validity. Because the current protocol does not force all correct authorities to agree on a single authoritative vote from each sender before signing begins, different authorities can compute and sign different consensus documents from different local vote sets.

The striking result is that a single compromised authority can suffice under suitable input distributions, and that a targeted client can be induced to use an equivocated consensus document in an undetectable manner. The attack does not require the malicious consensus to become the public network-wide consensus. Instead, the attacker can let the benign branch become public while privately assembling a hidden branch with enough signatures to look valid to the targeted client. This is why archived public consensus documents do not establish retrospective safety: they reveal the published branch, not necessarily any unpublished branch delivered only to selected clients.

The short-term mitigation proposed in that work is TorEq, a reactive monitor that collects from every authority the votes it says it received from every other authority and checks for discrepancies. The paper reports that TorEq was merged into Tor’s monitoring infrastructure on August 11, 2023. Its evaluated overhead is higher than the existing monitor but still operationally practical: 140.7 MB of bandwidth versus 18.0 MB, and 229.164 s of page-generation time versus 134.988 s, completing within about five minutes. The long-term mitigation is DirCast, which models the authority-consensus problem as interactive consistency and realizes it via authenticated synchronous Byzantine broadcast. DirCast is described as requiring about 1,000 lines of code added in a Tor C codebase section of about 13,000 lines, with no client changes. The same paper states that the full system reaches agreement in “optimistically five rounds and at most nine rounds” in the current nine-authority setting; elsewhere the body text gives 5 rounds in the best case and $f+4$ rounds in the worst case, which for $f=4$ yields 8, and the paper does not fully reconcile this discrepancy (Luo et al., 24 Mar 2025).

5. Partial synchrony, interactive consistency, and redesigned directory consensus

The DDoS analysis motivates a different redesign direction: replacing bounded synchrony with partial synchrony. In that model there is a Global Stabilization Time, $GST$, during which message delays may be arbitrary and unknown; after $GST$, communication becomes timely again within some bound $\Delta$. This redesign explicitly accepts temporary non-synchronous periods, including those induced by bandwidth exhaustion, while still aiming for deterministic Byzantine consensus with eventual progress.

The tradeoff is a reduced Byzantine threshold. The literature states explicitly that bounded synchrony can achieve $f < n/2$, while partial synchrony can only achieve $f < n/3$. For 9 authorities, this means tolerating up to 2 Byzantine faults instead of 4. The redesign is formalized as Interactive Consistency under Partial Synchrony. With $\times$0 nodes $\times$1, each node $\times$2 starts with a value $\times$3 and outputs a vector $\times$4 satisfying four properties: Termination, Agreement, Value Validity, and Common Set Validity. In particular, if $\times$5, a correct node’s own value must appear in its output; in all cases, every correct output contains at least $\times$6 non-$\times$7 entries.

The redesigned protocol is decomposed into dissemination, agreement, and aggregation. In dissemination, each authority broadcasts its full document $\times$8, digest $\times$9, and signature in a DOCUMENT message, then forms a PROPOSAL vector after receiving at least $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$0 documents. A leader collects at least $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$1 proposals and constructs a digest vector $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$2 with proof $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$3. In the agreement phase, any standard view-based Byzantine agreement protocol for partial synchrony may be used, including PBFT, Tendermint, or HotStuff; the implemented prototype uses a HotStuff variant. In aggregation, once authorities agree on the common digest vector, they fetch any missing full documents and then run Tor’s existing deterministic relay aggregation algorithm locally. The redesign therefore changes how authorities agree on the set of authority inputs, not the relay-property computation itself.

The performance claims are deliberately comparative. Under authority bandwidth settings of 50, 20, 10, 1, and 0.5 Mbit/s and relay counts from 1,000 to 10,000, the current protocol fails once the fixed two-round dissemination window cannot carry the vote files; for roughly 8,000 relays, it needs more than 10 Mbit/s, and it fails between 9,000 and 10,000 relays at 10 Mbit/s. The partial-synchronous redesign continues to operate because large-document dissemination can take arbitrarily long before the agreement step, and the agreement step itself operates only on digests and proofs. The paper specifically reports that the redesign still works at 0.5 Mbit/s, though it then takes around 15 minutes to finish sending documents and achieve consensus. Under a complete five-minute DDoS that knocks five authorities offline at protocol start, the current protocol and a synchronous secure prototype fail in that run and fall back to rerunning after 30 minutes, whereas the redesign generates a consensus about 10 seconds after the attack ends. In normal conditions, when serving 9,000 relays, the redesign adds about 5 seconds at 20 Mbit/s and about 3 seconds at 50 Mbit/s relative to Tor’s existing 10-minute directory cycle. This suggests that the redesign primarily addresses timing fragility rather than ordinary-case throughput.

Protocol	Synchrony / security	Communication
Current protocol	bounded synchrony; insecure	$0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$4
Synchronous secure prototype	bounded synchrony; secure for interactive consistency	$0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$5
Partial-synchronous redesign	partial synchrony; secure for interactive consistency under partial synchrony	$0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$6

Communication complexity for the partial-synchronous design is given as $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$7, and when HotStuff is used for agreement with input size $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$8, the overall complexity becomes $0.00074 per \((\text{Mbit/s} \cdot \text{hour})\), the paper computes an estimated cost of about \$9. The prototype is implemented in Rust, adding roughly 1000 lines of code (Luo et al., 12 Sep 2025).

6. Hidden-service directories, bridge distribution, and the boundaries of the term

The expression “Tor Directory Protocol” is often used narrowly for the nine-authority public relay-consensus mechanism, but the broader directory architecture includes other subsystems with different trust and privacy properties. One prominent example is the hidden-service directory subsystem. Onion service descriptors are not published globally; instead, a service computes descriptor identifiers and uploads two descriptors, using replica indices 0 and 1, to a protocol-determined subset of HSDir relays. Because each descriptor is stored on three adjacent HSDirs, each service is effectively placed on six HSDir relays per period. This creates an unavoidable exposure channel: an HSDir that stores a descriptor learns the onion address and can misuse that knowledge. The “Honey Onions” framework exploits exactly this property by creating bait onion services that are never shared elsewhere; any visit therefore implies probable snooping by one of the hosting HSDirs. Over a 72-day study, the inferred lower bound was at least 110 malicious HSDirs, with about 40,000 visits observed (Sanatinia et al., 2016).

A second boundary case is bridge distribution. TorBricks is explicit that it is not a replacement for Tor’s standard public directory protocol. Rather, it is a bridge-distribution protocol for the censorship setting in which public relay visibility makes blocking easy. Bridges are intentionally omitted from Tor’s public directory, so bridge distribution becomes a separate directory-like problem: how to tell users about usable entry points without publishing them globally. TorBricks distributes $f+4$0 bridges, guarantees that all honest users can connect with high probability after $f+4$1 rounds, and extends to multiple untrusted distributors with resistance against a $f+4$2 fraction of malicious distributors. The paper’s own framing is that this is a private, adaptive bridge directory/distribution layer logically adjacent to, but distinct from, the ordinary public directory architecture (Zamani et al., 2016).

Recent onion-service attack work further illustrates that directory-derived metadata have effects beyond consensus generation itself. In that setting, introduction points are learned from onion-service descriptors fetched from HSDirs, and attack feasibility is affected by relay flags such as Running, Valid, Stable, Fast, [Guard](https://www.emergentmind.com/topics/guard), and V2Dir, as well as by consensus weight and consensus-derived guard and middle selection probabilities. The paper is explicit that it is not an attack on the directory protocol in the narrow sense; rather, it uses directory-published metadata and HSDir-published descriptors as enabling substrate for a traffic-analysis attack on long-lived introduction circuits (Constantinides, 27 Feb 2026).

Taken together, these results distinguish three layers. First, the public nine-authority consensus protocol provides the authenticated relay view on which ordinary Tor path selection depends. Second, the hidden-service directory subsystem distributes onion-service descriptors to a small, deterministic subset of HSDirs, creating a privacy-sensitive storage role. Third, censorship-oriented bridge distribution is an adjacent but separate problem because bridge addresses must not be globally enumerable. The term “Tor Directory Protocol” is therefore most precise when restricted to the authority consensus process, but the surrounding directory architecture is broader and includes subsystems whose security failures are different in kind: outsider-induced liveness failure, insider equivocation, HSDir snooping, and bridge enumeration resistance.