Updates, insights, and community posts from 1st Amendment Encrypted Openness.
Every additional exact prefix character requires 32 times more search work on average. Learn why average time is not a deadline, what a 95% chance means, and how to compare realistic estimates. Read more
Every .onion address depends on the HSDir relays that store its descriptors. Under the flood their number fell from a ~5,800 plateau to just 945 relays on July 22 — and 728 of the losses were relays stripped of the role without ever restarting. It has since recovered most of the way, but remains about a third below where it started. Public, reproducible CollecTor data. Read more
The June–July flood is not an event, it is a chapter: ten distinct episodes since September 2025, forming two major campaigns. Autumn 2025 was ~22x larger by raw rate and the network absorbed it; the summer 2026 campaign accumulates state instead of rate — and its tenth episode did what no earlier wave managed, pushing 135 of our own relays into overload. Being wound down mode by mode, but not over. Read more
The worst single day showed 12.87% of relays overloaded — but the flood rotated: over five weeks it touched 4,559 distinct relays, nearly half the network and 57.2% of all Guards, hitting big and small guards at the same rate. All from Tor's public archives. Read more
MaxMemInQueues counts specific queues and caches — and this flood's memory lived outside all of them. A relay hit 11.7x the defense's ceiling without triggering it, and fleet-wide the defense freed less than 2% of what the kernel OOM-killer had to reclaim. Plus a config footgun that trips the defense with no attack at all. Read more
Five weight-matched relay pairs, same flood, opposite endings: every glibc relay held its memory balloon until the kernel terminated it; every mimalloc twin drained itself and survived. What the allocator decides, what swap decides, and the paging data showing swap held only idle memory — the active relays never thrashed. Read more
Since late June the whole Tor network has been under a circuit-building DoS wave — reconstructed here entirely from Tor's own signed public archives (CollecTor + Onionoo): two overload waves reaching ~12% of all relays, the flood landing squarely on the guard position, and the Running flag flapping network-wide. Every number is reproducible. Read more
How the attack actually works. Since Jun 25 23:00 UTC, open circuits on 1AEO's guard fleet ran ~20x peak — arriving as four waves offset in time (an onion-service INTRODUCE2 burst, the main ntor_v3 circuit flood, a malformed-circuit tail, and a late directory-write surge), each tripping a different one of Tor's built-in defenses and riding Tor's own path machinery to pick which relays it hit. Read more
What absorbing the flood costs an operator — and how 1AEO ranked. The circuits are cheap to send; soaking them up pegged host CPU at 90–99% and drove memory to OOM, while the relays never stopped relaying. From Tor's public data, 1AEO held at 0.3% of guards overloaded — the most guards at the lowest overload of any major operator. Read more
Underneath the circuit flood ran a second flood no Tor counter records: the Linux kernel on 1AEO's relay hosts silently dropped ~1.3 billion fully-completed TCP connections at the accept queue — roughly 900 per second for two weeks, beginning 1–2 days before the circuit flood. Tor's per-IP defenses fired 27 million times and it didn't matter: the kernel dropped ~40x more, upstream of them all. Read more
Better metrics and what Tor could fix. How to see an attack like this without logging anything about the traffic or its sources, the two measurement traps that nearly fooled us, and the protocol-level changes we're asking the Tor Project to weigh — per-source limits that compose into a per-relay cap, proof-of-work for circuit creation, and RSS-aware OOM handling. Read more
5-Way Deployment Blog: Testing 5 allocators on 100 relays (20 per group) with Debian 13.2 for 6-10 days showed mimalloc 2.0.9 (1.41 GB) used 7.4× less memory than 3.0.1 (10.44 GB), so we migrated all 200 production relays to 2.0.9. Read more
After testing allocators, config tweaks, and restarts across 100+ relays, we found that switching to mimalloc or jemalloc is the only fix that actually stops Tor guard memory from ballooning to 5+ GB. Read more
Our 90-relay experiment on Ubuntu 24.04 proves that swapping glibc for mimalloc (79% reduction) or jemalloc (71% reduction) keeps Tor guards under 2 GB without recompiling or losing Guard status. Read more
Disabling DirCache cuts memory by 94%, but it also removes your Guard flag—making it a diagnostic proof point rather than a viable solution for production Guard relays. Read more
Despite its promising name, MaxMemInQueues only limits circuit buffers—not the directory cache fragmentation that actually causes Tor relays to bloat to 5 GB. Read more
Scheduled restarts can reduce memory by up to 19%, but they disrupt circuits and still leave you at 4.5 GB—use them only as a stopgap while migrating to a better allocator. Read more
Limiting how long Tor keeps consensus diffs had zero impact on memory—all test groups ended at 5.6–5.8 GB, proving the fragmentation problem lies in glibc, not cache retention. Read more
A straightforward guide to the leading Tor relay dashboards—compare their bandwidth stats, update frequency, map views, and detailed features to monitor your nodes and network with ease. Read more
Supercharge your Tor relay deployments with turnkey BGP configs that take you from zero to announced in minutes. Read more
Running a 10 Gbps Tor relay at maximum capacity reveals lessons every operator should know before scaling up. Read more
A recent thread on the Tor-relays list raises a fundamental question for operators: is it better to deploy a single high-capacity server, or several smaller ones distributed across locations and providers? Read more