# AnonTestLab: Ten Years, Three Attempts, and One Idea That Wouldn't Let Go
TL;DR: the tool is at [hashtagrr.github.io/AnonTestLab](https://hashtagrr.github.io/AnonTestLab/). The rest of this is how it came to exist.
## Round one: an idea and no coding experience to build it
I got my hands on the Tor Browser almost ten years ago. It did the thing it does to a lot of people. The internet suddenly felt much bigger than I'd assumed, and I got curious about the machinery underneath. Digging into that, I learned about Tor's exit-node problem: traffic sits unencrypted between the exit relay and its destination unless the destination itself uses TLS. That fact stuck with me. At the time I'd built a shopping cart, a learning management system, and an exam management system for coursework, and nothing resembling network research. I decided anyway that I was going to design a new anonymous communication protocol as my final-year project.
I want to be honest about where I actually was, skill-wise. Nowhere near ready. I was ambitious though, so I pitched it. My supervisor laughed. He told me they weren't looking for something like that, they were looking for something with Cisco. I was devastated at the time. Looking back, that redirection is probably the only reason I didn't fail the project outright, because I didn't have the tooling to pull off what I was proposing yet.
That could have been the end of it. It wasn't.
* * *
## Round two: theoretical, and still not enough
A few years later I started an MSc in cybersecurity, and the idea hadn't gone anywhere, so I gave it another go. This time I delivered a full theoretical design for an anonymous communication protocol, and it did well. It got selected as one of the top ten projects in the program. Naturally I tried to get it published next. I hit the same wall, in a more specific shape. Reviewers wanted an actual implementation with actual results, and I had a design on paper.
So I decided I'd build it.
* * *
## Round three: three years, a full-time job, and a new country
The timing helped in one way I hadn't planned for. LLMs were becoming genuinely useful right around when I started, and that support is a real part of how I managed to write a codebase this size without the years of systems-programming background it would otherwise have taken. Everything else about the timing worked against me though. I was managing a full-time job, moving to a new country, and settling in, all while trying to implement a protocol I'd been circling for most of a decade. It took three years. It's currently in submission, and I'm waiting on the results.
Somewhere in that process, something shifted in how I thought about what I'd built. The protocol was the original project. The testing infrastructure became the unexpected one. By that point I had a genuinely large codebase. I'd tested my own network design against more than fifty test cases, and worked through nearly every combination of mix-network design and cover-traffic strategy I could think of to validate my own research. I realized that codebase wasn't just my research artifact anymore. It was something other people working in this space could use to get their own measurements, if I separated it out and released it properly. So I did. I made some changes and released it as its own project: AnonTestLab.
![](https://cdn.hashnode.com/uploads/covers/69b9861bc22d3eeb8ad2fb13/662587f5-e58a-47e8-a6cd-d13ef0ccf010.png align="center")
* * *
## What "real" actually means here
The one property I refused to compromise on, going all the way back to that exit-node fact, was that measurements had to be real, not modeled. AnonTestLab spins up relay nodes as genuine OS processes, each bound to its own loopback address, `127.0.0.1`, `127.0.0.2`, and so on, up to 254 addressable relays in a single run. They're connected by a telescoping circuit in the Tor sense, with a real ECDHE handshake per hop, real AEAD encryption, and hop-local circuit IDs so no single identifier is shared across two links of the same path. Latency, delivery rate, and correlation success all come out of actually running the protocol over actual sockets on localhost, where I can be sure the numbers are measured and not assumed.
![](https://cdn.hashnode.com/uploads/covers/69b9861bc22d3eeb8ad2fb13/43ec3f73-6257-4918-b70b-fb9c01295d7a.png align="center")
There's no directory or consensus system, and the wire format is my own, so this isn't a protocol-level reimplementation of Tor. It's a research harness, and crypto is a first-class axis in it: six AEAD ciphers across three ECDHE curves, two routing strategies, three traffic distributions, and four adversary models. That works out to 432 testable configurations. The number sounds like a feature count, but what it actually represents is the difference between rewriting experimental code for every new research question and just changing a config file.
![](https://cdn.hashnode.com/uploads/covers/69b9861bc22d3eeb8ad2fb13/1f28f2e2-d85a-4eb4-ad65-f44850f33404.png align="center")
* * *
## How an experiment actually runs
A YAML config drives the same pipeline every time: topology, a routing strategy, a traffic pattern with optional cover traffic, optional cell shaping, a crypto algorithm, per-hop WAN conditions, and one or more adversaries watching the result. `tor_like` is a fixed baseline preset. `custom` opens every dimension. Either way you get a results directory with the config, the seed, a metrics CSV, and a generated report.
Four adversary models sit on top of that, and each one answers a genuinely different question. `global_observer` correlates entry and exit traffic, with visibility restrictable by path count or network position instead of a flat "sees everything" assumption. `path_compromise` doesn't need packets to move at all, it's a Monte Carlo generalization of the textbook single-path compromise probability to multi-path sessions. `watermark` is active: a relay delays every Nth real packet, and the model checks whether that pattern survives real per-hop jitter, a question a distribution-sampled model can't answer honestly. `hop_depth` is the newest. Fixed-size cells in this harness still shrink by a fixed amount per hop, so instead of leaving that as a footnote, `hop_depth` measures how recoverable a cell's position is from its size alone. A leak you've measured carries more weight than one you've only disclosed.
* * *
## What I'd tell someone before they trust a result out of it
Per-edge link conditions are directional only. Keys are ephemeral, with no relay identity or directory system. `bandwidth_weighted` routing deliberately skips Tor's guard/exit-flag rules. And the experiment design is reproducible from its seed, but real measured latency isn't, because it's real, and real timing varies run to run.
These are the current, honest boundaries of what a research harness answering one specific question actually covers, not claims about security properties the tool doesn't have.
* * *
## Where this leaves me
I still don't know if the underlying protocol I've spent a decade circling will get published. That result is out of my hands right now. AnonTestLab exists independently of that outcome. It's the measurement infrastructure I had to build to even attempt an answer, and I'd rather other people working in this space have it than let it sit in a private research repo waiting on a review process.
Maybe nineteen-year-old me wasn't ready to build what he was proposing. The idea itself wasn't wrong though. It was just early.
> *AnonTestLab is open source under GPL-3.0. The full spec is at * [*hashtagrr.github.io/AnonTestLab*](https://hashtagrr.github.io/AnonTestLab/)*, and the source is at * [*github.com/hashtagRR/AnonTestLab*](https://github.com/hashtagRR/AnonTestLab)*.*