-
What is panetière?
Panetière is an anonymous broadcast protocol. In panetière, clients running in a trusted execution environment hold messages they want to publish and servers provide the service through which they can do so anonymously.
- Watch the presentation at SBC: https://www.youtube.com/watch?v=a-yHygE-wSU
- Read more in the draft whitepaper: https://net.flashbots.net/panetiere-draft.pdf
- See the implementation in GitHub - flashbots/panetiere: Work in progress reference implementation of Panetière: efficient anonymous broadcast. · GitHub
-
What is an anonymous broadcast?
In an anonymous broadcast a group of clients each contribute either a message or cover traffic, and at the end anyone can read all the messages, but no one can tell which client sent which.
Two things it deliberately does not do. It does not hide the content of the messages, since publishing them is the whole point. And it does not hide that you took part: an observer sees you in the broadcast, they just can’t tell what you said, or whether you said anything.
The set of clients who could plausibly have sent a given message is the anonymity set, and it’s the measure of how much anonymity you actually get. Most of the engineering in Panetière is about making a large anonymity set affordable.
-
What are some previous works that have served as inspiration and building blocks for panetière?
In DC-Nets (“Dining Cryptographers” Nets) participants simultaneously contribute to a shared computation that reveals a batch of messages without linking sender to message. DC-Nets can provide strong sender anonymity with moderate latency in synchronous settings, but typically at the cost of higher bandwidth and computational overheads.
A recent anonymous communication protocol called ZipNet made a simple, but powerful observation. When designing an anonymous communication protocols, many of the computational and bandwidth inefficiencies stem from the need to ensure liveness, rather than anonymity. Leveraging this observation, ZipNet ensures liveness with the help of TEEs and ensures anonymity via classical cryptographic means. Should a TEE be broken, the system may become unresponsive, but anonymity does not rely on the security of TEEs.
See Avoiding Client Disruption in Anonymous Broadcast Protocols
-
What is a trusted execution environment?
A trusted execution environment (TEE) is an area of the computer processor that isolates execution code and data and protects them from being accessed by other processes executing in the same processor. It also provides an attestation that works as a proof that the processor executed the requested code unmodified, to protect from backdoor attacks .
-
Why do clients have to run in a trusted execution environment?
Every client’s contribution is added together, and the messages are recovered from the total, so a single malformed contribution can make the broadcast fail for everyone. Anonymity also depends on each client placing their message at a position chosen independently and uniformly at random; a client who picks positions some other way weakens their own anonymity and can leak others’ anonymity.
-
What happens if a client breaks their TEE?
They cannot learn who sent what. What they can do is make the broadcast fail for everyone. Anonymity rests on the cryptography, not on the hardware — the servers jointly reveal only the sum of all clients’ encryption keys, and that summed key decrypts only the summed ciphertext. When the broadcast fails, either no valid key is revealed, or the revealed key doesn’t correspond to the sum of the clients’ contributions. In any case, no individual messages can be decrypted. This is a designed split: use TEEs for liveness, post quantum cryptography for anonymity. See the question on previous works above.
-
What are the cryptographic primitives and constructions used in panetière?
- Additive vector commitments with addition hiding — the sum of the clients’ commitments opens to the sum of their key shares, and reveals nothing about the individual shares. The client publicly commits to its whole share vector, and gives each server the opening for its own position; a server must then publish an opening that verifies against the sum of all the clients’ commitments.
See: - Extractable and equivocable commitments — used to lift the protocol from relaxed anonymous broadcast to full anonymous broadcast. Two sequential broadcasts: commit in the first, open in the second. Also twice the latency and bandwidth. Extractable means the message can be recovered from the commitment; equivocable means a commitment can be opened to a different message than the one committed. Both properties are used only in the security proof; they are not for a real participant.
See: - Key-additive homomorphic encryption — encrypting under two keys and adding the ciphertexts gives the encryption of the summed messages under the summed key. This lets each client encrypt a long vector while the servers only ever run secure addition on short keys. It is safe to publish that summed key because of addition privacy: the summed key decrypts the summed ciphertext and nothing else.
See: - Invertible bloom lookup tables — a Bloom filter tells you whether something is probably in a set. An invertible bloom lookup table can in addition list the items, with high probability, when the table is sized for the number of items expected. The tables are built from sums, so separately built tables can be added together, and the result lists everything as if all the items had been inserted into one table.
See: - Secure vector addition — each client splits its value into shares, sends one share to each server, and each server publishes the sum of the shares it received. Because the sharing is linear, adding up what the servers published gives the sum of the original values — and no server ever saw anything but noise. Clients holding vectors instead of single values do the same thing component-wise.
See: - Threshold secret sharing — split a key into one share per server, so that roughly half the servers together can reconstruct it and any fewer learn nothing. Adding shares gives the shares of the sum.
See: - Public-key encryption — everything else in the protocol is broadcast in the open, but each server has to receive its own key share without seeing anyone else’s. Each client encrypts a server’s share under that server’s public key, so only that server can read it, along with the opening proving the share is the one committed to. This assumes the servers’ public keys are already published and known to the clients.
See: - Pseudorandom functions — a pseudorandom function produces output indistinguishable from random, but does so deterministically from a key, so everyone holding the key computes the same positions while anyone without it sees noise. Inside the invertible bloom lookup table, they turn each message’s random value into the cells it lands in.
See: - Lattice-based cryptography — a lattice is a regular grid of points stretching out in many dimensions. Two hardness assumptions secure the protocol. The Short Integer Solution problem, which the commitments rest on, is the problem of finding a small combination of given values that sums to zero — easy if the coefficients can be large, believed hard if they must stay small. Learning With Errors, which the encryption rests on, is the problem of recovering a secret from many noisy linear equations — easy without the noise, believed hard with it. In both cases the given values define a lattice, and the thing to look for is a point in it.
See: - Negacyclic rings — the polynomial ring Z[X]/(X^n+1) where the arithmetic actually happens, chosen so multiplication can use the number-theoretic transform.
See: - Residue number system — arithmetic modulo a large number is slow, so a large modulus can be replaced by several small coprime ones, with the work done independently modulo each and reassembled at the end by the Chinese remainder theorem.
See: - Trusted execution environments — not cryptography, but the outermost trust assumption: clients run inside a TEE so they can’t deviate from the protocol.
See:
- Additive vector commitments with addition hiding — the sum of the clients’ commitments opens to the sum of their key shares, and reveals nothing about the individual shares. The client publicly commits to its whole share vector, and gives each server the opening for its own position; a server must then publish an opening that verifies against the sum of all the clients’ commitments.
-
Is panetière secure to quantum attacks?
Panetière relies on the hardness of the short integer solution problem, which is currently thought, but not proven, to be secure against a cryptanalytic attack by a quantum computer.
See Short integer solution problem - Wikipedia and Post-quantum cryptography - Wikipedia
-
What are the security guarantees of panetière?
-
What are some use cases for panetière?
We are analyzing and prototyping many use cases for panetière. As we consolidate them and test them for security, we will be sharing the details.
If you have any use cases in mind, please reply here and we will help you analyzing them for security and performance. -
What kind of use cases are not protected by anonymous broadcast protocol like panetière?
Anything that needs the message kept secret. Every message is published in full — what is hidden is who sent it, not what it says.
Anything that needs your participation kept secret. An observer can see that you took part in a broadcast. They cannot tell whether you sent a message or cover traffic, but they can see you were there.
Anything where the message identifies its sender. The protocol hides the link between client and message; it cannot hide a signature, a wallet address, a username, or a writing style that only one participant has. What you put in the message is your responsibility.
Anything where too few clients take part. Anonymity comes from the size of the anonymity set. With two participants, an observer guessing has even odds, no matter how good the cryptography is.
Existing anonymity solutions, such as TOR and Nym, require users to choose between weak anonymity or high latency.
-
How does panetière relate to a mixnet like Nym?
Mix-Nets, such as Nym, achieve stronger anonymity against global passive adversaries. They rely on cover traffic, and batching and reordering of messages, which introduces delays. The result is increased end-to-end latency and higher bandwidth overhead compared to low-latency networks.
-
How does panetière relate to onion routing?
Onion routing, famously employed by the TOR network, is highly efficient in terms of bandwidth overhead and allows each client to asynchronously decide when to send their message. In practice, it can also achieve low latency, but at the cost of weak anonymity against adversarial network-level observers.
Do you have any more questions?
.