Circuits Expire Every Ten Minutes. Your Guard Should Not.
Tor tears down its circuits roughly every ten minutes, yet the same entry guard can stay pinned to your client for four months or longer. That asymmetry looks like an accident. It is actually one of the most carefully studied trade-offs in the network's design.
Why guards exist at all
If every circuit entered the network through a randomly chosen relay, an adversary controlling a slice of the network would eventually sample some traffic from nearly every user. The Tor Project's guard specification states this plainly: without pinning, an attacker holding k/N of the network would see a growing share of circuits as C grows toward infinity. Guards cap that exposure by funneling all circuits through a small, fixed set of entry relays. The logic is simple. You either pass through a compromised guard or you do not. Pinning turns a rolling dice game into a single, low-probability bet - provided you never re-roll it.The guard discovery problem
The catch is that once an adversary learns which guard you use, that relay becomes a fixed target. This is the guard discovery problem: identify the victim's entry point first, then invest in compromising or coercing it. A 2022 PETS paper demonstrated a web-based attack that identifies a user's guard in about twelve seconds using crafted onion address lookups, making the follow-up compromise attack far cheaper than blind guessing. Onion services face the same pressure from the rendezvous protocol itself. Tor design proposal 247 notes that anyone can force a hidden service to build a three-hop circuit to a chosen relay, enabling a Sybil-based guard discovery attack followed by compromise. Vanguards, the mitigation shipped in response, pins second- and third-layer hops precisely because each new relay a client adopts is another chance for discovery.Ten-minute circuits versus long-lived guards
Tor separates path rotation into two very different clocks. Application paths rotate fast: the MaxCircuitDirtiness parameter defaults to ten minutes, after which no new streams may attach to a used circuit, according to the path specification. Middle and exit relays therefore change constantly. Guards run on the opposite schedule. The consensus parameter guard-lifetime-days defaults to 120 days for sampled guards, with confirmed guards kept at least 60 days. Clients use up to three primary guards and are instructed to always prefer them over any alternative. The short clock limits linkability within sessions; the long clock limits how many guards an adversary can realistically get assigned to you.What happens when a guard fails
A dead guard does not trigger an immediate replacement. The guard specification defines staged retries: primary guards are retried on a decaying schedule starting at thirty-second intervals, while non-primary guards get only a fifteen-second connection timeout before being set aside. If the internet itself appears down, marked by the INTERNET_LIKELY_DOWN_INTERVAL of ten minutes, the client holds off entirely. This patience is deliberate. The Changing of the Guards study by Tariq Elahi and colleagues, published at WPES 2012, simulated eight months of real consensus data and found that natural relay churn alone lets a malicious guard drift into client lists over time. Replacing an offline guard instantly compounds the problem, so researchers proposed waiting out outages instead of rushing to sample someone new.Switching guards hurts more than staying put
The same study quantified what intentional rotation costs. A tiny adversarial guard reached roughly ten percent of simulated clients after eight months through churn alone, but adding routine guard rotation pushed exposure to around fourteen percent within just a few months. Every rotation event is a fresh lottery ticket handed to the adversary. Roger Dingledine drew the operational conclusion on the Tor Project blog in 2013:"Changing the guard rotation period to a year or more is probably much wiser, since it will slow down the curves on all the graphs in the above research papers." - Roger Dingledine, Tor ProjectModern C tor landed between the extremes: two to three months of expected rotation plus the multi-month sample lifetimes above. Still slower beats faster, almost always.
What this means for operators and users
For most people the correct behavior is restraint. Frequent restarts, aggressive firewall changes, or manual guard edits all push a client toward sampling new entries, and each new entry resets your security margin downward. Slow latency swings during a guard outage are usually the retry system working, not a reason to intervene. More background lives in our tor network notes. Practical rules worth keeping:- Leave guard selection to the client unless you have a specific threat model.
- Avoid restarting tor on a schedule; uptime protects your guard set.
- If your guard fails, expect staged retries before any replacement.
- Run onion services with Vanguards if they must survive long-term.