A Tor client builds a circuit of three relays: guard (entry), middle, and exit.

Each relay peels one layer of encryption (onion layers), learning only its predecessor and successor.

Circuit construction uses a telescoping key exchange: the client negotiates keys with each relay incrementally.

Guard nodes are persistent (used for weeks/months) to limit the adversary's chance of controlling the entry point.

A service publishes its descriptor (including introduction points) to a distributed hash table.

Clients use rendezvous points to connect without either party revealing their IP.

Both client and service build circuits to the rendezvous point, achieving mutual anonymity.

v3 onion addresses are 56 characters, encoding an Ed25519 public key.

Tor protects against local network observers and individual compromised relays.

It is vulnerable to global passive adversaries who can correlate traffic timing at both entry and exit. See Security Threats.

Tor does not protect against application-level leaks (e.g., DNS, browser fingerprinting).

I2P bundles multiple messages into encrypted "cloves" and sends them through unidirectional tunnels.

Separate inbound and outbound tunnels add path diversity.

Tunnels are rebuilt periodically (every 10 minutes) for forward secrecy.

Every I2P node is a router, distributing load across the network (unlike Tor where relays are opt-in).

Designed for internal services (eepsites, I2P torrents) rather than exit to the clearnet.

Network database (netDB): a Kademlia-like DHT for distributing router info and service lease sets.

Tor optimizes for exit traffic (browsing the clearnet anonymously) and has a larger, more researched network. 3-hop circuits provide reasonable latency.

I2P optimizes for internal services with unidirectional tunnels and universal participation. Higher latency but more resistant to certain traffic analysis attacks.

Both use layered encryption; Tor uses bidirectional circuits while I2P uses separate inbound/outbound tunnels.