Today's article comes from the journal of Cybersecurity. The authors are Buccafurri et al., from the University Mediterranea of Reggio Calabria, in Italy. In this paper they're exploring how Tor can be extended to provide recipient anonymity even in the presence of a global adversary.
DOI: 10.1186/s42400-025-00388-z
Today's story begins in the 1990s inside the U.S. Naval Research Laboratory, where Paul Syverson, Michael Reed, and David Goldschlag were wrestling with a very specific problem. How do you let people communicate over the internet without revealing who is talking to whom?
Their solution was called "onion" routing: a method of wrapping messages in multiple layers of encryption and sending them through a sequence of relays, so that no single point in the network could see the whole picture. Each relay would know only where a message came from and where it was going next, but never the true origin and final destination at the same time. This technology was eventually released to the public, and Tor was born.
Today, Tor is much more than a research curiosity. It is a critical piece of internet infrastructure used by people around the world. Journalists rely on it to communicate with sources. Activists use it to evade censorship. Ordinary citizens depend on it to bypass surveillance in countries where accessing basic information can be dangerous. And even outside of overtly political contexts, Tor underpins privacy-sensitive services such as whistleblowing platforms and anonymous publishing.
But there is a catch. Tor's anonymity guarantees are asymmetric. It does a good job of hiding the sender, but the recipient side is much more fragile. In particular, if an adversary can observe traffic across the network as a whole, the structure of Tor circuits still leaks who the communication is ultimately destined for (the final recipient). Tor's services were designed to hide server locations, but they still do not fully solve this problem if there's a global observer. The traffic still converges. The last hop still stands out. And with enough visibility, the recipient can be inferred.
That's a problem. And that's the one today's paper is tacking head-on. In it, the authors are exploring how Tor can be extended to provide recipient anonymity even in the presence of a global adversary. Their answer is not to abandon Tor or to replace it with a different system, but to modify its circuit structure and traffic patterns so that the true recipient becomes hidden inside an anonymity set. Their study introduces two designs: L-Tor and B-Tor, and they walk through the viability of both. Let's dive in.
First we need to understand the whole "global observer" threat a bit more. This is someone (or some state or institution) that can passively observe traffic across large portions of the internet at once, including multiple independent network paths. You might think that nobody could possibly monitor an entire end-to-end communication path from user to destination, but you'd be wrong. More entities are capable of this than you'd think. Large ISPs working together, nation-state intelligence agencies, anyone with the resources to monitor traffic across major internet exchange points could do this. And these aren't hypothetical threats. They're real, they're documented, (that's one of the things Edward Snowden's disclosures in 2013 made clear). These are exactly the kind of adversaries that Tor was supposed to protect against.
So why could a global observer see the recipient for a given sender? Well, let's start with some Tor fundamentals. In standard Tor, when you want to connect to a website or service, your Onion Proxy, that's the client software running on your machine, selects three relay nodes to form a circuit. The first is called the entry router, the second is the middle router, and the third is the exit router. The Onion Proxy establishes a secret key with each of these nodes using Diffie-Hellman key exchange. Then, when you send a message, it gets encrypted in layers, one layer for each relay.
This provides sender anonymity against local observers. If someone's watching just your internet connection, they can see you're using Tor, but they can't see where your messages are going. If someone's watching just the destination server, they can see messages arriving, but they don't know where they came from. But this isn't true for the global observer. If someone can watch both your connection and the destination server, they can correlate the timing and volume of traffic and figure out that those messages are connected. Now, when you want to connect to a hidden service, what Tor calls an "onion service," things get more complicated, but the same basic problem is still there. A global adversary can still watch the whole thing.
That's the problem today's authors are trying to solve. How do you extend Tor to hide the recipient even when someone's watching everything?
One approach is what the authors call L-Tor, for Linear-Tor. Instead of connecting to one rendezvous point, you connect to many of them, arranged in a chain. Somewhere in that chain, one of the rendezvous points is connected to the recipient. The others are decoys. You send your request through all the rendezvous points, and each one forwards it to its associated hidden service. But only one of those hidden services is the real destination. The others receive encrypted dummy traffic. When the responses come back, the actual rendezvous point injects the real response into a stream of cover traffic flowing back through the chain to you. This works...in a way. The anonymity is real. The problem is performance. To set up this circuit, the client needs to do a Diffie-Hellman exchange with each rendezvous point in sequence. Each exchange involves multiple messages going back and forth through an increasingly long circuit. The setup time grows quadratically with the number of rendezvous points. So with just a few dozen points you could end up needing to wait 15 minutes or more before you can send your first byte of data.
The authors thought they could do better. That's where B-Tor comes in. The core idea is that you don't need a linear circuit. You can build a tree. Instead of stringing together all your rendezvous points in one long chain, you organize them hierarchically. You start with a small number of Branch Rendezvous Points, or BRPs. Each one builds its own circuit to several Chain Rendezvous Points, or CRPs. You arrange things so that the total number of rendezvous points gives you the anonymity set size you want.
Here's how the setup works. The client selects the hidden services it wants to hide among, including the AOS (the Actual Onion Service). It selects the BRPs and, for each BRP, it selects the CRPs that will form that BRP's branch. The ARP, the actual rendezvous point connected to the AOS, is one of these. It could be a BRP, or it could be a CRP.
Now the setup happens in parallel. The client builds the main circuit through the BRPs, which still does take time that grows quadratically with the number of BRPs. But while that's happening, each BRP is building its branch circuit through its CRPs, and those constructions all happen at the same time. The total setup time is dominated by the main circuit construction plus one branch construction, not by all of them added together.
Once it's all set up, the client sends its request through the main circuit to the ARP (whether that's a BRP or a CRP). Each BRP along the way receives the message, strips off a layer of encryption, forwards it to the next BRP, forwards a dummy message down its branch circuit to all its CRPs, and forwards the original message to its associated hidden service. When the message reaches the BRP that contains the ARP in its branch, it forwards the real request down that branch. The ARP, or the BRP if it's the ARP itself, forwards the real request to the AOS. Each CRP that receives a message does the same thing: strips a layer, forwards to the next CRP, forwards to its associated hidden service. The services that aren't the AOS receive encrypted dummy traffic. The AOS receives the real plaintext request.
For the response phase, all the terminal CRPs, that is the last CRP in each branch, generate bursts of data cells filled with cover traffic. These flow back up each branch. When the traffic reaches the ARP, it replaces the dummy cells with the actual response from the AOS. The other CRPs just forward and encrypt. When the branch traffic reaches each BRP, that BRP receives two flows: one from its branch and one from the next BRP in the main circuit. The BRP chooses a data rate for the forwarded traffic equal to the maximum of the two incoming rates, padding with cover traffic if necessary to maintain that rate.
The result? From the global adversary's perspective, every rendezvous point, both BRPs and CRPs, looks busy. They all receive traffic, they all send traffic, and the actual response is hidden within cover traffic flows. The communication latency is proportional to the number of BRPs plus the number of CRPs in one branch, instead of proportional to the total number of rendezvous points like in L-Tor. That means your data travels through fewer hops, and the time it takes to download files doesn't balloon beyond reason.
So does it work? Well it's early days, but yes it appears to. The authors show, through both analytical modeling and experimental evaluation, that their design meaningfully raises the cost of recipient deanonymization for a global observer, without blowing up latency. When they tested L-Tor it did what their theory predicted and became impractically slow. But B-Tor was able to preserve the system's low-latency behavior while hiding the true recipient inside the set.
Want to go deeper? If you're working on anonymous communication systems, privacy tools, or if you're just curious about the technical details I'd highly recommend downloading the paper. It includes the derivations for the security proofs, descriptions of circuit construction and message routing algorithms, complete simulation parameters and results for all the configurations they tested.