💻 computer science

Pepper: High-bandwidth and Scalable Anonymous Broadcast with Cryptographic Privacy

Pepper is a high-bandwidth, scalable anonymous broadcast protocol that leverages a two-server DC-net architecture with novel cryptographic primitives to achieve global sender anonymity, support batch messaging, and deliver significantly higher throughput than existing state-of-the-art alternatives without requiring external dialing services.

Original authors: Chenghao Li, Haoyuan Wang, Xianghang Mi

Published 2026-06-04

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Chenghao Li, Haoyuan Wang, Xianghang Mi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are in a crowded, noisy room where everyone is shouting. You want to whisper a secret message to the whole room, but you don't want anyone to know who you are. In the digital world, this is called anonymous broadcasting.

The paper introduces Pepper, a new system designed to let people send large amounts of data (like files or videos) anonymously, even if a powerful global spy is watching every single network cable.

Here is how Pepper works, explained through simple analogies:

1. The Problem with Old Systems

Previous systems were like a single-lane bridge.

One car at a time: You could only send one tiny message at a time. If you wanted to send a whole book, you had to break it into millions of tiny pieces and cross the bridge one by one. This was incredibly slow.
The "Dialing" Issue: To get on the bridge, you needed a separate, mysterious "dialing service" to give you a ticket. The old systems didn't explain how to get that ticket; they just assumed you had one.
Traffic jams: Because everyone had to wait their turn, the system was slow and couldn't handle big data transfers.

2. The Pepper Solution: A Multi-Lane Highway

Pepper is like a massive, multi-lane highway where you can send a whole convoy of cars (messages) at once.

Innovation #1: The Self-Contained Ticket Booth (Registration)

In the old days, you had to go to a separate, unexplained office to get a ticket.

Pepper's approach: The highway has a built-in ticket booth. You walk up, hand over your request anonymously, and the system checks if your ticket is valid without ever asking for your name or seeing your face.
The Magic: It uses a cryptographic trick called a "Verifiable Distributed Point Function." Think of it like a magic envelope. You put your request inside. Two guards (servers) open the envelope together. They can verify the envelope is real and sealed correctly, but they cannot see what is inside or who put it there. If it's fake, they throw it away. If it's real, they stamp it and let you in.

Innovation #2: The Convoy System (Batch Messaging)

This is Pepper's biggest superpower.

Old Way: If you wanted to send 8 messages, you had to make 8 separate trips across the bridge. Each trip required a security check (audit).
Pepper's Way: You load all 8 messages onto a single truck. You drive across the bridge once. The guards check the truck once.
The Result: Instead of paying a security fee 8 times, you pay it once. This makes the system 13 to 20 times faster for sending large amounts of data compared to the best existing systems.

Innovation #3: The "Ghost" Drivers (Cover Traffic)

To hide who is sending the real message, Pepper needs "cover traffic"—people who send dummy messages just to blend in.

The Problem: In old systems, only people with a special key could send messages. If you didn't have a key, you couldn't help hide the sender.
Pepper's Solution: Pepper creates "Phantom Channels." These are like fake lanes on the highway that no one actually uses for real data. Anyone can drive a dummy car into these lanes.
The Benefit: This allows regular users (like people just browsing a social network) to naturally generate cover traffic without needing special keys. The real sender hides in the crowd of these "ghost drivers."

3. How It Keeps You Safe

Two Guards: Pepper uses two servers (guards) working together. As long as one of them is honest, your identity remains safe. Even if the other guard is a spy, they can't figure out who sent the message.
No "Global Spy" Can Crack It: The system is built on math problems that are currently impossible to solve (like factoring huge numbers). Even if a global spy watches every packet of data, they can only guess who sent a message with the same probability as flipping a coin.

4. Real-World Performance

The authors built a working version of Pepper and tested it:

Speed: It can register new users in just a few milliseconds.
Scale: It works efficiently even with thousands of channels.
Comparison: When sending large files, Pepper is 1.2 to 20 times faster than the current state-of-the-art systems (like Spectrum or Express).
Compatibility: It's designed to work alongside existing networks like Tor (the onion routing network) and Mastodon (a decentralized social network). Imagine your favorite social media app having a built-in "anonymous mode" that uses Pepper to let you post sensitive information without fear of being tracked.

Summary

Pepper is a high-speed, anonymous mail system. It solves the problem of "how do I send a huge file without anyone knowing it's me?" by letting you send a whole convoy of messages in a single trip, using a built-in ticket system that doesn't require a separate office, and blending your real messages with a crowd of "ghost" drivers to hide your tracks. It is faster, more efficient, and easier to deploy than anything that came before it.

Technical Summary: Pepper

Problem Statement

Anonymous broadcast protocols (ABPs) are essential for privacy-sensitive applications like whistleblowing and censorship-resistant publishing, yet practical high-bandwidth deployment faces persistent challenges. While traditional systems like Tor offer low-latency routing, they remain vulnerable to global traffic-correlation attacks. Cryptographically guaranteed alternatives based on Dining Cryptographers networks (DC-nets) and mix-nets offer stronger anonymity but suffer from critical limitations:

External Dependencies: State-of-the-art systems like Spectrum and Express rely on unspecified external "dialing" or registration services for channel allocation, leaving a gap in end-to-end protocol specification.
Throughput Bottlenecks: Existing DC-net variants typically restrict broadcasters to one message per epoch, making them impractical for large data transfers (e.g., broadcasting a 1GB file can take over 13 hours).
Complex Auditing: Robust access control and auditing mechanisms often impose heavy computational overhead or require unrealistic trust assumptions (e.g., honest majorities of servers).
Lack of Integration: Prior works have not fully explored compatibility with existing decentralized infrastructures like Tor or federated social networks, which could provide natural cover traffic and server resources.

Methodology

Pepper addresses these limitations through a novel, integrated design built on a two-server DC-net architecture. The system operates in two sequential subprotocols: Registration and Messaging, utilizing advanced cryptographic primitives to ensure sender anonymity and efficient throughput.

1. Self-Contained Anonymous Registration

Unlike prior systems, Pepper specifies a full registration subprotocol that eliminates the need for external dialing services.

Mechanism: Broadcasters use Verifiable Distributed Point Functions (VDPFs) to anonymously acquire message channels.
Process: A broadcaster constructs a registration message containing their public key, a starting channel ID, and requested bandwidth. This is secret-shared between two aggregation servers.
Verification: The servers perform a joint audit using VDPF verification tokens to ensure the shares are well-formed and correspond to a valid request without learning the target channels or the broadcaster's identity. Successful registrations bind the public key to specific channel ranges on a public bulletin.

2. Batch Messaging with Efficient Auditing

Pepper introduces support for batch messaging, allowing a single broadcaster to send up to $t$ messages to distinct channels in a single epoch.

Mechanism: The system leverages Distributed Multi-Point Functions (DMPFs) and their verifiable variants (VDMPFs). This generalizes DPFs from a single non-zero point to multiple non-zero points, allowing a single key pair to encode multiple messages.
Access Control: To enforce that only the channel owner can write, Pepper integrates Schnorr Proofs over Secret Shares (SPoSS). This allows servers to verify that a client possesses the private key corresponding to a registered channel without reconstructing the message.
Cover Traffic: The system introduces "Phantom Channels"—special channels with universally known private keys (e.g., $g^1, g^2$ )—allowing cover-traffic clients to generate valid dummy writes without needing registered identities.
Audit Efficiency: Crucially, Pepper's auditing mechanism verifies an entire batch of $t$ messages in a single operation. It exchanges only one pair of audit tokens regardless of the batch size, amortizing the verification overhead significantly compared to systems that require $t$ separate verifications.

3. System Architecture and Compatibility

Pepper is designed for practical deployment alongside existing decentralized networks:

Aggregation Servers: The system uses cohorts of two servers. These can be co-deployed as Tor relays or Mastodon instances.
Directory Service: A directory service maintains a registry of active server pairs, allowing clients to select cohorts dynamically.
Fault Tolerance: The system assumes an "any-trust" model (at least one honest server per cohort) and supports horizontal scalability by adding more server pairs.

Key Contributions

Integrated Anonymous Registration: The design of a full, self-contained registration subprotocol using VDPFs, removing the dependency on external dialing systems required by Spectrum and Express.
High-Throughput Batch Messaging: The construction of a lightweight access control mechanism combining VDMPFs with SPoSS. This enables efficient verification of batch writes (up to $t$ messages) with a single proof exchange, significantly improving effective throughput.
Implementation and Evaluation: An open-source implementation (~8,000 lines of Go, ~2,900 lines of C/C++) that demonstrates millisecond-level registration audits and scalable performance up to thousands of channels.
Practical Deployment Path: A demonstrated compatibility with existing infrastructures, showing how Pepper can leverage Tor for cover traffic and server resources, and integrate with federated social networks.

Results

The authors evaluated Pepper against state-of-the-art baselines (Spectrum, Express, and PACLs) across communication cost, auditing time, throughput, and latency.

Auditing Latency: Registration audits complete in milliseconds even for 16,000 channels. For messaging, Pepper's batch auditing scales efficiently, outperforming Spectrum by 10.8×–12.4× and PACLs by 2.3×–3.6× in per-request auditing time for 5KB messages with batch size $t=8$ .
Effective Throughput: While single-request throughput is lower than Spectrum (due to higher per-request computation for batching), the effective messaging rate is significantly higher. For $t=8$ , Pepper delivers 1.2× to 5.0× higher rates than PACLs and 13.6× to 20× higher rates than Spectrum across various channel counts.
End-to-End Latency: In file transmission tests (100KB to 100MB), Pepper consistently achieved the lowest latency. For a 100MB file, Pepper took ~10.2 hours, compared to ~16.7 hours for PACLs and an estimated ~274 hours for Spectrum.
Communication Overhead: Pepper maintains competitive communication costs. While VDMPF keys are slightly larger than standard DPFs to support batching, the reduction in server-server audit token exchanges (one per batch vs. $t$ ) offsets the cost for large batches.

Significance

The paper claims that Pepper represents a significant step toward the practical deployment of high-bandwidth anonymous broadcast. By eliminating external dependencies, supporting efficient batch messaging, and integrating seamlessly with existing decentralized networks like Tor and Mastodon, Pepper addresses the throughput and scalability bottlenecks that have hindered previous DC-net systems. The system demonstrates that cryptographic sender anonymity can be achieved with performance metrics suitable for real-world applications such as anonymous file sharing and media dissemination, without requiring unrealistic trust assumptions or sacrificing anonymity guarantees.