How Onion Routing Works

Onion Routing: The Layered Encryption Model

Onion routing gets its name from the structure of its encryption: concentric layers, each removable only by its designated relay. When a Tor client builds a circuit, it negotiates a symmetric encryption key with each of three relays independently using a Diffie-Hellman key exchange. The message is then encrypted three times — first with the exit relay's key (innermost layer), then the middle relay's key, then the guard node's key (outermost layer).

Each relay receives a packet, decrypts its layer using the negotiated key, and forwards the result to the next hop. The guard node decrypts the outermost layer and sees the middle relay's address. The middle relay decrypts the next layer and sees the exit relay's address. The exit relay decrypts the final layer and sees the destination. At no point does any relay have access to both the originating IP and the final destination.

This is the property that makes onion routing useful for privacy: compromise of any single relay reveals only one hop in the chain, not the full path. Compromising two relays reveals more, but still not the full picture unless the attacker controls both the guard and the exit (or rendezvous point) simultaneously.

Onion Routing Circuit Construction in Tor

Tor onion routing builds circuits incrementally through a process called telescoping. The client first establishes a TLS connection to the guard node and negotiates an encryption key. Through that encrypted channel, it reaches the middle relay and negotiates a second key. Through both encrypted channels, it reaches the exit relay and negotiates a third key.

This telescoping process means the middle relay never communicates directly with the client. It receives encrypted traffic from the guard and forwards it to the exit. From the middle relay's perspective, traffic appears to originate from the guard. This is the mechanism by which onion routing prevents any single relay from reconstructing the full path.

Guard node selection is not random across the full relay set. Tor clients choose a small number of guard nodes and reuse them for 2-3 months. The rationale is counterintuitive: rotating guards frequently increases the probability of eventually selecting a malicious guard. Keeping a single (hopefully honest) guard for months limits exposure. This design was formalized after analysis published in the Tor path selection research showed that frequent rotation made statistical traffic confirmation attacks more practical.

Onion Network Layers and v3 Addressing

The onion network layers differ between v2 (deprecated) and v3 onion services. V3 addresses, now standard since 2021, use ed25519 public keys with SHA-3 hashing to produce 56-character addresses. The address itself is derived from the service's public key — meaning the address IS the public key, encoded. This is a fundamental property: connecting to a v3 .onion address implicitly verifies you are communicating with the holder of the corresponding private key.

V2 addresses used 16-character identifiers derived from RSA-1024 keys, which are now considered cryptographically weak. The deprecation of v2 was not cosmetic. RSA-1024 key factoring had become feasible for well-resourced attackers by 2020, making v2 onion address impersonation a realistic threat. V3's ed25519 keys provide approximately 128 bits of security, placing the impersonation cost well beyond current computational feasibility.

The onion service protocol also involves introduction points and rendezvous points. An onion service publishes its availability through introduction points (relays that agree to relay initial contact). A client wanting to connect selects a rendezvous point and sends its address to the introduction point, encrypted with the onion service's public key. The onion service connects to the rendezvous point, and the two parties establish an end-to-end encrypted session. Neither the introduction point nor the rendezvous point learns both parties' identities.

Tor Onion Routing vs. VPN Tunneling

Tor onion routing and VPN tunneling solve different problems, and conflating them is a common source of misplaced trust. A VPN encrypts traffic between the user and a single server operated by the VPN provider. The provider can observe all traffic metadata and, depending on jurisdiction and logging policy, may be compelled to hand it over.

Onion routing distributes trust across three independently operated relays. No single operator sees the full picture. The tradeoff is performance: Tor's multi-hop architecture adds latency (typically 200-800ms round-trip) that a single-hop VPN does not. For latency-sensitive applications, VPN wins. For threat models where the adversary is the network itself (ISP, national firewall, local network operator), onion routing provides stronger guarantees because it removes the single point of trust that VPN architecture requires.

Running Tor over a VPN (connecting to the VPN first, then launching Tor Browser) hides Tor usage from the ISP but shifts trust to the VPN provider, who now knows the user is connecting to Tor. Running a VPN over Tor (routing VPN traffic through Tor) is technically possible but defeats the purpose of both tools in most configurations. The Tor Project's documentation does not recommend either combination for most users.

Onion Routing Encryption Explained: Threat Model Boundaries

Onion routing encryption is effective against passive surveillance (traffic monitoring) and moderate active attacks (injecting or redirecting traffic). The documented failure modes involve attackers who control multiple relays or who combine traffic analysis with external information.

Traffic confirmation attacks are the most studied threat. If an attacker controls both the guard node and the exit relay (or rendezvous point), they can correlate timing patterns of packets entering and leaving the circuit to confirm that two endpoints are communicating. This does not require decrypting any content — packet timing alone is sufficient. The academic literature on this attack type is extensive; Murdoch and Danezis's 2005 IEEE Symposium paper on low-cost traffic analysis of Tor remains foundational.

The defense against traffic confirmation is statistical: with over 7,000 relays in the Tor network as of 2026, the probability of an attacker controlling both the guard and the exit/rendezvous relay for any given circuit is low. But "low" is not "zero." For high-security use cases, the recommended mitigation is to verify .onion addresses through out-of-band channels (such as PGP-signed canary statements) rather than relying solely on circuit-level security. For the full practical guide to that verification process, see our PGP verification guide. For how to use Tor Browser at the correct security level, see what is Tor Browser.

This is why verification resources that document verified .onion endpoints through PGP signature validation add a layer of trust that onion routing alone cannot provide. The network protects anonymity. Cryptographic verification protects authenticity. They are complementary, not redundant.