Chapter 17: Anonymous Communication Networks

"We kill people based on metadata."

Michael Hayden, panel discussion, Johns Hopkins University (2014)^1^

Introduction

Chapter 14 established cryptographic foundations. Encryption protects the content of communications. But encryption alone is insufficient for privacy.

The problem is metadata: information about communications, not their content. Who communicates with whom, when, how often, and for how long reveals patterns that surveillance can exploit. Even with perfect content encryption, metadata enables full monitoring of social networks, political associations, and personal relationships.

This chapter examines architectural solutions to the metadata problem at two layers. At the transport layer, VPNs, Tor and I2P, and mixnets each offer a different point on the latency-anonymity tradeoff. At the application layer, a sequence of encrypted-messaging protocols from PGP through Signal to MLS has progressively strengthened what end-to-end encryption protects and what it still leaks. Neither layer solves the problem alone; the two compose.

17.1 The Problem: How the Internet Leaks Privacy

IP Addresses: Built-In Identifiers

The Internet Protocol was designed for reliability, not privacy. Every packet contains the sender's IP address in plaintext, visible to every router along the path. The exposure is not a bug but a fundamental design choice: the network and the remote endpoint need source information so replies can find their way back.

Your IP address is an identifier. It connects to your approximate physical location and your internet service provider, which in turn connects to your legal identity through subscriber records. Every website you visit, every service you connect to, receives your IP address. They know where you are connecting from, and with additional records or account linkage they may infer who you are.

Even when content is encrypted, the IP header is not. HTTPS hides what you read on a website; it does not hide that you connected. Your ISP reliably sees that you are communicating and to which IP addresses or network providers; it often also sees the destination domain through DNS or TLS metadata, though encrypted DNS and ECH can reduce that visibility. Network observers along the path see source and destination IP addresses on every packet.

Metadata: The Full Picture

Metadata is data about data. For communications, metadata includes who (sender and recipient identifiers such as email addresses, phone numbers, and IP addresses), when (timestamps of communications), how long (duration of calls, size of messages), how often (frequency of communication between parties), and where (location data from devices). Content encryption hides what was said. Metadata reveals everything else.

Hayden's statement that "we kill people based on metadata" is not hyperbole.^1^ Communication patterns alone reveal social structure (who the leaders and intermediaries are), behavioral shifts (a sudden spike or silence signalling planning or operation), physical movement through device metadata, and association with known targets. Intelligence agencies have acknowledged using this information for targeting decisions.

Why Content Encryption Is Insufficient

Consider encrypted messaging between two parties. An observer who cannot read the messages still sees that Alice and Bob communicate, how frequently they communicate, when they communicate (times of day, days of week), how their communication patterns change over time, and who else each party communicates with.

Such information suffices for surveillance purposes in many contexts. Knowing that a journalist communicates frequently with a particular government official is valuable intelligence regardless of message content.

Traffic Analysis

Traffic analysis is the systematic exploitation of metadata. Timing correlation observes that if Alice sends a message at 2:03:47 and Bob receives one at 2:03:48, they are probably communicating, even if the content is encrypted and the route is indirect. Volume correlation matches message sizes across network hops to link sender and receiver. Pattern analysis identifies regular communication patterns (every Tuesday at 3pm) that reveal relationships even without content. Network flow analysis follows traffic through network infrastructure to reveal endpoints even when individual hops are encrypted. Traffic analysis works because communication must traverse physical infrastructure that can be observed.

17.2 Requirements for Anonymous Communication

Formal Properties

Anonymous communication systems aim to provide several properties, each addressing different aspects of the metadata problem.

Sender anonymity means observers cannot determine who sent a message, so that even if the content is known, the originator remains hidden. This property protects whistleblowers and anyone whose speech might invite retaliation. Receiver anonymity means observers cannot determine who received a message. The intended audience is hidden, protecting recipients from association with senders who may be targeted.

Unlinkability means observers cannot determine that a particular sender and receiver are communicating with each other. Even if both parties are known to use the system, connecting their activity defeats surveillance that relies on mapping relationships. Unobservability means observers cannot determine that a communication is occurring at all. The communication is hidden among other traffic or cover activity. This is the strongest property because it hides the fact of communication itself.

These properties have different strengths depending on the adversary model. Against a local observer (seeing only part of the network), weaker protections may suffice. Against a global adversary (seeing all network traffic), stronger protections are required. The design choice reflects expected threats: journalists in authoritarian regimes face different adversaries than users seeking privacy from advertisers.

Adversary Models

The strength of an anonymity system depends on assumptions about the adversary it is designed against. A passive adversary observes traffic without modifying it, collecting data and attempting identification through pattern correlation. An active adversary can inject, delay, drop, or modify messages. They might run their own nodes in the network or perform timing attacks by introducing deliberate delays to force users into identifiable behavior.

The local adversary sees only a portion of the network: the user's connection to their ISP, or traffic through a single relay. The global adversary sees all network traffic simultaneously. This is the most powerful model, as it enables end-to-end timing correlation that no amount of encryption can prevent without additional countermeasures.

Realistic threat modeling starts from who the likely adversary is. Most users do not face nation-state adversaries. But systems designed only for weak adversaries fail catastrophically when stronger ones appear. The cypherpunk approach builds systems that resist the strongest plausible adversaries, recognizing that capabilities expand over time.

The Anonymity Set

Anonymity is relative to an anonymity set: the group of possible senders or receivers among whom the actual party cannot be distinguished. This is the fundamental measure of anonymity strength.

If the anonymity set contains only three people, the adversary has a 1-in-3 chance of correct identification. If it contains millions, the odds improve correspondingly. The mathematics are simple: anonymity depends on who else is using the system.

Anonymity sets depend on who else is using the system at the same time. This creates a collective action dynamic: the more users, the stronger the anonymity for each user. A system with few users provides weak anonymity regardless of cryptographic strength. A system with many users can provide strong anonymity even with simpler cryptography.

This dynamic explains why adoption matters as much as technology. Privacy tools benefit from broad adoption. Early adopters sacrifice some anonymity to bootstrap the system; later adopters benefit from the anonymity set the pioneers created. The collective action problem also creates vulnerability: if adversaries can reduce adoption (through legal pressure or stigmatization), they weaken anonymity for remaining users.

Cover Traffic and Dummy Messages

Some systems introduce cover traffic, which is fake messages indistinguishable from real ones. Cover traffic serves several purposes at once: it maintains consistent traffic volume regardless of actual usage, which defeats volume analysis, and it creates activity even when users are idle, making timing analysis harder. It expands the effective anonymity set by including dummy messages among possible "real" messages.

Cover traffic has costs. Bandwidth consumption increases, as dummy messages consume the same resources as real ones. Latency may increase if systems wait to batch real and dummy traffic. Complexity increases, since distinguishing cover from real traffic must be impossible for observers but possible for recipients.

The design choice depends on threat model. Against passive local adversaries, cover traffic may be unnecessary overhead. Against active global adversaries, it may be essential for effective protection.

17.3 VPNs: A Simple but Limited Solution

What VPNs Provide

VPNs (Virtual Private Networks) are the simplest approach to hiding an IP address. They encrypt traffic between the user and the VPN provider's server, which then forwards it to the destination. The local network segment is protected against observers such as coffee shop WiFi operators, the ISP cannot see final destinations even though it still sees the VPN connection itself, and destinations see the VPN server's IP instead of the user's. For many users, this is enough. If the concern is an ISP logging browsing history or a network operator sniffing traffic, a VPN addresses the immediate problem.

Trust Concentration and Its Consequences

A VPN does not eliminate surveillance; it relocates it. The VPN provider knows the user's real IP address and sees all traffic destinations. The surveillance has moved from the ISP to the VPN provider. If the provider logs traffic or cooperates with authorities, the user has no protection. Websites still see cookies and behavioral fingerprints that identify users regardless of the IP address the packets carry. Unlike multi-hop systems, VPNs concentrate trust in a single commercial entity, and compromise of that entity compromises everything that flowed through it.

The trust model is also structurally opaque. VPN providers make claims about logging policies that users cannot verify. "No logs" claims have been contradicted when providers have turned over data to authorities, and users have no way to audit provider practices independently. Even well-intentioned providers can be compelled by legal process to begin logging, acquired by less privacy-respecting companies, or breached. The user must trust not only the provider's current stance but its future behavior under pressure it has not yet faced.

Some providers offer multi-hop configurations that route traffic through two or more servers, and users can chain VPNs manually by connecting to provider A and then through that connection to provider B. Provider A sees the real IP but not the destination; provider B sees the destination but only provider A's IP. Multi-hop VPNs remain weaker than Tor: the pool of providers is small compared to Tor's thousands of relays, the providers are commercial entities with known identities that are easier to pressure than pseudonymous relay operators, a single provider often controls multiple hops in its own "multi-hop" offering, and VPN configurations tend to be static where Tor circuits rotate. Single-hop VPN improves the path, but a purpose-built anonymity network distributes trust across a larger and less concentrated relay set.

Where the Trust Model Holds

The VPN trust model holds when the threat is local and the provider is outside the threat model. Protecting against ISP logging or public WiFi sniffing falls within that boundary, and for those threats a VPN does real work at low friction.

The model breaks when the adversary can reach the provider. Anonymity against a state that can subpoena the provider, protection from the provider itself, and any activity where concentrating trust in a single commercial entity is unacceptable all exceed what VPNs can deliver. The architecture determines the boundary, and no choice of provider changes it.

17.4 Onion Routing: Tor and I2P

The Core Insight: Distribute Trust

The fundamental weakness of VPNs is that one entity sees everything. Onion routing solves this by distributing trust across multiple relays. No single relay knows both who you are and what you are accessing.

Tor: Architecture and Operation

Tor (The Onion Router) is the most widely used anonymous communication system.^2^ It uses layered encryption where each layer is decrypted by successive relays.

The user's Tor client builds a circuit through three relays: a guard (entry) node, a middle node, and an exit node. The client knows all three; each relay knows only its neighbors. The message is encrypted three times, once for each relay; the guard decrypts the outer layer and forwards to middle, middle decrypts and forwards to exit, exit decrypts and forwards to destination. No individual relay knows both origin and destination: the guard knows the user but not the destination, the exit knows the destination but not the user, and the middle knows neither. This architecture means that one compromised relay does not automatically give an adversary a complete end-to-end view, though malicious relays still learn position-specific metadata. An adversary generally needs multiple vantage points or auxiliary attacks to link user to destination.

Tor Network Economics

Tor operates through volunteer relay operators who donate bandwidth and computing resources, and the incentive structure relies on self-interest combined with ideological commitment. Some operators need Tor themselves and contribute to the network they use; others operate relays to support freedom of communication as a matter of principle. Some relays are operated by organizations such as universities and privacy advocacy groups as part of their institutional missions. This volunteer model creates sustainability challenges. Exit relays face particular burdens: abuse complaints and legal exposure. The network has consistently struggled with insufficient exit capacity.

Tor Limitations

Tor has well-documented limitations, and real-world attacks have showed these vulnerabilities.^3^

Timing attacks allow a global adversary observing both ends of a circuit to correlate timing and link sender to receiver; Tor does not protect against adversaries who can monitor traffic at both entry and exit points. Traffic analysis can reveal information from patterns in circuit usage even without breaking encryption. Website fingerprinting attacks analyze the size and timing patterns of encrypted traffic to identify which websites a user visits; research has achieved over 95% accuracy in controlled settings when monitoring a small set of popular websites, though real-world effectiveness remains debated.^4^

Exit node vulnerabilities exist because exit nodes see unencrypted traffic to destinations unless the destination uses HTTPS, allowing malicious exit operators to observe and modify unencrypted traffic. Guard node compromise is particularly serious because Tor users maintain the same guard nodes for extended periods; an adversary who controls a user's guard sees all their Tor traffic entering the network, and combined with exit observation or website fingerprinting, guard compromise can materially increase deanonymization risk.

Documented deanonymization attacks have succeeded against Tor users, though the Tor Project's ongoing maintenance has addressed many specific vulnerabilities. In Operation Torpedo (2012), the FBI deployed malware through compromised onion services to unmask users by exploiting browser vulnerabilities.^5^ The 2013 Freedom Hosting attack used similar techniques.^30^ Both attacks exploited browser plugins (particularly Flash) that Tor Browser now disables by default; the specific vulnerabilities were patched. In 2014, researchers (allegedly from CMU/CERT) operated over 100 malicious relays comprising 6.4% of guard capacity, using a "relay early" traffic confirmation attack to deanonymize onion service users; The Tor Project discovered the attack and patched the "relay early" vulnerability in July 2014, ejecting the malicious relays.^6^

These historical attacks illustrate an important pattern: Tor undergoes continuous security review and improvement. Specific implementation vulnerabilities, when discovered, are typically patched promptly. The attacks that succeeded exploited bugs that no longer exist. What remains are structural limitations inherent to Tor's low-latency design: timing correlation by global adversaries, traffic analysis, and website fingerprinting cannot be fully eliminated without different architecture. Users should distinguish between historical exploits (largely fixed) and structural constraints (inherent to the design).

Nation-states have also showed sophisticated capabilities for detecting and blocking Tor bridges, the unlisted entry points designed to circumvent censorship. China, Iran, and Russia have implemented bridge-blocking with varying degrees of success. Sybil attacks, where an adversary creates many pseudonymous identities to gain disproportionate influence over a network, allow adversaries operating many relays to increase their chance of being selected for circuits, improving attack capabilities.

Performance suffers because multi-hop routing increases latency; Tor is slower than direct connections, sometimes substantially. Usability remains challenging; Tor is harder to use than ordinary browsing, and users make mistakes that compromise anonymity.

Tor's directory authority system is a point of centralization.^31^ Ten directory authorities vote regularly to produce the network consensus document that lists all relays and their trustworthiness. Clients download this consensus to build circuits. The directory authorities themselves are known entities with stable identities, operated by trusted community members and organizations. While compromise of a single authority has limited impact due to the voting mechanism, the system as a whole depends on this small group remaining honest and uncompromised. This is a pragmatic design choice: fully decentralized consensus is difficult for relay discovery, and the directory authority model has worked adequately. But it differs from the fully trustless models that some systems aspire to.

Tor provides strong protection against many adversaries, but well-resourced states can still disrupt access, block bridges, and improve their attack position by operating infrastructure or correlating traffic.

Onion Services: Censorship-Resistant Publishing

Tor's best-known use is anonymizing outbound connections: users access regular websites without revealing their identity. But Tor also enables the reverse: publishing services without revealing the server's location or requiring any registration with domain authorities.

An onion service generates a cryptographic key pair. For modern v3 onion services, the .onion address is derived from the service's ed25519 identity key material and encodes the public key, checksum, and version in base32. The service connects to the Tor network and establishes introduction points. Clients connect through the Tor network to these introduction points, then establish a rendezvous circuit. Neither client nor server reveals their IP address to the other or to any relay.

Onion services require no domain registration. Traditional websites require domain names purchased through registrars who enforce identity requirements and can revoke domains under legal pressure. Onion addresses derive from cryptographic keys. No registrar exists to pressure and no DNS seizure is possible. The address is self-authenticating: if you reach the service, you have reached the right service, verified by cryptography and not by certificate authorities.

The server location remains hidden: its IP address never appears in any connection, so adversaries cannot identify which server to raid or which jurisdiction's laws apply. A website can be published from anywhere and remain accessible as long as any path through the Tor network exists.

SecureDrop^29^ lets sources submit documents without revealing their location to a news organization; censored publications maintain presence despite takedown orders; forums and markets operate without the jurisdictional exposure that destroyed centralized predecessors; and conventional services like Facebook and the BBC run .onion versions to reach users in censoring countries. Limitations remain: onion services are slower because of the multiple hops, the long random addresses are hard to communicate, and operational security failures can still unmask operators through other means.

I2P: A Different Architecture for Internal Services

I2P (Invisible Internet Project) uses similar principles to Tor but with different design goals and architectural choices.^7^

Garlic routing differs from onion routing in a significant way: garlic routing can bundle multiple message elements (called "cloves") into encrypted packets instead of sending every piece individually. In current I2P practice, that often includes one primary message plus control cloves. Even so, the format makes traffic analysis harder because an observer cannot easily distinguish which element corresponds to which communication stream.

I2P also uses unidirectional tunnels in place of Tor's bidirectional circuits. Each communication requires four tunnels: outbound and inbound for each party. Data sent through I2P takes one path to the destination and a different path for responses. This architectural choice makes observation more difficult because an adversary cannot assume the return path mirrors the outbound path.

I2P is a self-contained network that hosts hidden services (called "eepsites") accessible only within the network; users primarily communicate with other I2P users instead of anonymizing connections to external sites. Because traffic stays within I2P, there are no exit nodes with their associated vulnerabilities and abuse issues. The architecture is distributed: every I2P user also routes traffic for others, creating a more symmetric network than Tor's client-relay distinction.

I2P has its own security challenges. The network relies on a distributed database (the "netDB") maintained by floodfill routers. Research in 2013 showed that Sybil attacks against floodfill routers could compromise the network; attackers who controlled sufficient floodfill peers could manipulate the database to enable deanonymization.^8^ The I2P project responded by implementing mitigations including separating the netDB into multiple sub-databases and improving peer selection algorithms. Like Tor, I2P undergoes continuous development; discovered vulnerabilities are addressed through software updates. The smaller network size compared to Tor means fewer resources for security research, but the project maintains active development and responds to reported issues.

I2P's tradeoffs differ from Tor's. Fewer users means smaller anonymity sets. Tor has received much more academic scrutiny, leaving I2P's security properties less thoroughly analyzed. The focus on internal services makes accessing the regular internet less convenient than with Tor. I2P is appropriate for users whose primary need is communication with other I2P users and not anonymous access to the general internet.

17.5 Mixnets: The Strongest Protection

Why Onion Routing Is Not Enough

Tor and I2P protect against adversaries who cannot observe the entire network. But a global adversary, one who can monitor traffic entering and leaving the network simultaneously, can perform timing correlation. If a message enters Tor at 2:03:47.123 and exits at 2:03:47.456, the timing links them regardless of the encryption layers in between.

Mixnets address this limitation at the architectural level.

Chaum's Original Vision

David Chaum proposed mixnets in 1981, before Tor existed.^9^ The concept: messages are collected, batched, reordered, and forwarded by mix nodes. Batching and reordering defeat timing analysis by breaking the relationship between input and output timing.

How Mixing Defeats Traffic Analysis

A mix node accumulates messages over some time period. Once enough have arrived, the node collects them into a batch, strips the outer encryption layer from each, shuffles the batch into a new order, and forwards every message simultaneously.

An observer seeing messages enter and leave the mix cannot link inputs to outputs. Timing correlation fails because all outputs leave together. Order correlation fails because the order is shuffled. Even a global adversary who sees everything cannot determine which input corresponds to which output.

High Latency as Necessary Tradeoff

Strong mixing generally imposes latency and overhead. Messages often wait for batches or probabilistic delays to accumulate. Classic batch mixnets are poorly suited to interactive communication (instant messaging, web browsing) but suitable for asynchronous communication (email, file transfer, cryptocurrency transactions).

The tradeoff is fundamental: lower latency usually means weaker anonymity guarantees, while higher latency enables larger effective anonymity sets and stronger resistance to traffic analysis. Modern low-latency mixnets try to recover usability through cover traffic and different delay models, but they manage the tradeoff; they do not eliminate it.

Modern Implementations

Modern mixnet projects include Nym, which uses the Sphinx packet format^10^ and economic incentives for mix operators.^11^ Nym introduces cover traffic (fake messages) to further defeat traffic analysis and uses cryptocurrency-based incentives instead of volunteer operation. Loopix is a mixnet design providing sender-receiver unlinkability with resistance to active attacks.

These projects attempt to make mixnets practical for modern use while preserving their strong anonymity properties. A critical limitation remains: deployed general-purpose mixnets still have far smaller user populations than Tor or mainstream VPN ecosystems. High-latency mixnets for email (like the historical Mixmaster and Mixminion systems^28^) are defunct. Modern mixnets like Nym remain in early deployment with limited adoption. The theoretical strength of mixing is real, but anonymity depends on who else is using the system; a mixnet with few users provides weaker practical anonymity regardless of cryptographic sophistication. For applications where latency is acceptable and adoption is sufficient, mixnets provide the strongest available protection against passive traffic analysis.

17.6 Why No Single Anonymity Architecture Suffices

The tradeoff between latency and anonymity strength is structural, not a design flaw. Low-latency systems preserve timing information that global adversaries can exploit; high-latency systems destroy timing information but cannot support interactive use. VPNs concentrate trust in a single provider for speed. Tor distributes trust across three relays, sacrificing latency so no single point of compromise reveals both endpoints. Mixnets destroy timing correlation through batching and reordering at the cost of interactivity. I2P optimizes for internal network services and accepts reduced external utility.

Each architecture answers a different adversary. A local observer is defeated by a VPN, a partial-path observer by Tor's multi-hop distribution, a global passive observer only by mixing. No universally optimal tool exists. Practical anonymity means matching a tool's known limitations to the actual threat. The application-layer protocols examined next ride on top of whichever transport the user chooses; payload encryption does not substitute for transport-layer anonymity, and transport-layer anonymity does not substitute for end-to-end encryption of contents.

17.7 When the Internet Is Not the Network

Every transport the chapter has examined so far assumes a working internet. A privacy architecture that holds only under that assumption fails against the adversary who controls or removes the internet itself. The Ukraine, Gaza, Myanmar, and Iran shutdowns of the last decade are the ordinary operating conditions under which privacy most matters. Mesh and offline-first transports carry information when the internet is unavailable or is itself the adversary.

Meshtastic: LoRa at the Edge of the Spectrum

Meshtastic is an open-source mesh-networking protocol that runs on inexpensive LoRa radios. LoRa trades data rate for range, achieving hundreds of bits per second over several kilometers under favorable conditions, and handheld devices cost the price of a restaurant meal. Nodes relay for one another without central coordination; payloads are end-to-end encrypted; the network has no authoritative directory or administrative boundary. Bandwidth is tight enough that only short text messages are practical, and line-of-sight physics constrain range regardless of the protocol. An adversary who takes down the internet does not take down the spectrum, and the defender's fallback requires only that enough participants already hold the hardware.^12^

Reticulum and the Cryptographically Self-Routing Stack

Reticulum Network Stack (RNS) is a cryptographic networking stack that can run over any transport, including LoRa, packet radio, serial links, and ordinary TCP/IP, with every node's address its public key and no central routing authority. A privacy architecture that rides on the ordinary internet when that is available and on amateur radio when that is not, without changing its security model, is more resistant than an architecture tied to a specific transport. The adversary who wants to deny the user connectivity must then deny every available transport simultaneously.^13^

Briar, BitChat, and Bluetooth-Scale Mesh

Briar synchronizes messages over Bluetooth, Wi-Fi, and Tor without a central server, targeting activists and journalists under compromised or absent networks. BitChat, released by Jack Dorsey in July 2025, runs over Bluetooth low energy mesh on iOS and Android with no phone number and no account, using store-and-forward relay so a message reaches its destination once any path of intermediate phones connects sender to receiver. Uptake on launch was rapid, and the category has expanded as users and journalists have carried these tools into the environments (protests, disasters, shutdowns) where the conventional network cannot be trusted. A Bluetooth mesh is the low-cost, low-range counterpart to a LoRa mesh; the defender's stack can include both at bounded cost.^14^

FIPS: A Self-Sovereign Network Layer

The Free Internetworking Peering System is a transport-agnostic overlay network in which every node generates its own cryptographic identity and routes without registration, DHCP, DNS, or any certificate authority.^15^ A FIPS node's routing address is derived from a secp256k1 keypair the operator generates offline. Per-device network keys, rotatable independently of any other identity the operator holds, keep the peering graph from collapsing into the user's other trust domains.

What FIPS contributes to the transport stack is self-sovereign addressing paired with transport indifference. The same mesh can span UDP, TCP, Ethernet, Tor, and Bluetooth low energy simultaneously; a single packet can traverse any of them. Hop-by-hop links use Noise IK encryption so every peer-to-peer link is authenticated and confidential, and end-to-end sessions use Noise XK with periodic rekey so intermediate routers learn only 16-byte truncated node addresses, not payloads or endpoint identities. The spanning-tree construction is partition-tolerant: a local segment whose link to the wider mesh is cut continues operating on its own and re-merges automatically on reconnect. An optional IPv6 adaptation layer maps node addresses onto a fd00::/8 range so unmodified applications can address any FIPS endpoint by hostname. Where Tor provides low-latency anonymity over the existing internet, FIPS provides addressing and routing that do not require the existing internet at all.

Amateur Radio and Licensed Spectrum

Licensed amateur radio is the oldest mesh. Operators relay messages using protocols including Winlink, FT8, JS8Call, and APRS, reaching everywhere an antenna can be pointed and a license obtained. FCC Part 97 in the U.S. (with analogues elsewhere) prohibits obscuring the meaning of messages, which is interpreted as a prohibition on encryption. Amateur radio can therefore carry authenticated but not confidential traffic in most jurisdictions. A signed Nostr event transmitted over an amateur band remains cryptographically authentic even though its contents are readable, and under state-shutdown conditions the defender takes what the regulatory regime allows.^16^

Satellite and the Question of Sovereignty

Low-earth-orbit constellations (Starlink, Iridium, and competitors) provide connectivity that does not depend on the terrestrial network of any specific state. Starlink has been subject to documented geofencing under political pressure; older networks like Iridium have had less bandwidth and less political attention and have proven more stable as a consequence. Satellite links belong in a privacy stack because they are orthogonal to terrestrial internet; which operator the defender chooses depends on specific political exposures.^17^

The Common Thread

Every transport in this section answers the same question: when the conventional network is unavailable or hostile, what carries the message? The answers differ by range, bandwidth, regulatory status, and political exposure. What they share is that each is cheap to deploy at the node, expensive to suppress at the network, and scalable in density as threat levels rise. Encryption protects what is said; mesh and offline-first transports protect whether it can be said at all.

17.8 Encrypted Messaging: The Application Layer

The transport-layer tools in the preceding sections hide the fact of communication. Encrypted-messaging protocols hide its contents. The two sit at different layers of the stack and solve different problems, but their histories are entangled: each generation of messaging protocol has tried to protect more of what the last one left exposed, and the residual leaks motivate exactly the transport-layer tools this chapter has already examined.

PGP: Content Encryption and Its Limits

Pretty Good Privacy, released by Phil Zimmermann in 1991 and standardized as OpenPGP in RFC 4880, was the first widely available tool that let ordinary people encrypt and sign email.^18^ Its arrival was politically significant: Zimmermann was investigated for three years under U.S. arms-export regulations on the theory that his software constituted a munition.^23^ The investigation was dropped, but it established that civilian access to strong cryptography would be contested. The chapter on the cypherpunk movement returns to this episode; the protocol that came out of it shaped the next generation of message encryption.

Cryptographically, PGP is a hybrid scheme. A long-lived primary key, conventionally split into a signing primary and one or more encryption and authentication subkeys, identifies the user. To send a message, the sender generates a fresh symmetric session key, encrypts the payload with that session key under a symmetric cipher, and then encrypts the session key separately to each recipient's public encryption subkey. Signatures over the plaintext or ciphertext are produced with the sender's signing primary or a signing subkey. The use of subkeys lets users rotate operational keys without abandoning the long-term identity that already accumulated trust signatures, but in practice most users never rotate at all.

The trust model is the web of trust. There is no certificate authority. Users sign each other's public keys after verifying them in person, and trust propagates transitively along signed chains. Public keys are published to keyservers, and verification is supposed to happen out of band, often through key signing parties at conferences where participants check government identification and exchange key fingerprints. The model is intellectually elegant and operationally hostile to anyone outside a small technical community.

What PGP does well is also what limits it. Long-lived keys are useful for signing software releases, Git commits, package repositories, and other artifacts whose authorship should remain provable for years; this is why PGP survives in the supply-chain integrity role even where it has been abandoned for messaging. The same long life is a liability for live correspondence. PGP provides no forward secrecy: anyone who compromises a long-term private key, whether through device seizure, malware, a cold subpoena, or a quiet decryption advance, can decrypt every past message ever encrypted to that key. Signatures are non-repudiable by design, which is the desired property for software releases and the wrong property for personal conversation; an offhand remark sent to one person becomes durable cryptographic evidence of authorship that the sender cannot later deny.

The trust infrastructure also failed in practice. Most users never participated in key signing and could not meaningfully verify the keys they downloaded. The SKS keyserver pool, which served as the de facto key distribution system for years, had no abuse controls; an attacker discovered in 2019 that flooding a key with hundreds of thousands of meaningless signatures produced a key file so large that GnuPG would hang or crash when it tried to import it, and the keys of high-profile project maintainers were poisoned faster than they could be rotated. The keyserver network never recovered. Newer distribution mechanisms exist, including the Web Key Directory standard that lets a domain publish keys at a well-known URL under its own authority, the Hagrid keyserver run by the Sequoia project under stricter validation rules, and the Autocrypt opportunistic key exchange built into clients like Thunderbird and K-9 Mail. None has restored a single working substitute for what SKS was supposed to do, and the modern OpenPGP world is fragmented across competing implementations such as GnuPG, Sequoia, RNP, and OpenPGP.js, with the LibrePGP fork having split from RFC 9580 in 2024.

Usability has been a known problem for as long as PGP has existed. The 1999 paper "Why Johnny Can't Encrypt" tested PGP 5.0 with educated users and found that most could not reliably encrypt or decrypt mail without making mistakes that defeated the protection. Later work in 2015 found the same problems unfixed in modern Mailvelope and similar tools. The interface model never matched the conceptual model, and the conceptual model never matched what users needed.

PGP also encrypts content only. Email headers, subject lines, recipient addresses, timestamps, and the key identifiers in encrypted message packets all travel in the clear, which lets a passive observer reconstruct the entire social graph and timing pattern of supposedly private correspondence. For secure messaging, PGP solves one problem and leaves many others visible. The protocols that followed treated each of those exposed surfaces as a problem to address explicitly.

OTR: Forward Secrecy and Deniability for Live Chat

Off-the-Record Messaging, introduced by Nikita Borisov, Ian Goldberg, and Eric Brewer in 2004, was a deliberate answer to PGP's model.^19^ Their paper is direct about the target: PGP-style cryptography makes live conversation look nothing like live conversation. Ordinary speech is authenticated in the moment but leaves no durable proof afterward, and the speakers can later deny what they said with no cryptographic instrument standing against them. OTR asked what cryptography would look like if it behaved the same way, and built the answer on top of existing instant messaging carriers, principally XMPP, AIM, ICQ, and IRC.

The protocol provides four properties: encryption, authentication, perfect forward secrecy, and deniability. Authentication runs on a per-session Diffie-Hellman exchange signed once at session setup with long-term identity keys, so parties prove who they are at the start of the conversation without re-signing every message. Message integrity runs on message authentication codes instead of digital signatures, because MAC keys are symmetric and shared between the two participants; either side could have generated any given MAC, so neither MAC alone is evidence against the other. After a MAC key is no longer needed for verification, OTR publishes it on the wire, making transcripts retroactively forgeable by anyone who later obtains them. Diffie-Hellman keypairs ratchet forward through the session as new key material is exchanged, so compromise of any single ephemeral key compromises only a small window of messages.

A second deniability problem OTR addressed is identity authentication itself. Asking "is this Alice?" over an untrusted channel is hard if the answer must be unforgeable to a network attacker but the channel is the only one available. OTR solved this with the Socialist Millionaire Protocol,^24^ an interactive zero-knowledge construction that lets two parties confirm they share a secret answer to an agreed question without revealing the answer to anyone, including each other if they got it wrong. In practice this allows two people who already know something private together (a shared past, a phrase agreed in person) to verify each other's identity without exchanging long key fingerprints and without producing a signature anyone could replay.

OTR's contribution to the line was conceptual: it showed that forward secrecy and deniable authentication were simultaneously achievable for interactive use, and that the property set ordinary conversation already has could be reproduced cryptographically. The protocol shipped initially as a libpurple plugin for Pidgin and Adium^25^ and was later integrated into clients including Jitsi, ChatSecure, CryptoCat, and Tor Messenger. OTR version 3, published in 2012, added multi-instance support so a user could run OTR from more than one client at once, and OTRv4, drafted from 2017 onward by the OTR Development Team, replaced the original key exchange with a deniable authenticated key exchange and added a double-ratchet construction inspired by the work that became Signal.^26^

The decline was operational. OTR assumed both parties were online at the same time to run the interactive key exchange, and it assumed a single long-running session per pair of devices. The smartphone era broke both assumptions. Mobile clients went offline whenever a screen locked or network connectivity hiccuped, and users acquired multiple devices that they expected to share a single conversation. OTR never acquired native asynchronous or multi-device support that worked at the level mobile users had come to expect from iMessage and WhatsApp, and the underlying XMPP networks that hosted most OTR conversations themselves shrank as users moved to integrated platforms. The successor protocol absorbed OTR's ratcheting idea into an architecture designed for the new constraints.

Signal: Asynchronous Forward Secrecy at Smartphone Scale

The Signal Protocol, developed by Trevor Perrin and Moxie Marlinspike at Open Whisper Systems, is the engine behind Signal itself and behind the end-to-end encryption shipped by WhatsApp, Google Messages, Meta Messenger, and most of the other mainstream messengers that claim E2EE.^20^^27^ It is two distinct protocols working in sequence.

X3DH completes a key agreement when the other party is offline by combining pre-published keys, and the Double Ratchet then rotates keys per message to provide both forward secrecy (past messages remain protected if the current state is compromised) and post-compromise security (future messages become protected again after the attacker is locked out for one round-trip). Out-of-order delivery is handled by caching skipped message keys in bounded windows.

Signal has been deployed at extraordinary scale and shipped post-quantum key agreement (PQXDH) in 2023. What it does not solve natively is group messaging. Signal groups are implemented with "sender keys": each participant broadcasts a symmetric ratchet to the others over their pairwise Double Ratchet channels. Adding or removing a member, or rotating keys after compromise, costs O(N) pairwise operations, which limits practical group sizes and makes post-compromise security expensive at scale. Signal also does not hide who is talking to whom; sealed-sender and private contact discovery are application-layer additions on top of a protocol that still requires a central server to deliver messages. The Signal server is a single shutdown target.

Noise: A Framework for Secure Channels

Signal and MLS solve the messaging-application problem. The Noise Protocol Framework, published by Trevor Perrin in 2016, solves the layer below: how to build a two-party authenticated and confidential channel in the first place, without relying on the certificate hierarchy that TLS assumes. Noise is not a protocol but a construction kit. A designer picks a handshake pattern (IK, XK, XX, and others are named by their authentication shapes), a Diffie-Hellman curve (25519 or 448), a cipher (ChaCha20-Poly1305 or AES-GCM), and a hash (SHA-256, SHA-512, or BLAKE2), and the framework derives a concrete protocol whose properties are specified by the chosen pattern. Forward secrecy, mutual authentication, and optional identity hiding are pattern-level guarantees, not implementation details.

The patterns carry their properties in the name. IK means the initiator knows the responder's static key in advance, so the initiator can authenticate the responder on the first message; XK is the same pattern with initiator identity hidden until the responder proves itself, which is useful when the initiator wants to stay anonymous to passive observers. XX is mutual authentication without either party knowing the other's static key in advance, which is the pattern TLS 1.3 approximates. Each pattern's security properties are formally analyzed, and a handshake built from a named pattern inherits those properties by construction.

WireGuard uses Noise_IK_25519_ChaChaPoly_BLAKE2s for its VPN handshake, which is why a WireGuard peer establishes an encrypted tunnel in one round-trip and the handshake format is small enough to fit in a UDP packet. Signal's X3DH and the I2P NTCP2 transport are Noise-derived. Lightning's BOLT #8 transport encryption uses Noise_XK for node-to-node communication, so every Lightning channel establishment includes a mutually authenticated handshake with responder-identity privacy. FIPS uses Noise_IK for hop-to-hop links and Noise_XK for session-layer encryption, inheriting both the handshake brevity and the formal analysis that comes with the named patterns. The framework has become the default construction for new secure-channel designs because the design work has already been done; a protocol author picks the pattern whose properties match the adversary model and gets a proved construction without writing a new one.

MLS: Group Messaging as a Standard

Messaging Layer Security, standardized as RFC 9420 by the IETF in 2023, is the first standards-track answer to the group-scaling problem Signal's design could not efficiently solve.^21^ MLS is a continuous group key agreement protocol: an authenticated key exchange designed from the start for groups instead of pairs, scaling from two members up to the tens of thousands the RFC targets as its working range.

MLS uses a ratchet tree, reducing the cost of adding, removing, or updating a member to O(log N) operations from Signal's O(N) pairwise sender-keys. Group lifetime advances through explicit epoch transitions that inject fresh entropy, and new members receive the group state asynchronously via prekey-style KeyPackages.

The security properties MLS inherits from this structure are exactly what Signal provides pairwise, lifted to groups: forward secrecy through epoch rotation, and post-compromise security because any commit by or about a compromised member introduces entropy the attacker does not control. What MLS leaves to the surrounding system is metadata protection. The RFC explicitly notes that the delivery service sees group identifiers, message frequency, and member counts. Hiding the social graph around the messages is not MLS's job. Cisco Webex, Wire, RingCentral, and Matrix have deployed MLS in production, and the GSMA's Universal Profile 3.0 specifies MLS for cross-carrier interoperable end-to-end encryption in RCS,^33^ with corresponding plans announced for iMessage. The IETF MIMI working group is building on MLS to satisfy European interoperability requirements.^34^

A separate line of deployment composes MLS with the decentralized relay layer examined in Chapter 21. The Marmot protocol uses Nostr keys as the MLS Authentication Service and Nostr relays as the MLS Delivery Service, so the identity and transport pieces MLS deliberately leaves abstract are filled in by infrastructure that no single entity controls. Marmot also addresses the metadata gap the RFC concedes. Each group message is published under a fresh ephemeral relay-layer keypair instead of the user's identity key, and the public group identifier is a rotatable pseudo-ID instead of the real MLS group ID. Welcome messages are wrapped in onion-style gift-wrap envelopes that hide sender and recipient from the relays carrying them. White Noise, the flagship Marmot client, ships on Android and iOS devices, and a specification audit by Least Authority completed in early 2026.^32^ Chapter 21 treats this composition in detail; the point here is that MLS's deliberate separation of cryptographic core from authentication and delivery is what makes such a composition possible at all.

What the Progression Shows

Each generation solved the core problem the previous one left open and revealed the next one. PGP protected content and exposed everything else. OTR protected live conversation but assumed synchronous single-device use. Signal made strong E2EE asynchronous and ubiquitous for pairs but scaled poorly to groups and depended on a central server. MLS standardized efficient group encryption but left the metadata problem at the delivery service to the surrounding system. That surrounding system is exactly what the transport-layer tools in sections 17.3 through 17.5 try to address: even the strongest application-layer encryption leaves the delivery infrastructure with the power to observe patterns of communication, so the two layers compose only when both are present. Chapter 21 examines how a decentralized relay layer can be combined with MLS to close more of that gap.^22^

Chapter Summary

Metadata exposure is a structural problem that content encryption cannot solve. The internet's design embeds sender and receiver identifiers in every packet, and encrypting the payload leaves communication patterns, timing, frequency, and volume visible to any observer along the path. Anonymous communication architectures form a spectrum defined by the latency-anonymity tradeoff. VPNs relocate trust to a single provider in exchange for speed; onion routing distributes trust across multiple relays so no single node learns both endpoints; mixnets destroy timing correlation through batching and reordering at the cost of latency that rules out interactive use. The adversary model determines the appropriate tool. A local observer is defeated by a VPN, a partial-path observer by Tor's multi-hop distribution, a global passive observer only by mixing. When the conventional internet is itself the adversary, mesh and offline-first transports (Meshtastic, Reticulum, Briar, BitChat, FIPS, amateur radio, satellite) carry messages on infrastructure no single state controls. A privacy architecture benefits from composing several of these transports so that an adversary who wants to deny connectivity must deny every available channel at once.

Application-layer protocols have progressively strengthened what encryption protects. PGP encrypted content and left everything else exposed. OTR added forward secrecy and deniability for live chat. Signal made asynchronous forward-secret messaging practical at smartphone scale. Noise became the default construction for new secure channels. MLS provides the same Signal-style security guarantees for groups in O(log N) operations and shipped as an IETF standard in 2023. Each generation solved what the previous left open and left the metadata problem at the delivery service to the layers below. No single tool provides complete anonymity, and every architecture has structural limitations determined by its design tradeoffs. Chapter 22 addresses the operational security practices that complement architectural protection, and Chapter 20 examines the distinct metadata problems Bitcoin's on-chain transparency and Lightning's channel graph create for monetary privacy.

---

Endnotes

^1^ The quote is widely attributed to Michael Hayden from a 2014 debate at Johns Hopkins University. See David Cole, "We Kill People Based on Metadata," New York Review of Books, May 10, 2014. For the earlier structural statement of the same dossier problem in transaction systems, see David Chaum, "Security Without Identification: Card Computers to Make Big Brother Obsolete," Communications of the ACM 28, no. 10 (1985): 1030-1044, archived at https://nakamotoinstitute.org/library/security-without-identification/.

^2^ Roger Dingledine, Nick Mathewson, and Paul Syverson, "Tor: The Second-Generation Onion Router," Proceedings of the 13th USENIX Security Symposium (2004): 303-320. The Tor Project, https://www.torproject.org/.

^3^ For a full survey of attacks on Tor, see the "Attacks on Tor" repository maintained by security researchers, available at https://github.com/Attacks-on-Tor/Attacks-on-Tor.

^4^ On website fingerprinting, see Giovanni Cherubin et al., "Online Website Fingerprinting: Evaluating Website Fingerprinting Attacks on Tor in the Real World," USENIX Security Symposium (2022). The study found that accuracy degrades rapidly when monitoring larger sets of websites in realistic conditions.

^5^ On Operation Torpedo, see Kevin Poulsen, "FBI Used Drive-By-Downloads to Expose Tor Pedophiles," Infosecurity Magazine, August 2014. The NIT (Network Investigative Technique) exploited a Flash vulnerability to reveal real IP addresses.

^6^ The Tor Project, "Tor Security Advisory: 'Relay Early' Traffic Confirmation Attack," July 30, 2014, available at https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confirmation-attack/. See also Philipp Winter et al., "Identifying and Characterizing Sybils in the Tor Network," USENIX Security Symposium (2016).

^7^ For I2P technical documentation, see https://geti2p.net/en/docs. On garlic routing specifically, see https://geti2p.net/en/docs/how/garlic-routing.

^8^ Christoph Egger et al., "Practical Attacks Against the I2P Network," RAID Symposium (2013). The researchers showed successful attacks using only 20 malicious floodfill peers. For I2P's threat model and mitigations, see https://geti2p.net/en/docs/how/threat-model.

^9^ David Chaum, "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms," Communications of the ACM 24, no. 2 (1981): 84-90.

^10^ On the Sphinx packet format used by modern mixnets, see George Danezis and Ian Goldberg, "Sphinx: A Compact and Provably Secure Mix Format," IEEE Symposium on Security and Privacy (2009), https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf. For the Loopix design that Nym partially descends from, see Ania M. Piotrowska et al., "The Loopix Anonymity System," USENIX Security Symposium (2017).

^11^ Claudia Diaz, Harry Halpin, and Aggelos Kiayias, "The Nym Network," available at https://nym.com/.

^12^ Meshtastic is the dominant open-source LoRa mesh protocol; Heltec, LILYGO, and RAK Wireless are the three main hardware vendors whose devices run it. Meshtastic project, https://meshtastic.org/, with source at https://github.com/meshtastic. LoRa modulation specification maintained by the LoRa Alliance at https://lora-alliance.org/. Hardware: Heltec Automation, https://heltec.org/; LILYGO, https://www.lilygo.cc/; RAK Wireless, https://www.rakwireless.com/. Event-scale deployment reporting in security-conference community coverage at DEF CON and similar gatherings since 2022.

^13^ Reticulum is a transport-agnostic cryptographic networking stack where every node's address is its public key; NomadNet and LXMF are the messaging applications built on top of it. Reticulum Network Stack, https://reticulum.network/, documentation at https://markqvist.github.io/Reticulum/manual/. NomadNet, https://github.com/markqvist/NomadNet. LXMF (Lightweight Extensible Message Format), https://github.com/markqvist/LXMF.

^14^ Briar and BitChat are the two reference Bluetooth-mesh messengers; Briar is the activist/journalist tool with Tor synchronization and a decade of peer-review history, BitChat (launched July 2025 by a project associated with Jack Dorsey) is the mass-market entry with no-account onboarding and iOS/Android distribution. Briar, https://briarproject.org/, with source at https://code.briarproject.org/briar/briar. On Briar's design and threat model, see Michael Rogers and Eleanor Saitta, "Briar: Private Messaging, Local Networks, and Censorship Resistance" (2018), https://briarproject.org/publications/. BitChat, https://bitchat.free/, with source at https://github.com/permissionlesstech/bitchat. On the security-research pushback against unaudited Bluetooth-mesh designs, see Matthew Green and Trail of Bits audit reporting at https://blog.cryptographyengineering.com/.

^15^ FIPS (Free Internetworking Peering System) is a self-organizing transport-agnostic overlay network in which each node generates its own secp256k1 keypair as its routing identity, independent of any ISP, regional internet registry, or certificate authority. FIPS, https://github.com/jmcorgan/fips, with protocol design documentation at https://github.com/jmcorgan/fips/tree/master/docs/design. Released under MIT license; at v0.2.0 at time of writing. The Noise protocol framework, https://noiseprotocol.org/, underlies both the hop-to-hop (Noise IK) and session-layer (Noise XK) encryption. An optional IPv6 adaptation layer maps node addresses onto an fd00::/8 range so unmodified applications can address any FIPS endpoint.

^16^ U.S. FCC Part 97 and analogous regulations in most jurisdictions prohibit encryption on amateur bands; Winlink, FT8, JS8Call, and APRS are the deployed data modes; amateur radio carries authenticated but not confidential traffic under these regimes. FCC Part 97 rules at https://www.ecfr.gov/current/title-47/chapter-I/subchapter-D/part-97. Winlink, https://www.winlink.org/. FT8 (part of the WSJT-X software suite), https://wsjt.sourceforge.io/. JS8Call, http://js8call.com/. APRS (Automatic Packet Reporting System), http://www.aprs.org/. On signed Nostr events carried over authenticated but unencrypted amateur bands, see community reporting from the HamRadio + Nostr intersection at https://github.com/search?q=nostr+ham+radio.

^17^ Starlink, Iridium, OneWeb, and Globalstar operate low-earth-orbit constellations that carry traffic independent of any state's terrestrial infrastructure; Starlink's geofencing and combat-zone disruptions make the case that no single operator is politically trustworthy and that orthogonal transport in the defensive stack beats reliance on any one satellite link. Starlink, https://www.starlink.com/. Iridium, https://www.iridium.com/. OneWeb (operated by Eutelsat Group), https://oneweb.net/. Globalstar, https://www.globalstar.com/. On Starlink's documented disruptions in Ukraine, see reporting in Financial Times, Reuters, and Elon Musk's own public statements on X/Twitter archived at https://web.archive.org/. On the geofencing incidents, see Ukrainian Ministry of Defense statements through 2023–2024.

^18^ J. Callas et al., "OpenPGP Message Format," RFC 4880 (November 2007); updated by RFC 9580 (July 2024) and forked by the LibrePGP specification. On PGP's usability and architectural limits, see Alma Whitten and J. D. Tygar, "Why Johnny Can't Encrypt," USENIX Security Symposium (1999); Scott Ruoti et al., "Why Johnny Still, Still Can't Encrypt: Evaluating the Usability of a Modern PGP Client," arXiv:1510.08555 (2015); and Matthew Green, "What's the Matter with PGP?" (2014), available at https://blog.cryptographyengineering.com. On the SKS keyserver poisoning attack of 2019, see Daniel Kahn Gillmor, "OpenPGP Certificate Flooding," and Robert J. Hansen, "SKS Keyserver Network Under Attack" (June 2019), the latter at https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f. On the Web Key Directory standard, see the IETF draft at https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/. On Autocrypt, see https://autocrypt.org.

^19^ Nikita Borisov, Ian Goldberg, and Eric Brewer, "Off-the-Record Communication, or, Why Not To Use PGP," Workshop on Privacy in the Electronic Society (2004). Specification at https://otr.cypherpunks.ca/.

^20^ For the Signal Protocol specifications, see Moxie Marlinspike and Trevor Perrin, "The X3DH Key Agreement Protocol" (2016) and "The Double Ratchet Algorithm" (2016), both at https://signal.org/docs/. For formal analysis, see Katriel Cohn-Gordon et al., "A Formal Security Analysis of the Signal Messaging Protocol," IEEE European Symposium on Security and Privacy (2017). Post-quantum extension: "The PQXDH Key Agreement Protocol," 2023. The Noise Protocol Framework specification, Trevor Perrin, "The Noise Protocol Framework," revision 34 (2018), https://noiseprotocol.org/noise.html, is the reference for the handshake-pattern taxonomy. Noise-derived deployments include WireGuard (Jason Donenfeld, "WireGuard: Next Generation Kernel Network Tunnel," NDSS 2017), Lightning's BOLT #8 transport encryption, I2P's NTCP2 transport, and FIPS's hop and session encryption.

^21^ R. Barnes et al., "The Messaging Layer Security (MLS) Protocol," RFC 9420 (July 2023); R. Barnes et al., "The Messaging Layer Security (MLS) Architecture," RFC 9750 (2024). The underlying ratchet-tree design originates in Katriel Cohn-Gordon et al., "On Ends-to-Ends Encryption: Asynchronous Group Messaging with Strong Security Guarantees," ACM CCS (2018).

^23^ The U.S. government's arms-export investigation of Phil Zimmermann under the International Traffic in Arms Regulations (ITAR) ran from 1993 to 1996 and established that civilian access to strong cryptography would be legally contested. The case was dropped without charges, but its chilling effect on cryptography export shaped the cypherpunk movement's urgency. Philip R. Zimmermann, The Official PGP User's Guide (MIT Press, 1995), documents PGP's design and the political context. The ITAR case is documented in Simson Garfinkel, PGP: Pretty Good Privacy (O'Reilly, 1994), pp. 81–102, and in Steven Levy, Crypto: How the Code Rebels Beat the Government Saving Privacy in the Digital Age (Viking, 2001), pp. 199–230. Phil Zimmermann's own account appears at https://web.archive.org/web/20240101000000/https://philzimmermann.com/EN/background/index.html.

^24^ The Socialist Millionaire Protocol (SMP) is the zero-knowledge equality-test used in OTR for mutual identity authentication without exchanging long key fingerprints. It derives from Fabrice Boudot, Berry Schoenmakers, and Jacques Traoré, "A Fair and Efficient Solution to the Socialist Millionaires' Problem," Discrete Applied Mathematics 111, no. 1–2 (2001): 23–36. OTR's adaptation of SMP is specified in the OTR protocol version 2 and later specifications at https://otr.cypherpunks.ca/Protocol-v3-4.1.1.html; the specific implementation as an interactive zero-knowledge proof that two parties share a common secret without revealing it appears in section 2.6 of that document.

^25^ Pidgin is the multiprotocol instant messaging client whose libpurple plugin architecture enabled OTR's initial distribution; Adium is the macOS equivalent. The original OTR libpurple plugin at https://otr.cypherpunks.ca/. Pidgin project at https://www.pidgin.im/. Adium project at https://adium.im/. The libpurple library, shared between Pidgin and Finch, provided the plugin API that allowed OTR to be retrofitted onto AIM, ICQ, XMPP, and other protocols without modifying the underlying clients.

^26^ OTRv4 replaces the original Diffie-Hellman key exchange with a deniable authenticated key exchange (DAKE) based on the work of Yehuda Lindell and adds a double-ratchet mechanism that provides forward secrecy at the message level within a session. Specification: Nik Unger, Sofía Celi, Jurre van Bergen, and the OTR Development Team, "OTRv4," draft specification (2019–present), https://github.com/otrv4/otrv4/blob/master/otrv4.md. On the deniable authenticated key exchange construction, see Mario Di Raimondo, Rosario Gennaro, and Hugo Krawczyk, "Deniable Authentication and Key Exchange," ACM CCS (2006), https://eprint.iacr.org/2006/280.

^27^ WhatsApp's 2016 deployment of the Signal Protocol to its then 1 billion users was the largest single rollout of end-to-end encryption in history. Moxie Marlinspike and Trevor Perrin, "WhatsApp's Signal Protocol Integration Is Now Complete," Open Whisper Systems Blog (April 5, 2016), https://signal.org/blog/whatsapp-complete/. The technical white paper is WhatsApp Inc., "WhatsApp Encryption Overview: Technical White Paper" (2016, updated 2017), https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf. Google Messages' RCS end-to-end encryption using the Signal Protocol is documented at https://support.google.com/messages/answer/10262381. Meta Messenger's adoption is described in Jon Millican, "Messenger End-to-End Encryption Overview," Meta Engineering Blog (2023), https://engineering.fb.com/2023/12/06/security/messenger-end-to-end-encryption-default/.

^28^ Mixmaster and Mixminion were the two deployed high-latency anonymous remailer networks for email; both are now defunct. Mixmaster was the type-II remailer network; Lance Cottrell, "Mixmaster and Remailer Attacks," in Proceedings of the Workshop on Privacy Enhancing Technologies (1994). Mixminion was the type-III successor: George Danezis, Roger Dingledine, and Nick Mathewson, "Mixminion: Design of a Type III Anonymous Remailer Protocol," IEEE Symposium on Security and Privacy (2003), https://mixminion.net/minion-design.pdf. Both networks closed due to insufficient user adoption rather than cryptographic failure, illustrating the collective-action dynamics the chapter describes. The Mixminion source archive remains at https://mixminion.net/.

^29^ SecureDrop is the open-source whistleblower submission system developed by the Freedom of the Press Foundation, built on Tor onion services; it is deployed by more than 75 news organizations. Freedom of the Press Foundation, https://freedom.press/. SecureDrop project at https://securedrop.org/, with source at https://github.com/freedomofpress/securedrop. The original design was created by Aaron Swartz and Kevin Poulsen as DeadDrop; the Freedom of the Press Foundation assumed stewardship in 2013. On SecureDrop's threat model and architecture, see the official documentation at https://docs.securedrop.org/en/stable/threat_model/threat_model.html.

^30^ The 2013 Freedom Hosting operation was an FBI action that deployed malware (a Network Investigative Technique) through a JavaScript exploit against Firefox 17 ESR to unmask users of Tor hidden services hosted on Freedom Hosting's infrastructure. Kevin Poulsen, "FBI Allegedly Ran Tor Hidden Services, Seized Them to Unmask Child Porn Viewers," Wired, August 5, 2013. Subsequent analysis by Vlad Tsyrklevich, "Tor Browser Bundle Exploit Analysis" (August 2013), documented the payload's mechanism. The exploit targeted a Firefox use-after-free vulnerability (CVE-2013-1690) that had been patched in newer Firefox versions but remained present in the then-current Tor Browser Bundle; the attack was mitigated by upgrading Tor Browser and disabling JavaScript.

^31^ Tor's directory authority system and its consensus mechanism are documented in the Tor design paper and the dir-spec. Roger Dingledine and Nick Mathewson, "Tor Protocol Specification," at https://spec.torproject.org/; the directory authority protocol specifically in "Tor directory protocol, version 3," https://spec.torproject.org/dir-spec. The nine currently recognized directory authorities and their operators are listed at https://metrics.torproject.org/rs.html#search/flag:Authority. On the security properties and known weaknesses of the directory authority system, see Aaron Johnson et al., "Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries," ACM CCS (2013), https://www.ohmygodel.com/publications/usersrouted-ccs13.pdf.

^32^ The Marmot protocol specification and White Noise client are the primary open-source implementation of MLS over Nostr infrastructure. Marmot protocol specification at https://github.com/marmot-protocol/marmot. White Noise client (Android and iOS) at https://whitenoise.chat/. The Least Authority security audit of the Marmot specification, completed in early 2026, is available from Least Authority at https://leastauthority.com/. On the NIP-17 gift-wrap envelope construction that Marmot uses for metadata-hiding message delivery, see https://github.com/nostr-protocol/nips/blob/master/17.md.

^33^ The GSMA's Rich Communication Services (RCS) Universal Profile 2.4 introduced end-to-end encryption, and Universal Profile 3.0 specifies MLS as the group key agreement protocol, enabling cross-carrier interoperable E2EE in carrier-delivered messaging. GSMA, "RCS Universal Profile Service Definition Document," version 3.0 (2024), available to GSMA members at https://www.gsma.com/solutions-and-impact/technologies/networks/rcs/. Apple's announcement of RCS support with end-to-end encryption for iMessage interoperability: Apple Inc., "Apple Announces RCS Support" (2024), with technical details in the WWDC 2024 session "What's new in Messages for Business." Google's Messages implementation of RCS E2EE is documented at https://support.google.com/messages/answer/10262381.

^34^ The IETF More Instant Messaging Interoperability (MIMI) working group is developing standards to allow end-to-end encrypted messaging across different providers, primarily to satisfy the European Union's Digital Markets Act interoperability requirements. IETF MIMI working group charter and documents at https://datatracker.ietf.org/wg/mimi/about/. The key documents are the MIMI content format (draft-ietf-mimi-content) and the MIMI protocol (draft-ietf-mimi-protocol), both building on MLS (RFC 9420) as the group key agreement layer. On the Digital Markets Act interoperability obligation that motivates this work, see Regulation (EU) 2022/1925 of the European Parliament and of the Council, Article 7, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R1925.

^22^ For readers who want to use the tools covered in this chapter: Tor Browser (torproject.org) is the reference anonymity client; Mullvad (mullvad.net) and IVPN (ivpn.net) are the privacy-oriented VPN providers with the strongest public track records; Signal (signal.org) and Session (getsession.org) are the mainstream encrypted messengers; Element (element.io) is the reference Matrix client, and Wire (wire.com) ships MLS in production; Nym (nym.com) is the most developed deployed mixnet. For background reading, Matt Blaze's Tangled Web writings, the Tor Project's ongoing research notes, and the EFF's Surveillance Self-Defense guide (ssd.eff.org) are all worth consulting; Moxie Marlinspike, "The Ecosystem Is Moving" (2016), https://signal.org/blog/the-ecosystem-is-moving/, is the canonical modern statement of why federated protocols have struggled against integrated end-to-end-encrypted platforms and why the gap between deployed cryptography and academic cryptography keeps widening. Bruce Schneier, Data and Goliath (2015) and Carissa Véliz, Privacy Is Power (2020) address the wider political context around the same infrastructure.

---

<- Previous: Computing on Secrets |

-> Next: Bitcoin and the Digital Money Breakthrough |

The Praxeology of Privacy -- third edition. New chapters publish daily at 1600 UTC.