Tor’s default client circuit is three hops: guard, middle, exit. Picking that first hop is where Tor’s design makes its most counterintuitive move — it refuses to randomize. Tor entry guards pin a small, persistent set of relays as the first hop for weeks at a stretch, reused circuit after circuit, instead of drawing a fresh relay every time. That looks backwards; less predictability should mean more security. It doesn’t, and the reason is a specific, dated result in the anonymity literature: when an adversary gets to keep sampling from a partly hostile pool, the randomized strategy is the one that eventually fails with certainty — the fixed one does not.
This is a tight, elegant piece of design-pattern engineering, and it generalizes well past onion routing. Any system that repeatedly draws from a pool where some fraction of members are hostile faces the same fork Tor faced. Why Tor chose persistence over randomness — and where that choice still has attack surface of its own — is a transferable lesson for anyone building a system that samples from an imperfectly trusted population.
The Predecessor Attack: Why Randomizing Your First Hop Backfires
The guard relay occupies a specific, privileged position: it is the one hop in an ordinary three-hop circuit that sees a client’s real IP address. It does not see the destination or the payload — both are still wrapped in two further encryption layers — but it sees who is asking. If Tor selected that first hop uniformly at random for every new circuit, the intuition would be that unpredictability is protective: an adversary can’t target what it can’t foresee. Wright, Adler, Levine, and Shields showed in 2003 that this intuition is exactly backwards for a client who builds many circuits over time (Wright et al., “Defending Anonymous Communication Against Passive Logging Attacks,” IEEE S&P 2003).
Their result, since generalized as the predecessor attack, is simple probability with an uncomfortable conclusion. Suppose an adversary controls some fraction of the relays eligible to serve as a first hop. On any single circuit, the chance that hop is adversary-controlled is small — that fraction, and nothing more. But a client using fresh random selection doesn’t build one circuit; it builds thousands over a browsing lifetime, and across N independent draws the probability that at least one lands on a hostile relay climbs toward 1 as N grows, even though each individual draw looked safe.
The table below illustrates the shape of that curve. It uses a simple binomial model with a hypothetical adversary controlling 1% of guard-eligible relay capacity — a round number chosen for the arithmetic, not a claim about real Tor relay statistics — to show why the shape of the problem, not the exact constant, is the lesson:
| Circuits built (N) | Fresh random first hop each time: P(at least one hostile draw) | Persistent guard pinned once: P(exposure) |
|---|---|---|
| 10 | ≈9.6% | 1% (unchanged) |
| 50 | ≈39.5% | 1% (unchanged) |
| 100 | ≈63.4% | 1% (unchanged) |
| 500 | ≈99.3% | 1% (unchanged) |
| 1,000 | >99.9% | 1% (unchanged) |
Random-per-circuit selection doesn’t stay at “1% risk” — it compounds every single time a new circuit is built, because each circuit is an independent trial against the same hostile fraction of the pool. Pin the same guard instead, and the number in the right column simply doesn’t move. That’s the whole design decision in one table: statelessness, which feels like the safer choice because it’s less predictable moment to moment, is provably the worse choice against an adversary who can afford to wait and keep sampling.
This isn’t a purely theoretical pool, either. Independent relay-operator research by the pseudonymous “nusenu” tracked a threat actor known as KAX17, first identified in 2019 with activity traced back to 2017, that at its peak ran more than 900 relays concentrated in guard and middle positions — at points giving an ordinary client up to a 16% chance of drawing a KAX17-run guard relay before directory authorities removed the batch (The Record, “A mysterious threat actor is running hundreds of malicious Tor relays,” 2021). A pool that can concentrate to double-digit percentages, even briefly, is exactly the setting the predecessor attack describes: not a hypothetical adversary, but a documented one.
Persistence Converts Certainty Into a Bounded Bet
Tor’s fix inverts the naive instinct. Instead of maximizing unpredictability, the guard-selection algorithm commits a client to a small, persistent set of guard relays and keeps that set fixed for an extended period, building circuit after circuit through the same first hop rather than re-rolling it.
The important thing to be precise about is what this buys, because it is not what it sounds like at first. Persistence does not lower the odds that any given guard is hostile — that per-guard probability is still whatever fraction of the pool is adversary-controlled, exactly as before. What persistence changes is whether that risk is drawn once or drawn over and over. With a fixed guard set, a client is either compromised from the very first circuit it builds — because the guard it happened to pick was already hostile — or it is safe for as long as that guard set stays in place. There is no third outcome where a client who was fine for the first thousand circuits becomes newly exposed on the thousand-and-first, the way there is under random-per-circuit selection. The risk doesn’t shrink; it stops accumulating.
It’s also worth being precise about what the mechanism is not defending against. A global adversary that can already watch both ends of a connection doesn’t need to run a client’s guard at all — traffic-confirmation correlation of that kind is a separate, explicitly out-of-scope problem in Tor’s published threat model. What guards defend against is narrower: the chance that the one relay positioned to see a client’s real IP is, itself, adversary-controlled. That’s a smaller problem than “defeat all traffic analysis,” and it was never sold as more.
Changing of the Guards: Tuning Persistence Empirically
Committing to a persistent guard raises its own design questions immediately: how many guards should a client keep at once, how long should each one stay pinned before rotating, and what happens if a client’s only guard goes offline — does it fall back to picking a fresh one, quietly reopening the door the whole mechanism was built to close?
Elahi, Bauer, AlSabah, Dingledine, and Goldberg answered these questions with data rather than intuition in “Changing of the Guards” (WPES 2012), simulating guard-rotation policies against real Tor network telemetry rather than reasoning about them in the abstract. Their work shaped the guard-selection algorithm’s later parameters directly: how aggressively to prefer a client’s existing guards over adding new ones, how to handle a guard becoming unreachable without collapsing back to unrestricted random selection, and how to balance guard lifetime against the network’s need to spread load across relays rather than concentrating all traffic on whichever handful of nodes happened to get picked first.
That load-balancing tension is a real cost of the design, not a footnote. Push persistence to its logical extreme — one guard, forever — and a small set of high-bandwidth relays would carry a hugely disproportionate share of guard traffic, which is both an availability risk (that relay’s downtime is the client’s downtime) and a fresh concentration target for the same adversary the mechanism is trying to blunt. The tuning problem is finding a rotation policy that keeps the number of independent trials small enough to defeat the predecessor attack, without concentrating so much traffic on so few relays that an adversary can win by attacking the small set directly instead of waiting for a client to sample its way into trouble.
Tor’s own guard specification documents the resulting mechanism deliberately without hard-coding it: a small, persistent set of guards, held in place for a period the spec frames as weeks to months rather than circuit to circuit, with the precise counts and durations defined as consensus parameters the directory authorities can vote to retune, published and versioned rather than buried as constants in client source. Even the tuning of “how persistent is persistent” stays adjustable as the network’s threat picture changes, instead of being frozen at whatever looked right in 2012.
Guard Discovery: Attacking the Scheme Without Compromising the Guard
Persistence solves the predecessor attack, but it introduces a different kind of attack surface: if a client’s guard stays fixed for weeks, an adversary who can figure out which relay that is gains a stable, long-lived target — without needing to have run that relay itself. Two documented results attack the guard-selection scheme from this angle, at different points in its history and by different means.
Øverlier and Syverson, in “Locating Hidden Servers” (IEEE S&P 2006), described an active attack against the pre-guard version of Tor’s hidden-service design, where the entry relay for a rendezvous circuit was chosen fresh each time rather than pinned. An attacker could repeatedly force a targeted hidden service to build new rendezvous circuits — flooding it with connection requests — until, purely by chance, one of the attacker’s own relays got selected as the entry point, directly revealing the service’s real location. This is the direct historical reason guard persistence was extended from client circuits to hidden-service circuits: a service that re-rolled its entry hop handed a patient attacker exactly the repeated-sampling opportunity the predecessor attack depends on.
Mittal, Khurshid, Juen, Caesar, and Borisov, in “Stealthy Traffic Analysis of Low-Latency Anonymous Communication Using Throughput Fingerprinting” (CCS 2011), showed something more unsettling for the already-guarded case: an attacker doesn’t need to run a client’s guard, or any relay it uses, to identify it. A guard relay tends to be the throughput bottleneck across a client’s circuits more often than the middle or exit hops, since it carries that client’s full traffic load. By correlating throughput fingerprints across many observed circuits — from relays the attacker does control, positioned elsewhere — the attacker can infer which relay is a target’s guard purely from bandwidth patterns, a passive technique requiring no compromise of the guard itself.
| Attack | Source | Class | Target | Mitigation |
|---|---|---|---|---|
| Rendezvous-flooding guard discovery | Øverlier & Syverson, IEEE S&P 2006 | Active | Pre-guard hidden services | Extended guard persistence to hidden-service circuits |
| Throughput fingerprinting | Mittal et al., CCS 2011 | Passive | Any client’s guard, clearnet or onion-service | Vanguards’ rotating extra guard layers (onion services) |
The throughline across both results: pinning a guard closes one attack (the predecessor attack) by removing the attacker’s ability to keep sampling, but it opens a narrower one — a stable target is, definitionally, easier to study over time than a moving one. Neither paper is evidence the guard mechanism failed; both are the reason it kept getting hardened.
Vanguards: Hardening the Scheme for Onion Services
Guard discovery is a sharper problem for onion services than for ordinary clearnet browsing, and the reason is topological. A connection to an onion service isn’t a single three-hop circuit; the client builds its own three-hop circuit to a rendezvous point, the service independently builds a separate three-hop circuit to that same point, and the two are joined there — roughly six relay hops end to end, not three. The standard guard mechanism protects the first hop of each of those two circuits. It says nothing about the hops in between, and a service that stays up for months is, again, a stable target worth studying.
Tor’s answer is the Vanguards add-on, built around Tor Proposal 292 (“Mesh Vanguards”), which layers additional, independently rotating guards onto the deeper positions of an onion service’s side of the rendezvous path — supplementing, not replacing, the ordinary entry-guard algorithm for the extra hops onion-service circuits have that clearnet circuits don’t. The goal, per the Tor Project’s own announcement, is blunting both throughput-style guard discovery and active resource-injection attacks that force rapid circuit rebuilding toward attacker-chosen addresses, so a colluding relay further down the path can’t as easily infer which relay is the service’s guard.
The design logic is the same one this whole mechanism has followed from the start, applied one layer deeper: a long-lived, high-value target benefits from more state and more rotation discipline than a client that builds a handful of circuits and moves on, not less. Vanguards is guard persistence, generalized to a topology where a single guard flag on the first hop alone no longer covers the whole exposure.
The Transferable Lesson: Persistence Beats Randomness Against Repeated Sampling
Strip away the onion-routing specifics and what’s left is a general result about any system that repeatedly draws from a pool where some fraction of the pool is hostile, unreliable, or otherwise something you’d rather not depend on: the number of independent draws is the variable an adversary exploits, and persistence is how you cap it. A single draw with a 1% chance of landing badly is a fine bet. A thousand independent draws with that same 1% chance, taken one after another, is not — the math doesn’t care that each individual draw looked safe in isolation.
This generalizes well beyond anonymity networks, and it’s worth recognizing in systems that have nothing to do with Tor:
| Domain | The tempting random-per-trial design | The persistence alternative |
|---|---|---|
| Tor circuit entry hop | Fresh random relay every circuit | Small, persistent guard set, rotated on weeks-to-months timescales |
| DNS resolution | Random public resolver per query | Pin one or a few audited, trusted resolvers |
| Service-mesh backend routing | Random pod/node per request in a shared multi-tenant cluster | Session affinity or sticky routing to a vetted subset |
| Agent tool or MCP server selection | Pick a random registry entry per task | Maintain a small, vetted, reused allowlist |
| Blockchain light-client peers | Query a random full node per lookup | Pin to a small set of known-honest peers, rotate deliberately |
The trade-off deserves the same honesty Tor’s own designers gave it. Persistence isn’t a free win — it’s a different distribution of the same underlying risk. If the choice you pinned happens to be the bad one, you don’t get the self-correcting benefit random selection offers, where next time might go better; you’re exposed until you deliberately notice and rotate away. What persistence buys isn’t a lower chance of ever picking badly — it’s the guarantee that picking badly doesn’t get more likely just because you kept using the system. Against an adversary that wins by waiting and resampling, that guarantee beats the marginal unpredictability a fresh random draw provides.
❓ Frequently Asked Questions
What is a Tor entry guard?
The entry guard is the first of the three relays in an ordinary Tor circuit — the one hop that sees a client’s real IP address, though not the destination or payload, both still wrapped in two further encryption layers. Rather than choosing this first hop fresh on every circuit, Tor selects a small, persistent set of entry guards and reuses them for an extended period, treating the choice as made once rather than re-rolled per connection.
Why is randomizing your Tor entry guard on every circuit less safe than keeping the same one?
Because of the predecessor attack (Wright, Adler, Levine, and Shields, IEEE S&P 2003): if a client draws a fresh random relay every circuit, the probability that at least one draw eventually lands on an adversary-controlled relay climbs toward certainty as circuit count grows, even though each individual draw carried only a small risk. A persistent guard set instead means the risk doesn’t compound — a client is either exposed from the start or safe for as long as that guard set holds.
How long does Tor keep the same entry guard before rotating it?
Tor’s guard specification describes a small, persistent guard set held in place for a period framed as weeks to months rather than circuit to circuit, but it does not hard-code the exact count or duration as a fixed constant — those are consensus parameters the directory authorities can retune over time, published and versioned in the spec.
Can an attacker find out which relay is a client’s guard without controlling it?
Yes. Mittal, Khurshid, Juen, Caesar, and Borisov (CCS 2011) showed a guard relay is disproportionately likely to be the throughput bottleneck across a client’s circuits, so an attacker elsewhere in the network can infer which relay is a target’s guard purely from correlated bandwidth patterns — passive, no compromise required. Øverlier and Syverson (IEEE S&P 2006) earlier showed an active version against pre-guard hidden services: flooding rendezvous requests until an attacker-run relay gets picked by chance.
Do Vanguards replace the normal Tor entry guard mechanism for onion services?
No. Vanguards, based on Tor Proposal 292, adds rotating extra guards to the deeper hops specific to an onion service’s side of the roughly six-hop rendezvous path — hops the ordinary entry-guard algorithm doesn’t cover, since it only protects a circuit’s first hop. It supplements the standard mechanism for onion services specifically, not ordinary clearnet browsing.
Does pinning a persistent Tor entry guard make an individual user more anonymous?
Not by lowering the odds that any single guard is hostile — that per-guard probability is unchanged. It stops that risk from accumulating across the many circuits a real browsing session builds over time, converting a risk that would otherwise climb toward certainty into a single, bounded bet made when the guard set was first chosen.
📚 Further Reading
- DNS Security Issues, Vulnerabilities, and Exploits and Understanding Internet Bandwidth for Engineers and Architects — the throughput and infrastructure-trust background behind guard-discovery attacks like throughput fingerprinting.
- Secure Agentic Harness: The Lethal Trifecta at Fleet Scale and MCP Server Supply Chain Security: Hardening Agent Skills — the persistence-versus-randomness pattern applied to picking tools and servers from a partly untrusted pool.
- Data and Goliath by Bruce Schneier and The Best Books on Distributed Systems (Beginner to Expert) — the surveillance-threat and distributed-systems grounding this guard-selection trade-off sits inside.
📚 Recommended Resources
Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.
Security Engineering: A Guide to Building Dependable Distributed Systems
Ross Anderson · Book · 3rd edition
The reference for reasoning about adversaries who get to keep sampling, keep waiting, and keep trying — exactly the setting that makes randomized-per-trial selection lose to persistence. If the predecessor-attack argument in this article clicked, Anderson is where that intuition gets formalized across an entire field.
Distributed Algorithms
Nancy A. Lynch · Book
The rigorous treatment of what state actually buys a distributed protocol — the same question underneath “why pin a guard instead of re-rolling it.” A denser read than this article, but the formal grounding for why statefulness is sometimes the more secure design, not the riskier one.
Designing Data-Intensive Applications
Martin Kleppmann & Chris Riccomini · Book · 2nd edition
Not about Tor at all, and that’s the point: the same persistence-vs-randomness trade-off this article walks through — sticky routing, session affinity, pinned upstreams — shows up constantly in the distributed systems this book covers. Useful for seeing the pattern outside an anonymity network.
Free and worth more than any book here: the primary sources this article cites — Tor’s own guard specification at spec.torproject.org and “Changing of the Guards” (WPES 2012) at freehaven.net/anonbib.