15 KiB
MTU as a Cypherpunk Tool
What Others Have Done
Yes, many people have worked on this idea — exploiting the MTU boundary and the properties of UDP to create communication that is hard to block. Here are the most important examples.
1. QUIC / HTTP/3 (Google, IETF)
The biggest success story. QUIC (Quick UDP Internet Connections) was designed by Google in 2012 and is now an IETF standard (RFC 9000). It is the foundation of HTTP/3.
What it does: QUIC runs entirely over UDP on port 443. It is encrypted by default (TLS 1.3). It is designed to be a single-packet protocol for connection establishment — the entire handshake fits in one round trip, often in one packet.
Why it matters for censorship resistance: QUIC was not designed for censorship resistance, but it has become one by accident. Because QUIC traffic is:
- On port 443 (same as HTTPS)
- Encrypted (TLS 1.3)
- Over UDP (not TCP)
- Indistinguishable from random bytes
...blocking QUIC means blocking HTTP/3, which means breaking a significant and growing portion of the web. China has tried to block QUIC and largely failed because it breaks too many Google services.
Current status: QUIC is used by Google (YouTube, Search, Chrome), Meta (Facebook, Instagram), Cloudflare, and many CDNs. It is estimated to carry 30-50% of all internet traffic.
Lesson: The most effective censorship-resistant protocol is one that billions of people use for legitimate purposes. Your protocol becomes hard to block because blocking it would break the internet.
2. CurveCP / MinimaLT (Daniel J. Bernstein)
The most explicit cypherpunk take on this idea. Daniel J. Bernstein (djb) — the same person who created Curve25519, NaCl, and qmail — designed CurveCP specifically as a censorship-resistant transport protocol.
What it does: CurveCP runs over UDP. Every message is a single UDP datagram. The protocol is designed so that:
- The server has no state until the client proves they can receive packets (anti-amplification)
- The handshake is a single exchange of two packets
- Everything is encrypted and authenticated
- The protocol is minimal — the specification is a few pages
Why it matters: djb explicitly designed CurveCP to be hard to block. He wrote about the "TCP/IP blocking problem" — TCP connections have visible handshakes (SYN, SYN-ACK, ACK) that can be detected and blocked. UDP has no handshake. A single UDP datagram is just a blob of bytes. There is nothing to pattern-match.
Current status: CurveCP never saw wide adoption. It was superseded by QUIC in practice. But the ideas live on. djb's design principles (minimal, single-packet, encrypted-by-default, no handshake pattern) are the blueprint for protocol hardening.
Key paper: "MinimaLT: Minimal-latency Networking Through Better Security" (2013) by djb et al.
3. obfs4 (Tor Project, Yawning Angel)
Making Tor traffic look like nothing in particular. obfs4 is the fourth generation of Tor's pluggable transport system. It is designed to make Tor traffic indistinguishable from random bytes.
What it does: obfs4 uses the NTOR handshake (a cryptographic protocol) over a custom transport that:
- Uses the IAT (Inter-Arrival Time) obfuscation technique to make packet timing look random
- Encrypts everything with a key derived from a shared secret
- Can run on any port, but commonly port 443
- Uses a "scramble suit" that makes the traffic pass statistical tests for randomness
Why it matters: obfs4 is the most widely deployed censorship circumvention tool after VPNs. It is used by millions of people in China, Iran, Russia, and other censored countries. It works because the adversary cannot distinguish obfs4 traffic from random noise without the key.
Current status: obfs4 is the default pluggable transport in Tor Browser. It is actively maintained. China has tried to block it using active probing (connecting to a suspected obfs4 bridge and seeing if it responds with a valid obfs4 handshake), which has led to a cat-and-mouse game of obfs4 vs. active probing.
Lesson: obfs4 shows that making traffic look like random noise is effective, but the adversary can use active probing to find bridges. This is why protocol hardening needs to be combined with anonymity (the bridge's IP address must be hidden).
4. DNS Tunneling (Many Implementations)
Hiding data in the one protocol that cannot be blocked. DNS is essential internet infrastructure. Without it, the internet does not work. This makes it an ideal carrier for covert communication.
What it does: DNS tunneling encodes data in DNS queries and responses. A client sends a DNS query for a domain like data1234.evil.com. The resolver (controlled by the attacker) extracts the data from the query and sends back a response with more data encoded in the response.
Why it matters: DNS is almost never blocked. It runs on UDP port 53. It is processed by every network device. Blocking DNS breaks everything. DNS tunneling is slow and detectable with statistical analysis, but it is extremely reliable.
Current status: DNS tunneling is used by malware for command-and-control, by censorship circumvention tools (like DNSCat, Iodine, OzymanDNS), and by some VPN protocols. It is well-known to defenders, who can detect it by analyzing DNS query patterns (unusual domain lengths, high query frequency, unusual TLDs).
Lesson: DNS tunneling shows the power of hiding in essential infrastructure, but also the limits — the adversary can detect anomalies in the pattern of queries even if they cannot read the content.
5. uTP / BitTorrent (LSD, Arvid Norberg)
Making your protocol look like friendly background noise. uTP (Micro Transport Protocol) was designed for BitTorrent to be "internet-friendly" — it yields to other traffic. But it also has censorship resistance properties.
What it does: uTP runs over UDP. It uses delay-based congestion control (not loss-based like TCP). This means it looks like random UDP traffic to a DPI box. There is no TCP handshake, no sequence numbers in the clear, no window scaling.
Why it matters: BitTorrent traffic is frequently throttled or blocked by ISPs. uTP was designed partly to evade this throttling. By running over UDP and looking like random traffic, uTP makes it harder for ISPs to identify and throttle BitTorrent traffic.
Current status: uTP is the default transport for modern BitTorrent clients (uTorrent, Transmission, libtorrent). It has been successful at evading ISP throttling, but not at evading deep packet inspection by sophisticated adversaries.
6. WireGuard (Jason A. Donenfeld)
The minimal VPN. WireGuard is a VPN protocol designed to be simple, fast, and hard to block.
What it does: WireGuard runs over UDP. It uses a single port (usually 51820, but can be any port). Every packet is encrypted and authenticated. There is no handshake visible to an observer — the first packet already contains encrypted data. The protocol is ~4000 lines of code (compared to ~400,000 for OpenVPN).
Why it matters: WireGuard's minimalism makes it hard to fingerprint. There is no TLS handshake, no certificate exchange, no negotiation. The packets are just encrypted blobs. An adversary cannot distinguish WireGuard traffic from random UDP traffic without the key.
Current status: WireGuard is included in the Linux kernel (5.6+). It is used by many VPN providers (Mullvad, IVPN, ProtonVPN). It is being standardized by the IETF. It is not designed specifically for censorship resistance, but its minimalism makes it naturally hard to block.
Lesson: WireGuard shows that simplicity is a censorship resistance feature. The fewer protocol features you have, the fewer patterns the adversary can fingerprint.
7. CoAP / DTLS (IETF)
Protocols for constrained devices. CoAP (Constrained Application Protocol) is designed for IoT devices with limited memory and bandwidth. It runs over UDP.
What it does: CoAP is essentially HTTP for UDP. It uses a simple binary format, supports multicast, and can be encrypted with DTLS (Datagram TLS). Messages are designed to fit in single UDP datagrams.
Why it matters: CoAP shows that the single-datagram design is not just for censorship resistance — it is also the natural design for constrained environments. This means censorship-resistant protocols can piggyback on legitimate IoT traffic.
Current status: CoAP is used in IoT, smart home, and industrial automation. It is not widely used for censorship resistance, but the protocol design is compatible with the approach.
8. The Binary Events Protocol (This Repo)
Your own work in rethinking_nostr/. The binary events protocol (.bne files) is designed to fit in single UDP datagrams under the MTU limit.
What it does: The protocol uses a fixed binary header (113 bytes) with fields aligned to CPU cache lines (64 bytes). The total event fits in 1472 bytes, meaning it can be sent as a single unfragmented UDP datagram. The header includes the kind, pubkey, and signature at fixed byte offsets, allowing kernel-level eBPF programs to filter and verify events at wire speed.
Why it matters: This is a concrete implementation of the protocol hardening approach. It combines:
- MTU boundary exploitation (single datagram)
- CPU cache line alignment (64-byte boundaries for Schnorr signatures)
- Kernel-level processing (eBPF packet filtering)
- Content-addressed storage (filesystem deduplication)
Current status: In development. The design documents in rethinking_nostr/ lay out the substrate constraints and the protocol architecture.
9. IP Fragmentation Attacks (Various)
Using fragmentation to bypass DPI. If a packet is fragmented (split into multiple pieces), some DPI systems cannot reassemble and inspect it in time.
What it does: The attacker sends a message as multiple IP fragments. The first fragment contains the header, and subsequent fragments contain the payload. Some DPI systems only inspect the first fragment and pass the rest without inspection. By carefully crafting fragments, the attacker can hide data in later fragments.
Why it matters: Fragmentation attacks show that even within the IP layer itself, there are substrate properties that can be exploited. The adversary must either reassemble all fragments (expensive) or risk missing data hidden in fragments.
Current status: Fragmentation attacks are well-known and most modern DPI systems handle them. But they still work against older or simpler systems.
10. tcpcrypt (IETF)
Encrypting TCP itself. tcpcrypt is a protocol that adds encryption to TCP at the transport layer, without requiring changes to applications.
What it does: tcpcrypt adds a cryptographic handshake to TCP connection setup. The handshake is designed to be indistinguishable from a normal TCP handshake to a passive observer. The encryption is transparent to applications — they just see a normal TCP connection.
Why it matters: tcpcrypt shows that even TCP — the most inspected protocol on the internet — can be hardened. If all TCP connections were encrypted by default, the adversary would have to inspect every TCP connection to find the ones they want to block.
Current status: tcpcrypt never saw wide adoption. It was standardized as RFC 8548 but is not widely deployed. The lesson is that protocol hardening works best when it is adopted by mainstream applications, not just by cypherpunk tools.
Summary Table
| Protocol | Transport | Key Technique | Censorship Resistance | Adoption |
|---|---|---|---|---|
| QUIC/HTTP3 | UDP port 443 | Encrypted by default, looks like random bytes | High (accidental) | Very high (30-50% of web traffic) |
| CurveCP | UDP | Single-packet handshake, minimal design | High (intentional) | None (superseded by QUIC) |
| obfs4 | TCP (any port) | Random-looking traffic, IAT obfuscation | High (intentional) | High (Tor Browser default) |
| DNS tunneling | UDP port 53 | Hide in essential infrastructure | Medium (detectable) | Low (malware, circumvention) |
| uTP | UDP | Delay-based congestion control, no handshake | Low (evades throttling) | High (BitTorrent default) |
| WireGuard | UDP (any port) | Minimal protocol, no visible handshake | Medium (accidental) | Growing (Linux kernel, VPNs) |
| Binary events | UDP | MTU-bound, cache-line-aligned, eBPF | High (intentional) | In development |
| IP fragmentation | IP | Hide data in fragments | Low (known to defenders) | N/A (attack technique) |
| tcpcrypt | TCP | Encrypt TCP handshake | Low (not deployed) | None |
The Pattern
Looking at all these examples, a clear pattern emerges:
The most successful censorship-resistant protocols are not designed for censorship resistance. They are designed for performance (QUIC), simplicity (WireGuard), or privacy (obfs4). The censorship resistance is a side effect of good design.
The protocols that are designed for censorship resistance (CurveCP, binary events) have low adoption. The protocols that accidentally provide censorship resistance (QUIC, WireGuard) have high adoption.
This suggests a strategy: design protocols that are better than the alternatives for legitimate reasons, and let the censorship resistance be a free benefit. If your protocol is faster, simpler, and more private than TCP, people will use it for normal things. Once billions of people use it, it becomes impossible to block.
Open Questions
-
Can we design a protocol that is explicitly for censorship resistance but also useful for normal things? QUIC succeeded because it was faster, not because it was censorship-resistant. Can we find another performance advantage that also provides censorship resistance?
-
What is the next MTU? The 1500-byte MTU is a legacy of 1980s Ethernet. Jumbo frames (9000 bytes) exist but are not universal. Is there a new substrate boundary we can exploit? IPv6? 5G? Starlink?
-
Can we make censorship-resistant protocols that piggyback on QUIC? QUIC is already deployed at massive scale. Can we design a protocol that looks like QUIC but is actually something else? This is the obfs4 approach applied to QUIC.
-
What about the application layer? Most censorship happens at the application layer (blocking specific websites, keywords, or content). Protocol hardening at the transport layer does not help if the adversary is blocking by domain name or content hash. How do we combine transport-layer hardening with application-layer evasion?
-
Is there a thermodynamic limit to DPI? Deep packet inspection requires energy proportional to the amount of traffic inspected. As internet traffic grows exponentially, the energy cost of total surveillance grows exponentially. Is there a point where DPI becomes thermodynamically impossible? This is the question from
first_thoughts.md— the "thermodynamic cost of tyranny."