Tor is a distributed system that solves one narrow, precisely stated problem: let a client reach a destination such that no single party on the path — not even the network’s own relay operators — can link sender to receiver, while keeping latency low enough for interactive use. This article covers how Tor works at the protocol level: layered (“onion”) encryption, telescoping circuit construction, the ntor handshake, fixed-size cells, the guard/middle/exit relay roles, and the hourly directory consensus that bootstraps trust in a network with no central operator. It closes with the part most explainers skip — Tor’s own stated threat model, and the deliberate, published limits of what onion routing defends against.
The thesis worth carrying past the mechanics: Tor is the best-documented production case study available of designing a system against an explicit, published adversary model. Every wire-format choice below — the ntor handshake, the fixed cell size, the persistent guard set, the nine-authority consensus — defends a specific, named adversary capability, and the system’s designers were equally explicit about what they were not defending against. That precision is rarer in security engineering than it should be, and it’s the actual reason to study Tor if you build distributed systems for a living.
What Tor Is, and What It Is Not
Get the taxonomy right before anything else, because most Tor confusion is really taxonomy confusion. Tor is three distinct things wearing one name:
- The Tor network — a volunteer-run overlay of relays that carry traffic through multi-hop encrypted circuits.
- Tor Browser — the Firefox-ESR fork that The Tor Project ships, hardened against fingerprinting and configured to route through the network by default. It is not the same artifact as Onion Browser, a separate, third-party iOS app maintained independently by Mike Tigas — a distinction worth getting right, since the two projects have different codebases, different maintainers, and different security postures.
- Onion services — destinations that live inside the Tor network (
.onionaddresses) rather than being reached through it. They’re a minority of Tor’s traffic and a separate protocol layer from ordinary circuit-relayed browsing; this article covers the client-circuit case, not onion-service rendezvous (that’s a hub of its own).
Tor is also not a VPN, and the difference is structural, not marketing. A VPN moves your trust problem — you now trust one operator with both your identity and your destination, in exchange for hiding both from your ISP. Tor’s design goal is that no single relay ever holds both pieces at once. And Tor by itself does not make a user anonymous: browser fingerprinting, account logins, and unencrypted traffic at the exit relay all defeat network-layer anonymity regardless of how good the routing is underneath. Network anonymity and application-layer anonymity are different problems, and Tor solves the first one.
The NRL Origin, and Why It Had to Be Public
Onion routing did not begin as consumer privacy software. It began as a defensive communications problem for the U.S. Naval Research Laboratory (NRL), where Paul Syverson, Michael Reed, and David Goldschlag started the work in the mid-1990s, funded initially by the Office of Naval Research starting in 1995; the first public description appeared at the 1996 Information Hiding Workshop, with the code cleared for public release that July. DARPA extended funding in 1997 under its High Confidence Networks program and again from 2001 under Fault Tolerant Networks, before U.S. government funding for the project ended in the fourth quarter of 2004, according to Tor’s own project history.
The goal was protecting government and intelligence communications traversing the open internet — not, as a persistent myth has it, exfiltrating data. That myth gets the mechanism backward: onion routing is a routing-layer anonymity protocol, with nothing in its design that moves data out of a network it wasn’t already permitted to reach. The actual, more interesting problem NRL had to solve was one of population, not cryptography: a network used only by naval intelligence officers anonymizes no one, because “traffic from this network” is itself a fingerprint that reads as “U.S. government business.” Correlating a message to “someone on the onion-routing network” is most of the work of correlating it to “a U.S. government employee” if government employees are the only users on it.
That realization is the single most important thing carried out of NRL and into Tor’s public design. Roger Dingledine, Nick Mathewson, and Syverson built the second-generation implementation — named Tor, “The Onion Router” — starting in 2002; alpha code was released in September 2002, and the network grew publicly through 2003 to roughly a dozen volunteer nodes by year’s end, ahead of the design being formalized at USENIX Security 2004. The 2004 design paper states the deployability goal directly: “a hard-to-use system has fewer users — and because anonymity systems hide users among users, a system with fewer users provides less anonymity.” Dingledine and Mathewson later expanded this into its own argument in Anonymity Loves Company: Usability and the Network Effect, presented at the Workshop on Economics of Information Security (WEIS) in 2006: a rational, technically sophisticated user would still choose an anonymity system partly by how many other people use it, because the anonymity set the system provides is its user population.
This is why NRL released the code publicly, why EFF began funding Dingledine and Mathewson in 2004, and why The Tor Project incorporated as a 501(c)(3) nonprofit in December 2006. Diverse, public, civilian adoption was not philanthropy bolted onto a government tool — it was a load-bearing security requirement. For an architect, it’s a genuinely counterintuitive result: for most systems, a smaller and more homogeneous user base is a security improvement. For an anonymity system, the anonymity set is the user population, so a smaller, more homogeneous base is weaker — an attacker who merely learns “this is Navy traffic” has done most of the deanonymization work already, without touching a single cryptographic primitive. Security, here, is a property of the network’s demographics, not just its math.
Layered Onion Encryption: What Each Relay Knows and Cannot Know
The mechanism that makes the population argument survivable is layered encryption over a fixed three-hop path: guard, middle, exit. The client encrypts its traffic in nested layers, one per hop, using a session key negotiated individually with each relay. Each relay strips exactly one layer — decrypting with the key it negotiated with the client — and forwards what’s left toward the next hop. No relay ever sees more than one layer removed from what it received, and one layer short of what it forwards.
The result is a system where knowledge is structurally partitioned, not policy-partitioned:
| Relay position | Sees client’s real IP | Sees the destination | Sees the payload (if the app layer is itself plaintext) | Knows the full path |
|---|---|---|---|---|
| Guard (hop 1) | Yes | No — still wrapped in two more layers | No | No |
| Middle (hop 2) | No — only the guard’s and exit’s circuit IDs | No | No | No |
| Exit (hop 3) | No | Yes | Yes, if unencrypted | No |
Notice what’s missing from every row: no single relay position ever has both “who” and “what.” The guard is the one relay that sees the client’s real IP address, but the payload in front of it is still wrapped in two more encryption layers, so it cannot read the destination or the content. The exit is the one relay that can see the destination and any application-layer plaintext, but it never received the client’s identity — all it has is the previous hop’s circuit ID, which belongs to the middle relay, not the client. The middle relay is structurally the least informed of the three: it never sees an endpoint at all, only two other relays’ circuit identifiers passing through.
This is a stronger property than access control over the same data, and it’s the generalizable lesson worth stealing: rather than trusting each party to behave, the architecture makes each party incapable of learning what it doesn’t need. A relay that never receives a piece of information cannot leak it, subpoena-comply it, or misconfigure it into a log file. Compare that to a typical multi-tenant proxy or API gateway, where every hop by default receives the full request and chooses not to look — an assumption that fails the moment any single component is compromised, subpoenaed, or simply misconfigured.
Telescoping Circuit Construction: EXTEND2, EXTENDED2, and Why Incremental
Circuits are not built all at once — they’re telescoped, extended one hop at a time, and the reason connects directly to the knowledge-partitioning property above.
The client first negotiates a session key with the guard directly, via a CREATE/CREATED cell pair (or their newer CREATE2/CREATED2 variants). To extend the circuit, the client doesn’t open a new connection to the middle relay — it sends an EXTEND2 relay message, carried inside a RELAY_EARLY cell, through the already-encrypted tunnel to the guard. The guard, on receiving it, opens a fresh CREATE2 handshake to the requested next hop and relays back the resulting EXTENDED2 response once that hop replies. The client repeats the pattern to add the exit: an EXTEND2 message tunneled all the way through the two already-negotiated hops, answered by an EXTENDED2 traveling back the same path. Every one of these mechanics is defined in tor-spec’s circuit-construction section.
The detail that matters architecturally: each hop’s key material is negotiated directly between the client and that specific hop. The guard, when it forwards the client’s EXTEND2 payload to the middle relay, is forwarding opaque handshake bytes it cannot read — it is not a party to the resulting session key between the client and the middle relay. No intermediate relay ever holds, derives, or even sees the key material for a hop further down the path.
Two properties fall out of building the circuit this way instead of negotiating one shared key for the whole path up front:
- No relay ever sees a complete, cleartext description of the path. The guard knows the middle relay exists (because it’s the one contacting it), but it doesn’t know the exit; the middle relay knows the guard and exit exist as adjacent circuit IDs, but not which client initiated the circuit or what the client is trying to reach. Path knowledge is scoped to immediate neighbors only.
- Forward secrecy is per-hop, not per-circuit. Each hop uses a fresh ephemeral Curve25519 exchange. If an adversary records traffic today and compromises a relay’s long-term identity key next year, that compromise doesn’t retroactively decrypt anything — the ephemeral session keys used at the time are gone, and they were never derivable from the long-term key alone.
The transferable lesson generalizes past onion routing: if you must reveal topology to establish a secure multi-hop channel, reveal it incrementally, and re-key at every increment, rather than negotiating the whole path in one shot with a single shared secret. A single up-front handshake for an entire multi-party path means every party that helped set it up necessarily learned something about the whole path in the process, and a single compromised key-derivation step compromises every hop that depended on it. Telescoping trades one extra round trip of latency per hop for the guarantee that no party — not even a fully cooperative relay — ever holds more topology information than its own two neighbors.
The ntor Handshake
The cryptographic core of each hop’s key exchange is ntor: Diffie-Hellman over Curve25519, combined with HMAC-SHA256 for key derivation and authentication. It’s not a Tor-specific invention — it’s a direct implementation of Goldberg, Stebila, and Ustaoglu’s provably secure one-way-authenticated key exchange (1W-AKE) construction, published in Designs, Codes and Cryptography, ported into Tor’s wire protocol as Proposal 216 and merged into the codebase in Tor 0.2.4.8-alpha (2013).
Before ntor, circuit hops were negotiated with TAP (the “Tor Authentication Protocol”), built on RSA-1024 combined with Diffie-Hellman. TAP is now marked obsolete in-spec; ntor has been the deployed standard for over a decade, and neither TAP’s key sizes nor its ad hoc security argument would be considered acceptable in a new protocol design today.
| TAP (legacy, obsolete) | ntor (current standard) | |
|---|---|---|
| Core primitive | RSA-1024 + Diffie-Hellman | Curve25519 ECDH + HMAC-SHA256 |
| Security argument | Ad hoc, pre-dates the construction below | Goldberg/Stebila/Ustaoglu’s provable 1W-AKE construction |
| Merged into Tor | Original (2002–2013 default) | 0.2.4.8-alpha (2013) |
| Status today | Marked obsolete in tor-spec | Deployed default for all circuit hops |
Two things worth version-pinning precisely, because both are easy to overstate. First, ntor-v3 is a real, specified extension — it carries additional encrypted data using SHA3-256 and AES-256-CTR, and moves relay identities from 20-byte SHA-1 digests to 32-byte Ed25519 keys — but it is a specified capability, not yet the deployed default for ordinary circuit construction; treat any claim that it has replaced ntor network-wide as needing a fresh check against tor-spec at time of reading. Second, post-quantum circuit handshakes — hybrid constructions combining X25519 with a lattice-based key-encapsulation mechanism, aimed at the “harvest now, decrypt later” threat — exist as active proposal work (proposal 263, superseded by 269 and 340), not as a shipped default. Both are worth tracking; neither should be described as already protecting ordinary Tor circuits today.
Fixed-Size Cells and Traffic Analysis
Every unit that moves across a Tor connection — control messages and relayed data alike — is a cell, and cells are fixed-size by design. On the current link protocol (version 4 and above), a cell is 514 bytes: a 4-byte circuit ID, a 1-byte command, and a 509-byte body. On the legacy link protocol (version below 4), the circuit ID shrinks to 2 bytes, making the whole cell 512 bytes. The 509-byte body is constant across both; only two categories of cell — the VERSIONS command and commands numbered 128 and above — are allowed to vary in length. All of this is defined precisely in tor-spec’s cell packet format, and it’s worth citing the version qualifier every time — “514-byte cells,” unqualified, silently drops the fact that the number changed with the link protocol.
Inside a decrypted relay cell, the 509-byte body carries its own sub-structure: a 1-byte relay command, a 2-byte “recognized” field that reads as zero once a hop has correctly decrypted its layer (this is how a hop knows a cell was meant for it, rather than needing to guess), a 2-byte StreamID (zero for circuit-wide control messages like EXTEND2), a 4-byte running integrity digest, a length field, and padding to fill out the fixed size — tor-spec’s relay-cell layout spells out every field. The consequence of packing everything, from a one-byte command to a chunk of a streamed data payload, into the same fixed envelope: on the wire, every cell looks identical in size. An observer watching link traffic cannot distinguish an EXTEND2 control message from a chunk of streamed video by size alone.
That’s a real defense, and it’s worth being precise about what it defends against and what it doesn’t. Fixed cell size blunts packet-size fingerprinting specifically — one class of side channel, closed essentially for free at the wire-format level, with no extra round trips or bandwidth required. It does nothing for the harder problem: timing and volume correlation, where an adversary who can watch both ends of a circuit correlates the pattern of when and how much data moves, independent of packet size. Tor’s padding-spec layers circuit- and connection-level padding on top specifically to target that gap — a separate, more expensive mechanism, because it costs bandwidth rather than being free.
The talking point generalizes cleanly: map each specific observable signal — size, timing, volume, ordering — to the specific mechanism defending it, and assume gaps exist wherever you haven’t done that mapping explicitly. “We encrypt the payload” is not an answer to “is this side-channel-resistant”; size, timing, and volume are three separate signals with three separate (and separately expensive) defenses, and a system that closes only one of them has closed exactly one of them.
Guard, Middle, Exit: The Three Roles
The three-hop structure isn’t just a knowledge partition — it’s also an operational-risk partition, and relay selection is built around that. Relays advertise their bandwidth and uptime to the directory authorities, which assign flags — Guard, Exit, Fast, Stable, among others — based on measured properties, and consensus-published bandwidth weights bias path selection so that high-capacity, long-uptime relays carry proportionally more circuits. A relay needs sustained measured stability before it earns the Guard flag at all; a fresh, unproven relay is not eligible to be anyone’s entry point, which limits how quickly an attacker can stand up new relays and have them selected as guards.
The exit role carries a distinct operational and legal burden the other two don’t: exit traffic is the point at which decrypted (if the destination itself isn’t using TLS) application data re-enters the open internet under the exit operator’s IP address, meaning exit operators field abuse complaints and takedown notices that guard and middle operators essentially never see. That asymmetry is why volunteer exit capacity has historically been the network’s scarcest resource, and it’s a direct, structural consequence of where in the three-hop chain plaintext — if there is any — becomes visible again, not a policy quirk.
One hop-count precision worth stating plainly here rather than assuming: the three-hop, guard/middle/exit structure describes an ordinary client circuit reaching the regular internet. It is not a universal description of every Tor path. A connection to an onion service joins two independently built three-hop circuits at a rendezvous point — six relay hops end to end, with a different role structure on each side. Treat “Tor is three hops” as a description of one specific, common circuit type, not a blanket fact about the protocol.
Why Entry Guards Exist: From Statistical Certainty to Bounded Risk
If guard selection were uniformly random on every new circuit — the naive, “more secure because less predictable” design — the network would actually be more exposed over time, not less. This is the predecessor attack, formalized by Wright et al. and operationalized for Tor’s specific design by Elahi, Danezis, and Goldberg in Changing of the Guards (WPES 2012): an adversary running a fraction c/n of the network’s relays, given enough circuits built over enough time, will eventually — with probability approaching 1 — land as some client’s first hop. Because the first hop is structurally the one relay position that sees the client’s real IP address, “eventually becomes the guard for this client” is equivalent to “eventually deanonymizes this client’s guard-level exposure,” and with uniform random selection on every circuit, eventually is not a hypothetical — it’s a near-certainty that compounds with every additional circuit a client builds.
Tor’s fix inverts the intuition: instead of maximizing randomness, commit to a small, persistent guard set and keep it stable for weeks. If the persistent guard set doesn’t include a hostile relay, the client is safe for the duration the set is stable — a bounded, non-compounding risk. If it does include a hostile relay, that was already true from the moment the set was chosen, and it doesn’t get worse through repeated exposure the way random-per-circuit selection does. The random-per-circuit approach converts “small chance per trial” into “certainty across enough trials”; guard persistence converts it back into a single, bounded, one-time bet.
The engineering lesson is worth stealing anywhere an adversary wins by patient, repeated sampling: statelessness is not automatically the more secure design. It feels safer because it’s less predictable moment to moment, but against an adversary who can wait and resample, statelessness is exactly what lets small per-trial risk compound into near-certain eventual exposure. Adding state — commitment, persistence, stickiness — is sometimes the more secure choice precisely because it caps the number of independent trials the adversary gets, even though it looks, superficially, like giving up randomization.
The Directory Authorities and Hourly Consensus
None of the above works without an answer to a more basic question: in a network with no central operator, how does a client learn which relays exist, which ones are trustworthy enough to route through, and which ones just joined and haven’t been measured yet? Tor’s answer is a small, deliberately centralized bootstrap layer sitting inside an otherwise decentralized system: nine directory authorities, each independently measuring the relay population and publishing a signed vote once every hour. Votes are exchanged among the authorities, and any authority — or any client, using the same deterministic algorithm — computes the identical resulting consensus document. A consensus is only valid with signatures from more than half of the known authorities: a fixed-quorum, majority-signature model, spelled out in dir-spec’s consensus-computation section, governed as a small set of named, publicly accountable operators per the Tor Project’s directory-authority governance page (nine as of this writing — worth re-checking against that page, since the count can change).
This is a genuine trade-off, not an oversight, and it’s worth stating why the obvious “more decentralized” alternative loses. Fully peer-reported relay membership — every relay simply announcing itself, with no privileged validator — is trivially Sybil-attackable: an adversary who can spin up more relay identities than real ones can vote itself into majority control of the network’s own description of itself. Tor’s designers chose instead to concentrate bootstrap trust in a small, named, accountable set of operators who vote hourly and require majority agreement, rather than pretend that trust had been eliminated when it had only been hidden. It’s a deliberate centralization point inside a system that is otherwise, deliberately, decentralized traffic-wise.
The generalizable point: total decentralization and Sybil-resistance are frequently in tension, and a small, transparent, accountable trusted root is often the more honest engineering answer than architecting around a claim of “no trusted parties” that doesn’t actually hold up. Systems that market themselves as fully trustless while quietly depending on a bootstrap list, a genesis block, or a small validator set are making the same choice Tor made — the difference is only whether they say so as plainly as Tor’s spec does.
The Explicit Threat Model: What Tor Deliberately Does Not Defend Against
Everything above defends against a specific adversary, and Tor’s founding paper names that adversary with unusual precision. Section 3 of the 2004 USENIX paper states it directly: Tor is designed against “an adversary who can observe some fraction of network traffic; who can generate, modify, delete, or delay traffic; who can operate onion routers of his own; and who can compromise some fraction of the onion routers” — a local, partial adversary. The same section disclaims more than that, in the paper’s own words: “Tor does not claim to completely solve end-to-end timing or intersection attacks.”
That’s the honest core of the whole system, laid out as a table:
| Adversary capability | Covered by Tor’s threat model | Stated as out of scope |
|---|---|---|
| Observe some fraction of network links | Yes | — |
| Operate some fraction of relays | Yes | — |
| Modify, delay, or inject traffic on links it controls | Yes, within bounds | — |
| Observe essentially all traffic entering and leaving the network at once (a global passive adversary) | — | Yes, explicit since the 2004 paper |
| Correlate a circuit end-to-end via timing, once observing both ends | — | Yes — “Tor does not claim to completely solve” this (§3) |
A global passive adversary — one able to watch traffic simultaneously at both the point a client’s circuit begins and the point it exits — can, in principle, correlate the two ends by timing and volume alone, without breaking a single cryptographic primitive. That is not a secret flaw, a backdoor, or evidence the system is broken. It is a documented, named, published limitation, stated in the same paper that describes everything the system does defend, and it has been stated that way since 2004.
The best-documented real exercise of the in-scope part of that threat model — a well-resourced, local, partial adversary, not a global one — is the 2014 “relay-early” incident. Roughly 115 malicious relays, holding both Guard and HSDir roles, joined the network around January 30, 2014, and modified relay-cell headers to inject a traffic-confirmation signal against onion-service users and operators — at their peak, Tor’s own advisory put the malicious relays’ share of Guard capacity at 6.4%. Tor identified and removed them from the network on July 4, 2014, shipping a fix the same day in versions 0.2.4.23 and 0.2.5.6-alpha. A scheduled Black Hat 2014 talk describing similar deanonymization techniques, to be given by two Carnegie Mellon researchers, was abruptly cancelled beforehand. The Tor Project later stated, in its own public post, its belief that CMU had been paid approximately $1 million by the FBI for the underlying research — a claim neither the FBI nor CMU has ever officially confirmed or denied, and one that remains genuinely contested in public reporting to this day.
Reported honestly, the 2014 incident is exactly what a precisely stated threat model is for: a specific, dated, scoped attack by a resourced adversary operating within the model’s own stated bounds (running a fraction of relays, injecting signal on links it controlled), identified, measured, and patched — not a demonstration that the design’s premises were wrong. Most real-world Tor deanonymizations, in fact, trace to the browser or to operator error rather than to broken network cryptography: the FBI’s 2013 Freedom Hosting compromise (the “EgotisticalGiraffe” Firefox exploit) attacked the browser layer, not the onion-routing protocol, and cases like Ross Ulbricht’s are, on the public record, opsec failures — reused identifiers and correlated timestamps outside Tor — rather than a broken circuit.
This is the clearest place to land the transferable lesson: a precisely scoped, publicly stated threat model is a security asset, not a marketing liability. A system that says plainly “here is exactly what I defend against, and here is exactly what I don’t” gives its users an honest basis for risk decisions, and it gives its own engineers a stable definition of success — the 2014 incident is legible as “the stated model working as documented” precisely because the model was stated. Systems that market themselves as unconditionally “anonymous” or “unbreakable” collapse the first time any partial adversary succeeds at anything, because they never defined a boundary for what “secure” was supposed to mean in the first place. Publish the boundary. It’s more honest, and — as the relay-early episode shows — it also ages better under public scrutiny.
The Transferable Architecture Lesson
Pull back from the mechanics and one thread runs through every choice above: telescoped circuits reveal topology incrementally instead of all at once; entry guards trade randomization for bounded, stateful risk; fixed cells close one side channel cheaply and leave a documented gap for a more expensive mechanism to close separately; the directory authorities trade full decentralization for an honest, accountable trust root; and the threat model itself trades the appeal of an unconditional security claim for a precisely bounded, defensible one. None of these are compromises Tor’s designers were forced into by incompetence — they’re the same move, applied five times: make the boundary of what the system promises exactly as precise as the mechanism that enforces it, and no more precise than that.
And underneath all five sits the strangest one, the one worth carrying into any system you design that depends on a population of users rather than a population of one: Tor’s anonymity property is not purely a function of its cryptography. It is a function of its user population, and that meant the system’s security required deliberately giving away a technology developed to protect government communications to the general public — competing hackers, journalists, ordinary browsers, and yes, criminals, all mixed into the same anonymity set. “Anonymity loves company” is not a slogan bolted onto Tor after the fact. It’s the reason NRL’s own operational security depended on Tor having millions of non-government users, and it remains the sharpest available answer to the question every system with an anonymity or privacy property eventually has to face: anonymous with respect to whom, and does your actual user population make that claim true?
❓ Frequently Asked Questions
How does Tor actually work, at the protocol level?
A client builds a circuit through three relays — guard, middle, exit — negotiating a fresh session key with each one via the ntor handshake, then wraps traffic in three nested encryption layers, one per hop. Each relay strips exactly one layer and forwards the result; no relay ever holds both the client’s identity and the destination. Circuits are built incrementally (telescoped) via EXTEND2/EXTENDED2 messages rather than negotiated all at once, and everything travels in fixed-size cells (514 bytes on link protocol v4+, 512 legacy) so no cell’s size leaks what kind of message it is.
What does each relay in a Tor circuit actually know?
The guard sees the client’s real IP address but not the destination or payload (both still wrapped in two more encryption layers). The exit sees the destination and any application-layer plaintext but never receives the client’s identity. The middle relay sees neither endpoint — only the circuit IDs of its immediate neighbors. Knowledge is structurally partitioned by the layered-encryption design, not by any relay choosing not to look.
Why does Tor use persistent entry guards instead of picking a new relay for every circuit?
Because uniform-random relay selection on every circuit is provably worse over time: an adversary running a fraction of the network’s relays will, given enough circuits, eventually land as some client’s guard with probability approaching 1 — the predecessor attack, formalized in Changing of the Guards (WPES 2012). Committing to a small, stable guard set for weeks converts that compounding risk into a single bounded one: either the fixed guard set is compromised or it isn’t, and building more circuits doesn’t make it more likely.
Does Tor protect against a government-level adversary?
Against one that controls or observes only part of the network — some relays, some links — yes, that’s exactly the threat model Tor’s 2004 design paper states it defends against. Against a global passive adversary capable of watching traffic simultaneously at both ends of a circuit, Tor’s own founding paper is explicit that end-to-end timing correlation is not something it claims to fully solve. That’s a stated limitation, not a secret one, and it’s been in the design paper since 2004.
Is Tor the same thing as the “dark web,” or mostly used for illegal activity?
No, on both counts. Tor Browser routes ordinary web traffic through the network to reach the regular internet; onion services (.onion addresses) are a separate, minority use case, and averaging traffic share, service counts, and content sampling into one “percent criminal” figure conflates measurements that don’t measure the same thing. Tor Browser is also not “Onion Browser” — that’s a separate, third-party iOS app.
What’s the difference between the TAP and ntor handshakes?
TAP, Tor’s original circuit handshake, combined RSA-1024 with Diffie-Hellman and is now marked obsolete in-spec. ntor, the current standard since Tor 0.2.4.8-alpha (2013), uses Curve25519 ECDH with HMAC-SHA256, based on Goldberg, Stebila, and Ustaoglu’s provably secure one-way-authenticated key exchange construction. A newer variant, ntor-v3, and post-quantum hybrid handshakes both exist as specified proposals, but neither is the deployed default for ordinary circuits as of this writing.
📚 Further Reading
- DNS Security Issues, Vulnerabilities, and Exploits and What Is the Domain Name System? — the naming and trust-bootstrapping problem Tor’s own directory-authority consensus has to solve without a DNS-style root.
- The Best Books on Distributed Systems (Beginner to Expert) — for the consensus and fault-tolerance background behind the directory-authority design.
- Data and Goliath by Bruce Schneier and The Age of Surveillance Capitalism by Shoshana Zuboff — the surveillance-economics context that makes “anonymity loves company” more than an academic curiosity.
- Better Email Privacy and Security with ProtonMail and Encrypt and Secure Your Data — practical privacy tooling that pairs with network-layer anonymity.
- Understanding Internet Bandwidth for Engineers and Architects — the latency and throughput budget every extra encrypted hop spends against.
📚 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 canonical text on building systems that survive a real adversary rather than an imagined one — which is precisely the discipline that produced Tor’s published threat model. If this article’s closing lesson landed for you, Anderson is the thousand-page version of it.
Cryptography Engineering: Design Principles and Practical Applications
Niels Ferguson, Bruce Schneier & Tadayoshi Kohno · Book
The applied-cryptography grounding behind the ntor handshake and the layered encryption described above: key agreement, forward secrecy, and why protocols that look correct on a whiteboard fail in deployment.
Crypto: How the Code Rebels Beat the Government — Saving Privacy in the Digital Age
Steven Levy · Book
The history that explains why a government lab was building anonymity tools in the first place. Levy’s account of the crypto wars is the political backdrop to the technical story this article tells.
Free and worth more than any book here: the primary sources this article cites — the 2004 USENIX design paper and the Tor specifications at spec.torproject.org.