What Is Tor and How Does It Actually Work?

How does Tor work? Tor wraps your internet traffic in three layers of encryption and bounces it through three volunteer-run relays, so no single point ever sees both who you are and what you’re doing. The first relay (the guard) sees your real IP address but not your destination; the last relay (the exit) sees your destination but not your IP; the middle relay sees neither. Each relay peels off exactly one encryption layer — like unwrapping the layers of an onion — which is why it’s called The Onion Router. The result is anonymity built not on trusting one company, but on splitting trust across three independent strangers who would all have to collude to unmask you.

That’s the short answer. The mechanism underneath is more elegant — and more limited — than most explanations admit, so let’s take it apart layer by layer, including what Tor genuinely cannot protect you from.

What does “onion routing” actually mean?

In plain terms: instead of sending your data straight to a website (where your internet provider and the site both see your real address), Tor sends it on a detour through three computers, encrypting it in nested layers so each computer can only see one step of the journey.

The analogy that gives Tor its name: imagine putting your message inside three nested envelopes. The outermost envelope is addressed to the guard relay. Inside it is a second envelope addressed to the middle relay. Inside that is a third envelope addressed to the exit relay, and only inside the innermost envelope is the actual request for the website you want. Each relay can open only its own envelope, find the address of the next hop, and pass the still-sealed inner package along. No relay ever sees the whole set of envelopes at once.

The real cryptography matches the metaphor closely. When your Tor client builds a circuit, it negotiates a separate encryption key with each of the three relays. Your data is then encrypted three times — first with the exit’s key, then the middle’s, then the guard’s. As the data travels forward, each relay strips off exactly one layer of encryption with its own key, revealing only the address of the next relay. This is symmetric (shared-key) encryption applied in layers, not a single end-to-end tunnel.

The crucial property: each relay knows only the previous hop and the next hop, never the full path. That single design choice is what makes Tor anonymous.

What does each relay (guard, middle, exit) see?

A standard Tor circuit has three relays, each run by a different volunteer, each seeing a deliberately incomplete picture:

• Guard / entry node — sees your real IP address (it’s the relay you connect to directly) but has no idea what site you’re visiting, because the destination is buried under two more layers of encryption it can’t peel.
• Middle node — sees neither your IP nor your destination. It only knows “data came from this guard, send it to that exit.” It exists purely to keep the guard and exit from ever talking directly and comparing notes.
• Exit node — sees the destination you’re contacting and the content of your request (after the last Tor layer is removed), but has no idea who you are, because it only ever saw traffic arriving from the middle node.

So the question “can a relay deanonymize me?” answers itself: no single relay can, because no single relay holds both ends of the link. You’d need an adversary who controls (or can watch) both your guard and your exit at the same time — which is exactly the weakness we’ll return to later.

One detail people miss: the exit-to-website hop is not protected by Tor’s encryption. Tor’s layers all come off at the exit. From the exit node to the actual website, your traffic is only as private as the site’s own HTTPS. If you log into a non-HTTPS site over Tor, the exit operator can read your credentials. Tor anonymizes where the traffic comes from; it does not encrypt the final delivery. This is why Tor Browser pushes HTTPS so aggressively and why you should never enter a password on a plain http:// site over Tor.

Circuits are also short-lived — by default Tor stops attaching new connections to a circuit after about ten minutes, so even a relay that does observe you only sees a roughly ten-minute slice of activity that’s hard to link to the next slice.

How does Tor pick its relays — and what’s a guard node really for?

This is the layer most “how does Tor work” explanations skip, and it’s where Tor goes from “neat idea” to “actually secure.”

Your client doesn’t pick relays at random off the open internet. A small set of trusted directory authorities vote roughly every hour to publish a signed document called the consensus — the canonical list of all relays, their cryptographic keys, their measured bandwidth, and flags describing what each is trusted to do. Every Tor client downloads this same consensus, so everyone shares one consistent view of the network. The network runs on several thousand volunteer relays at any given time (the live count fluctuates daily — see Tor Metrics for the current figure), and the consensus is what turns that swarm into a usable directory.

Relay selection within a circuit is random but weighted by measured bandwidth: faster relays carry proportionally more traffic, which keeps the network balanced. Exit selection is further constrained by each relay’s exit policy — many relays refuse to act as exits at all, or only allow certain ports.

The subtle part is entry guards. Instead of choosing a fresh first hop for every circuit, your client picks a small, persistent set of guard relays and sticks with them for an extended period. Why? Statistics. If you chose a random first hop every single time, then over enough circuits you’d eventually pick a hop run by an attacker — and an attacker who controls your entry and can also see your exit can correlate the two and unmask you. By keeping the same few guards for a long time, you make that catastrophic event either happen immediately (if your guard is bad) or never (if it’s good), rather than becoming a near-certainty over time. Earning the guard flag requires sustained high uptime, sufficient bandwidth, and a track record — it’s not handed out lightly. RVNT’s threat model leans on the same distributed-trust logic; see our threat model for what that lets us promise and what it doesn’t.

How do .onion addresses and onion services work?

Everything above hides you, the client. Onion services (the .onion addresses you’ve heard about) hide the server too — neither side learns the other’s IP address or physical location.

The plain version: a .onion site doesn’t publish an IP address anywhere. Instead, both you and the server meet at a neutral relay in the middle, each having traveled there through your own anonymizing path, so neither end knows where the other actually lives.

The mechanism, in order:

1. The .onion address is derived directly from the service’s public key (modern v3 addresses are 56 characters, based on ed25519). The address is the key — which is why onion addresses look like random gibberish and why they’re self-authenticating: there’s no certificate authority to trust, because connecting to the address cryptographically proves you reached the right server.
2. The service picks several introduction points and publishes a signed descriptor announcing them (via a distributed hash table).
3. To connect, your client picks a rendezvous point and sends a one-time secret to the service through one of its introduction points.
4. The service connects out to your chosen rendezvous point.
5. Both sides now talk end-to-end encrypted through the rendezvous point, which relays sealed cells and learns neither party’s identity.

Because each side builds its own multi-hop path to the meeting point, an onion-service connection involves roughly six relays total — slower, but with location privacy for both ends. Major newsrooms, including outlets that publish through SecureDrop, run .onion mirrors precisely so sources can reach them without leaving a network trail.

Is Tor the same as a VPN? Should I use both?

No — they solve different problems with opposite trust models, and conflating them is the most common Tor misconception.

	VPN	Tor
Who you trust	One company	~3 independent volunteers per circuit
Who sees your real IP	The VPN provider	Only your guard relay
Who sees your destination	The VPN provider	Only your exit relay
Can one party link both ends?	Yes (the provider)	No single relay can
Speed	Fast	Much slower
Best for	Everyday privacy, geo-unblocking	High-assurance anonymity, censorship circumvention

A VPN is a single company that sees both your real IP and everything you do — you’re trading “my ISP sees me” for “my VPN sees me.” That can be a fine trade for routine privacy, and it’s fast. Tor’s entire point is that no single party ever sees both ends. That distributed trust costs you a lot of speed (your traffic is crossing three volunteer relays, often on different continents), which is the honest answer to “why is Tor slow?”

Should you stack them? Usually not necessary, and “Tor over VPN” mostly just means your VPN provider — instead of your ISP — learns that you use Tor. Unless you have a specific reason (for example, your network blocks Tor entirely), the Tor Project’s general guidance is that adding a VPN does not improve Tor’s anonymity and can introduce its own risks.

Is Tor legal, and is it safe to use?

In nearly every jurisdiction, downloading and running Tor is completely legal. Tor is privacy software used daily by journalists, human-rights workers, researchers, businesses protecting sensitive communications, and ordinary people who simply don’t want to be tracked. Only specific activities done over Tor can be illegal — the same as with any internet connection. A handful of authoritarian states actively block or restrict Tor, which is a censorship signal, not a legality one.

A few more myths worth retiring:

• “Tor is the dark web.” The .onion services are one feature of Tor, not its purpose. Most Tor traffic is people reaching the ordinary, public internet anonymously.
• “The dark web is most of the internet.” This confuses the deep web (any unindexed page — your bank statements, paywalled articles, private databases; genuinely enormous) with the dark web (onion services), which is a tiny fraction of the web.
• “Tor is peer-to-peer.” It isn’t. Tor is a relay/overlay network of dedicated volunteer-run servers — structurally nothing like BitTorrent. (RVNT, by contrast, is peer-to-peer for message content, and uses Tor purely as the anonymizing transport layer — two different jobs.)

Can you actually be tracked on Tor?

Yes, under specific conditions. Tor dramatically raises the cost of deanonymization, but “raises the cost” is not “makes it impossible,” and honest privacy writing has to say so.

The real weaknesses:

• End-to-end traffic correlation. An adversary who can simultaneously observe traffic entering your guard and leaving your exit — for instance, a state-level actor watching many network chokepoints, or someone running a large fraction of relays — can statistically correlate the timing and volume of packets to link you to your destination. This is the fundamental limit of low-latency anonymity networks, and Tor does not claim to defeat a global passive adversary who can watch everything everywhere at once.
• Malicious exit nodes. An exit operator can read or tamper with unencrypted (non-HTTPS) traffic passing through them. HTTPS defeats reading the content, but the destination is still visible to the exit by design.
• User-side leaks. This is how most real-world Tor deanonymizations actually happen — not by breaking the crypto, but by the user breaking their own anonymity: enabling JavaScript or browser plugins that leak identifying data, logging into a personal account, browser fingerprinting, or running BitTorrent outside Tor (which leaks your real IP).

This is also where the most important honesty point lives, and it applies to RVNT every bit as much as to Tor: anonymity at the network layer does nothing if your own device is compromised. Malware or a keylogger on your endpoint sees everything before Tor ever touches it. No overlay network protects you from a contact who screenshots your conversation, from shoulder-surfing, or from a legal order served on the person you’re talking to. Name the limits, or you’re selling snake oil.

Tor Browser is the practical tool for most of this: a hardened Firefox ESR fork with anti-fingerprinting built in and three security levels — Standard, Safer, and Safest (which disables JavaScript). Using the official Tor Browser, rather than forcing a random browser through a proxy, is what keeps the user-side leaks closed.

What’s new in Tor (2025–2026)?

Tor is not standing still, and two developments are worth knowing.

Counter Galois Onion (CGO) is a new relay-encryption scheme the Tor Project announced in November 2025, designed to replace Tor’s legacy “tor1” algorithm. The old scheme used a weak 4-byte SHA-1 digest and was vulnerable to tagging (malleability) attacks, where an adversary controlling entry and exit could mark a cell and recognize it later. CGO uses a wide-block construction — tamper with any part of a cell and you destroy that cell and all future cells on that circuit — adds forward secrecy within a circuit, uses a 16-byte authenticator, and removes SHA-1 from relay encryption. Important caveat: CGO is being rolled out, not yet enabled by default. It is implemented in both Arti and the legacy C Tor, and the project plans to make it the default only once testing is complete. Don’t believe anyone who tells you it’s already universal.

Arti is Tor’s ground-up rewrite of the client in Rust (memory-safe by construction). It now ships in a 2.x series — the latest releases landed in the first half of 2026 — but the rewrite is not finished: as of mid-2026 Arti still cannot run as a Tor relay, and relay plus directory-authority support are the remaining milestones before the original C implementation can eventually be retired. The work is in progress, not done. Alongside it, Conflux splits traffic across multiple circuits for better throughput, anti-censorship transports like Snowflake and obfs4 keep Tor reachable in countries that block it, and the Tor Project released an experimental Tor VPN beta for Android in 2025 (early-access, explicitly not for high-risk users yet).

The Arti rewrite is directly relevant to RVNT: we embed arti — the Rust Tor implementation — as our transport layer, so RVNT traffic rides 3-hop Tor by default and 5-hop in max-privacy mode, with a mixnet on top. We chose the Rust implementation specifically for the memory-safety guarantees that motivated Arti in the first place. You can read how we layer it in our Tor integration docs and mixnet design.

The takeaway

Tor’s genius is structural, not magical: by splitting your path across three independent relays and wrapping it in layered encryption, it ensures no single point ever knows both who you are and what you’re doing. That buys real, meaningful anonymity — and it stops exactly at the edges Tor was never designed to cover: the exit-to-site hop, your own device, a contact who betrays you, and a global adversary watching every wire. Understanding both halves — the protection and the limits — is what separates using Tor wisely from trusting it blindly. Don’t trust us, or Tor; verify how each one works, then decide what it’s good for.