Anonymity Is Censorship Resistance: Efficient Anonymous Broadcast Under Censorship

Transcript

[music] [music] >> I don't think it's working. Can you guys hear me? Oh, it's working. Terrific. All right. Um All right, let me start with a simple question. Um If a network can't see what you're saying, can it still decide whether your message gets through? So, we'll explore this through a simple auction, see how anonymous broadcast changes the picture, and then we'll ask what happens when someone actively tries to censor the network.

Let's start um with a simple auction. So, here you can see that Alice bids five, Bob bids seven, and Eve bids two. If it was a fair auction, Eve would stand no chance, right? But, Eve doesn't need to outbid Alice and Bob here. Imagine uh that instead she can influence an intermediary responsible for forwarding the bids to the auction. She arranges for Alice and Bob's bids to be delayed while her own makes it through before the deadline.

Now, look what happens to each of these bids. Alice's Alice's bids bid gets delayed, and so does Bob's, and Eve is the only bidder left. As a result, Eve wins the auction. Okay, so let's put the auction inside a trusted execution environment, a TEE. The computation in a trusted execution environment is protected. But, if we look at all the paths leading to it, Alice and Bob are still delayed, and Eve's bid still arrives on time.

That is to say that the protected computation can execute correctly even when someone deliv- uh interferes with the delivery outside of it. Putting the auction inside a protected environment does not automatically give every participant a protected network path. TEEs address computation, but we still need to address delivery. Fully homomorphic encryption. What if we encrypt the bids instead and use fully homomorphic encryption, right? The labels here show encryptions of five and seven and two.

The numbers, of course, are here to explain the example. Let's uh they're not planes plain text for the sensor in the hypo. So, even so, the sender paths they remain distinguishable. The reason for that is because the network addresses leak. So, FHE protects computation over encrypted values. It does not automatically hide where the traffic comes from or guarantee that it arrives before a deadline, right? Encrypted bids can still travel along the distinguishable paths. The same distinction matters when Alice submits a private transaction through a ZK-RPC relay. The relay can see the network endpoint from which her request

arrived. Depending on the setting, timing and maybe some later activity put together, it can correlate the request with something else and de- de-anonymize. Of course, this doesn't mean that every relay app that every relay learns Alice's real-world identity or that every request can be matched to an on-chain action. A correlation depends on whatever the observer can see and what information it has along with its capabilities. But, the point here is that payload privacy and submission path are different guarantees.

Hiding the transaction's does not by itself hide the trail left by its submission. Now, let's extend this to an AI workflow. Imagine I ask a personal agent to research an acquisition. A supervisor divides the task amongst company research and valuation and legal research. Some of their models call Some of their model calls pass through an AI gateway. Each one of these intermediaries has a different view.

And the supervisor, for instance, knows the assignments and receives the results. The gateway sees the requests at hand handles and provides it to routers and so on. The network observer has different and usually narrower views across the network. Nobody sees the whole graph, but it can be put together. The point is that linking requests does not by itself identify a person, but it may reveal a project that no single subtask explain. And the design question is whether our privacy protection survives the whole workflow and not just one request.

The common thread here is that a sealed message still rece- reveals a trail. Uh privacy inside a payload or a computation can coexist with the revelation of network metadata. Cryptography is doing its job within a particular model, but we need to be explicit about what other layers we must protect. Which brings us to anonymous broadcast. Anonymous broadcast is a way to publish me- messages while concealing the mapping between messages and their senders.

In uh anonymous broadcast, a group submits contributions and receives an unordered collection of messages. The privacy goal is to hide which honest sender supplied the honest message. Here, Alice, Bob, and Charlie participate, but the published result does not label each message with the sender. Of course, there are limits to that statement, right? A message itself can identify its author through its contents. An observer may also know something about who participated independently.

Anonymous broadcast does not erase all of that side information. And so, we have to keep these three properties separate. Confidentiality of the message and anonymity of the sender and delivery of the contribution. The protocol's guarantees depend on its trust assumptions and the network model. Those assumptions will never matter or Sorry, those assumptions will matter a great deal when we introduce a sensor. Before we do that, um you might wonder why anonymous broadcast, why not simply use Tor or a mixnet?

So, Tor is actually designed for interactive low-latency communication, but it doesn't defend against observer correlating traffic at both ends. Mixnets use cover traffic and mixing to make that correlation much harder, but the trade-off is delay and bandwidth. A Flashbots project, Panethia, takes a different approach. Participants contribute to a shared cryptographic computation, and the result reveals the messages without revealing their sender mapping.

This gives us a reason for optimism. We can pursue strong sender anonymity without making random mixing delay the main privacy mechanism. We still have to pay for communication, computation coordination and that brings us to the central challenge of the talk, which is a clean round could be fast, but can we keep it fast and anonymous when someone interferes with the participation? Panethia has three design goals.

Making anonymous broadcast work efficiently in practice is a pretty serious challenge. And so, the goals are first, that we want anonymity, strong anonymity to hide which participating client sent which messages and under the protocol's trust and network assumptions. Second, we want low latency. Especially in applications like auctions, a message arriving a few seconds or even milliseconds too late can be worthless. And third, we need resilience.

We want the system to keep working through specified faults rather than allowing every malicious contribution or failed participation to stop it. The challenge is getting these properties together without making the protocol prohibitively expensive or slow. And this is where Pantheer comes in, right? An anonymous broadcast uh protocol that is designed to prioritize strong anonymity and low latency with protections against certain forms of disruption. Okay, let's look at how it works.

At a high level, it works in three steps. First, each participant encodes and encrypts their message. And for the purpose of this walk-through, let's assume the multi-set encoding uses an invertible Bloom lookup table or IBLT. And we can think of this as a way basically of combining multiple messages into a single structure that later can be recovered uh that later individual messages can be recovered from. Each client also encrypts its encoded contribution using a fresh key.

And here's where the clever part, I think, lies. Instead of secret sharing the whole encoded message, the client secret shares only the short encryption key among the servers. The encryption contribution still has to The encrypted contribution still has to be published or distributed. Of course, right? Second, uh the contributions are combined. Pan tier uses key additive homomorphic homomorphic encryption, which lets encrypted contributions be added together, so their sum could be decrypted using the corresponding sum of keys.

Now, if we follow the two paths on the slide, on the upper path, you see cipher texts are combined by a recipient or an aggregator, and on the lower end lower path, you see servers combining key shares they hold and releasing aggregate key shares. These let the recipient reconstruct the combined key without reconstructing each other's individual keys. And third, the recipient recovers the messages. It uses the aggregate key to decrypt the combined cipher texts, and then decodes the multi-set structure to recover the collection of messages without a sender label attached to each one.

This is the central efficiency insight. Aggregate Aggregate the encrypted messages while secret sharing only the smaller keys. Of course, there are some additional protections. We use cryptography to hide hide the sender mapping, commitments to verify aggregate key shares, and client TEEs to enforce input rules essentially as a DDoS prevention. And to enforce the correct to make sure that there are only correctly formed contributions.

None of these checks by themselves, of course, will force a participant's packets to arrive, and that is a distinction that we need to keep in mind that protecting anonymity and checking contributions and ensuring delivery are connected, but they are very different problems. We'll return to this in just a moment. What happens when a protocol assumes participants won't collude, but the system itself creates financial incentives for them to do just that? MEV gives us really good reason to take that question deadly serious.

That is to say if controlling which transactions can get included determines who makes money, then it follows that there's a financial incentive to manipulate inclusion. And this is because it might be sometimes cheaper to pay someone to interfere than it is to compete fairly. And that means that we need to ask whether our assumptions about who will remain honest or realistic, especially when there's money on the table. It also raises a deeper tension in the way we look at the problem. So, traditionally, we would ask how many malicious participants a protocol can tolerate right?

Um, but in an environment like Ethereum, we should also ask how expensive would it be for an adversary to persuade enough participants to become malicious. A protocol may be perfectly secure as long as a majority of its participants remain honest, but what if honesty is for sale? And that is not a question that cryptography alone can answer. So, a couple of different trust models that you might hear. Um, honest majority assumes a majority of servers are honest.

Few trust relies on a specified small number of honest servers, and any trust commonly means that one honest server is enough for a specified privacy property. And the key term here is for a specified property. A threshold that protects privacy and does not automatically guarantee availability. Few trust also needs a concrete numerical threshold, and the name alone is not a security statement. The The takeaway here is that one ought to advocate or explore, at the very least, weaker honesty assumptions in the guarantee of anonymity.

When we say a system needs a certain number of honest servers, we also need to ask who operates those servers. And what new modes of vulnerability this might introduce into the system. And so if the previous slide asked what happens when collusion pays, this one asks how socio-legal variables like operational control and institutional pressure fit into the same threat model. So in the hypothetical in the hypothetical deployment on on the slide, you see four nodes belong to two operators and both operators use the same hosting provider.

Four nodes identities do not therefore establish four [snorts] independently controlled organizations. And the shared host is yet another dependency that needs to be examined. The meta point is that we need to examine the organizations and the dependencies behind node count. And the next three slides are an attempt to basically make this concrete. First, we'll see what anonymity looks like when everyone's contribution goes through.

Then we'll give the censor one power deciding whose contribution arrives, and then we'll try a simple defense requiring enough participants before releasing an outfit and an output and evaluate what it does protect and what it costs. And then we'll ask whether protecting each round is enough to protect someone across multiple rounds. So let's make a Let's make this extra concrete with a simple example of anonymous broadcast. Imagine Alice and Bob and Charlie each submit a message. The protocol publishes all three messages together without identifying who sent which one.

And importantly, the order that you see on the slide doesn't really tell you anything about who submitted them. That's the the anonymity guarantee that we're interested in, right? That's the published messages don't reveal which honest participant sent which one. So, of course, that doesn't mean that like messages are completely untraceable. Alice could still identify herself through content of her message. Uh or an observer might have information from somewhere else that helps connect the message to its sender, but the point is that the broadcast output itself doesn't reveal the connection.

So far, so good. Everyone participates. All three messages appear and the protocol preserves the uh sender message anonymity that we're looking for. But now, let's introduce Eve, right? She can't identify which message belongs to Alice from the published output. But instead, she might try to interfere with Alice's connection before before her message ever reaches the protocol. And I think that's where things begin to get interesting. So, imagine Eve successfully blocks Bob and Charlie from participating in the round.

And basically, that leaves Alice as the only participant whose message makes it through. And now, suppose the protocol publishes the surviving message, message three here on the slide. Because Eve knows that Bob and Charlie were excluded, she can infer that the message must have come from Alice. And notice that Alice notice that Eve didn't have to. She didn't have to break encryption. She didn't steal a single key. She simply eliminated the other possible senders until Alice was the only one left.

In other words, Eve didn't break the anonymity. She removed the anonymity set. Yep. So, that might preserve Alice's anonymity, but now nobody's message gets delivered to the round. Forgive me, a protocol could instead refuse to publish anything and abort the round entirely. That might preserve Alice's anonymity, but nobody's message would get delivered in the round. And so we predicted protected privacy at the expense of liveliness or the ability of the protocol to actually complete.

So now Eve has created a different dilemma. Publish the result and potentially expose Alice or abort the round and let censorship succeed. And that brings us to an important design question. How do we prevent the anonymity set from becoming so small that messages could be traced back to individual centers? One possible defense is to require a minimum number of participants before the protocol releases anything. But as we'll see, that comes with its own issues. So let's try that defense. Announce a three-client roster and require at least two of those clients to participate before publishing the output. If Eve blocks both Bob and Charlie, then Alice

remains and the round aborts for being below the minimum required participants. That blocks the isolation attack that we just saw, but it also means that Eve can prevent delivery by excluding enough clients writ large. So what if Eve gets a little smarter and instead of blocking two participants, she just blocks one? And let's say she changes who she blocks from round to round so that every individual round satisfies our anonymity threshold. Nobody is isolated, nothing gets aborted, but here's the question.

What happens when Eve starts comparing the results across multiple rounds? In round A, Eve blocks Bob. Alice and Charlie remain and the output contains the messages associated with identities Y and Z. In round B, Eve blocks Alice. Bob and Charlie remain and the output contains messages associated with identities Y and X. And now assume those identities are stable and linkable across rounds, for example, through signatures under persistent pseudonyms and such.

Charlie is the only participant present in both rounds and Y is the identity that appears in both outputs. And so in this example, Y maps to Charlie. And that also leaves Z mapped to Alice and X mapped to Bob. And note that the payloads don't need to be identical. A recurring linkable identity can be enough. There's also a performance problem. The optimistic case is fast because expected inputs arrive and parties can aggregate them. Selective dropping can force recovery and coordination

about which participants belong in the round. An adversary, for instance, may trigger that process repeatedly and weaker honest honesty assumptions can make the coordination more demanding. The cost depends on the protocol's actual delivery and agreement mechanism. Anonymous broadcast protocols don't have all the identical recovery design. That means that the clean round benchmark is only part of the picture. And we need to understand the cost of disruption, the cost of recovery, and how often an attacker can force us to pay those costs. The practical objective is to retain useful performance when interference is deliberate and when interference is repeated.

To that end, I would organize next steps around three research questions of delivering, recovering, and deterring. First delivering. How do we keep honest inputs included under active interference? Second, recovering. When something goes wrong, how do we keep recovery fast? And third, deterring. Can we make disruption costly enough that an attacker has less reason to attempt it in the first instance? And these are obviously some very open research directions.

And the grouping is a way of organizing the problem, and not a claim that the draft already specifies a complete defense. An economic defense, for instance, needs evidence of misconduct. And it must distinguish attacks from innocent packet loss without creating another way to harm honest participants. I think the challenge is to combine delivery, recovery, and incent- and incentives while preserving the latency that makes the system useful. Anonymity can make sender-based discrimination harder.

In the other direction, selective censorship can undermine anonymity by controlling who participates. When these properties interact, neither automatically implies the other. Strong cryptography obviously matters, and so does the surrounding system. Who gets to contribute? What happens when someone is excluded? And what does an attacker learn by changing that set over time? The delegation example of AI delegation asks what a sequence of requests might reveal.

Other research might wonder, or might in- uh interrogate, who controls the infrastructure and what pressures can reach them. Both help us test whether a system around cryptography matches its assumptions. And the promise is low-latency anonymized broadcast. The hard work is preserving that promise under active interference. Hide the center, protect participation, and because exclusion can become um identification. Thank you. Uh I'm Ahmed Ghappour. Uh credit for uh the original talk and visual storytelling goes to Mateusz Morawiecki and credit for the Palantir

research goes to my colleagues Neil Fleishhacker, Mateusz, and Mark Simkin. >> [music]