Lecture 19: Anonymous Communication (Tor)

What this lecture covers

This is a guest lecture by Nick Mathewson, one of Tor's core developers, given after students read a Tor design paper. It defines anonymity precisely, then walks step by step from "we want Alice to be able to buy socks without being tracked" to the actual design of onion routing, circuits, and relays. It closes with practical problems Tor has faced in production: abuse, hidden services, and real attacks against the network.

It follows directly after the private browsing lecture and extends the same privacy unit into network-level anonymity. After watching, you should be able to define unlinkability and unobservability, explain why a single relay or a small anonymity set doesn't provide real protection, describe how Tor builds and uses circuits, and name some of the concrete attacks and design tradeoffs Tor deals with.

Key ideas

• Anonymity (technical sense): an observer cannot link a specific user to a specific action, categorically or even probabilistically better than random.
• Unlinkability: an attacker cannot connect a user's separate actions or pseudonymous activity into one long-term profile.
• Unobservability: an attacker cannot even tell that a user is active online at all; much harder to achieve than plain anonymity.
• Anonymity loves company: anonymity systems only protect users well if they have a large, shared user base; small user pools (like old remailer networks) provide little real cover.
• Onion routing: a message is wrapped in layers of encryption, one per relay, so each relay only knows the hop before and after it, not the full path.
• Circuits: Tor negotiates a symmetric key with each relay in a path and reuses that path (a circuit) for a session rather than doing expensive public-key crypto per message.
• Directory consensus: Tor avoids trusting a single directory server or an unverified peer-to-peer list by having multiple hardened authorities vote hourly and sign a consensus list of relays.
• Traffic correlation: Tor does not hide packet timing and volume; an attacker who sees both ends of a connection can often still correlate them statistically.

Walkthrough

Defining anonymity: unobservability and unlinkability (8:05)

Using an example of Alice buying socks while an eavesdropper Eve watches, the lecture distinguishes plain anonymity (Eve can't tell Alice bought socks, categorically or probabilistically) from unlinkability (Eve can't connect Alice to a long-term pseudonymous profile, like a blog written under a fake name) and unobservability (Eve can't even tell Alice is online). Unobservability is called much harder to build than the other two.

Motivations: why build Tor (11:07)

Mathewson explains Tor grew out of an unfinished research project and a belief that anonymity systems needed a real test bed to make progress, since waiting for research problems to be solved first would have meant waiting indefinitely. He discusses use cases beyond obvious privacy: companies protecting competitive data, researchers avoiding biased geolocation results, law enforcement avoiding tipping off investigation targets, and journalists or ordinary users avoiding harassment. He is direct that Tor is also used for illegal activity, and argues that a security tool unusable by criminals is usually a bad security tool.

Building anonymity step by step: from a single relay to onion routing (17:08)

The lecture builds Tor's design incrementally on the whiteboard. A single relay is not enough, since an eavesdropper can just watch that one machine. Adding many users through one relay helps but still trusts that relay fully. Adding TLS protects the links but the relay still knows both who is asking and what they asked for. The fix is multiple relays, each removing one layer of encryption, so no single relay sees both the source and the destination — classic onion routing, with a warning that timing and volume of traffic are not hidden by this scheme alone, which is why systems like mix networks trade latency for stronger protection (a tradeoff Tor deliberately does not make, since it targets everyday web browsing).

How Tor's circuit protocol works (27:23)

A detailed walkthrough shows Alice negotiating a symmetric key with the first relay via a create cell, then extending the circuit to a second relay via a relay extend cell encrypted so only that next relay can read it. Each relay only knows its own circuit ID and neighbor, not the full path. The lecture explains why Tor carries TCP stream contents rather than raw IP packets (avoiding the need for an IP normalization layer, since different OS TCP stacks are trivially fingerprintable) and why it avoids protocol-specific proxies, since end-to-end encryption from the user's application to the destination means anonymizing transformations must happen in the application, not a proxy.

Node discovery and abuse (46:38)

The lecture traces why Tor settled on multiple hardened directory authorities that vote hourly and sign a consensus, rejecting a hardcoded node list (doesn't scale), a single trusted directory (single point of failure), and unverified peer gossip (vulnerable to route-capture attacks where one relay lies about the network). On abuse, exit policies restricting ports turned out not to stop abuse (any port can carry abusive traffic) but did let more operators volunteer to run limited exits. The deeper problem is that many sites use IP-based blocking against abusive users, and this frequently gets all Tor users banned; blind signatures and anonymous blacklistable credentials are discussed as partial, still-immature fixes.

Hidden services and attacks and defenses (55:46)

Hidden services solve "responder anonymity" — publishing content without revealing the server's location — by having the service build circuits to several relays, register a public key with a directory system, and let clients connect through those relays without ever learning the service's real IP. The lecture also covers real attacks: unencrypted application traffic being the most common attack surface, a traffic-tagging flaw in early integrity checking, memory-exhaustion ("sniper") attacks against relays, and a serious bug where Tor's Diffie-Hellman implementation failed to reject degenerate values like zero, which would let an attacker force a known shared key.

Before you watch

• Read (or at least skim) the Tor design paper assigned for this lecture; the talk assumes familiarity with it and references specific sections.
• Review the private browsing lecture's discussion of IP-based identification, since this lecture treats Tor as a complementary layer that addresses IP anonymity but not fingerprinting.

Check your understanding

1. What is the difference between unlinkability and unobservability, and why is the second one harder to achieve?
2. Why does "anonymity loves company" mean that a small anonymity network can fail to protect its users even without any flaw in its cryptography?
3. Walk through why Tor uses layered relays with per-hop encryption instead of a single trusted relay.
4. Why did Tor reject both a single trusted directory server and unverified peer-to-peer node discovery?
5. Why is unencrypted application traffic described as the single biggest practical attack on Tor users?