💻 computer science

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

Pepperは、2サーバーDC-netアーキテクチャを活用し、新たな暗号プリミティブを用いることで、グローバルな送信者匿名性を実現し、バッチメッセージングをサポートし、外部のダイヤリングサービスを必要とすることなく既存の最先端の代替案よりも大幅に高いスループットを実現する、高帯域幅でスケーラブルな匿名ブロードキャストプロトコルである。

原著者： Chenghao Li, Haoyuan Wang, Xianghang Mi

公開日 2026-06-04

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Chenghao Li, Haoyuan Wang, Xianghang Mi

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

想像してみてください。あなたは、誰もが叫んでいる騒がしく混雑した部屋にいます。あなたは部屋全体に秘密のメッセージをささやきたいと考えていますが、誰にも自分が誰であるかを知られたくありません。デジタル世界では、これを「アノニマス・ブロードキャスティング（匿名放送）」と呼びます。

この論文は、強力なグローバル・スパイがすべてのネットワークケーブルを監視していたとしても、人々が大量のデータ（ファイルやビデオなど）を匿名で送信できるように設計された新しいシステム、「Pepper」を紹介しています。

Pepperの仕組みを、簡単な比喩を用いて説明します。

1. 旧来のシステムの課題

以前のシステムは、**「一車線の橋」**のようなものでした。

一度に一台の車： 一度に送れるのは、ごく小さなメッセージだけでした。もし本一冊を送りたいと思ったら、それを何百万もの小さな破片に分解し、一つずつ橋を渡らなければなりませんでした。これは非常に時間がかかる作業でした。
「ダイヤリング」の問題： 橋に乗るためには、別途、謎めいた「ダイヤリング・サービス」からチケットをもらう必要がありました。旧来のシステムは、どうやってそのチケットを手に入れるのかを説明しておらず、単に「チケットを持っていること」を前提としていました。
交通渋滞： 全員が順番待ちをしなければならなかったため、システムは低速で、大量のデータ転送を処理することができませんでした。

2. Pepperによる解決策：多車線の高速道路

Pepperは、大量の車の隊列（メッセージ）を一度に送ることができる、**「巨大な多車線の高速道路」**のようなものです。

革新点 #1：自己完結型のチケット売り場（登録）

かつては、チケットをもらうために別の説明不足な事務所へ行かなければなりませんでした。

Pepperのアプローチ： 高速道路には、チケット売り場が組み込まれています。あなたは歩いて近づき、匿名でリクエストを提出します。システムは、あなたの名前を聞いたり顔を見たりすることなく、チケットが有効かどうかをチェックします。
魔法の仕組み： これは「検証可能な分散ポイント関数（Verifiable Distributed Distributed Point Function）」と呼ばれる暗号技術を用いたものです。これは**「魔法の封筒」**のようなものだと考えてください。あなたはリクエストを封筒の中に入れます。二人のガードマン（サーバー）が一緒にその封筒を開けます。彼らは、封筒が本物であり、正しく封印されていることを検証できますが、中に「何が入っているか」や「誰がそれを入れたか」を見ることはできません。もし偽物であれば、彼らはそれを捨てます。本物であれば、スタンプを押してあなたを通します。

革新点 #2：隊列システム（バッチ・メッセージング）

これがPepperの最大の強みです。

旧来の方法： もし8つのメッセージを送りたい場合、8回の別々の往復を行う必要がありました。それぞれの往復ごとにセキュリティチェック（監査）が必要でした。
Pepperの方法： 8つのメッセージを一つのトラックに積み込みます。そして、一度だけ橋を渡ります。ガードマンは、そのトラックを一度だけチェックします。
結果： セキュリティ手数料を8回支払う代わりに、1回支払うだけで済みます。これにより、大量のデータを送信する場合、既存の最高のシステムと比較して13倍から20倍高速になります。

革新点 #3：「ゴースト」ドライバー（カバートラフィック）

誰が本当のメッセージを送っているかを隠すために、Pepperは「カバートラフィック（隠蔽通信）」、つまり、紛れ込むためにダミーのメッセージを送る人々を必要とします。

問題点： 旧来のシステムでは、特別な鍵を持っている人だけがメッセージを送ることができました。鍵を持っていなければ、隠蔽に貢献することはできませんでした。
Pepperの解決策： Pepperは**「ファントム・チャネル（幽霊のレーン）」**を作成します。これらは、実際にはデータ通信に使用されない、高速道路上の偽のレーンのようなものです。誰でもこのレーンにダミーの車を走らせることができます。
メリット： これにより、一般のユーザー（例えば、単にソーシャルネットワークを閲覧している人々）が、特別な鍵を必要とせずに、自然にカバートラフィックを生成できるようになります。本当の送信者は、これら「ゴースト・ドライバー」の群衆の中に隠れることができます。

3. あなたの安全をどう守るのか

二人のガードマン： Pepperは、協力して働く二つのサーバー（ガードマン）を使用します。どちらか一方のガードマンが正直である限り、あなたのアイデンティティは安全に保たれます。たとえもう一人のガードマンがスパイであったとしても、メッセージを誰が送ったかを突き止めることはできません。
「グローバル・スパイ」も突破できない： このシステムは、現在では解くことが不可能な数学的問題（巨大な数の因数分解など）に基づいています。たとえグローバル・スパイがすべてのデータパケットを監視していたとしても、メッセージの送信者を特定できる確率は、コイン投げの結果と同じレベル（偶然）に過ぎません。

4. 実世界のパフォーマンス

著者らは動作するバージョンのPepperを構築し、テストを行いました。

スピード： 数ミリ秒で新しいユーザーを登録できます。
スケール： 数千のチャネルがあっても効率的に動作します。
比較： 大容量ファイルを送信する際、Pepperは現在の最先端システム（SpectrumやExpressなど）よりも1.2倍から20倍高速です。
互換性： Pepperは、Tor（オニオン・ルーティング・ネットワーク）やMastodon（分散型ソーシャルネットワーク）のような既存のネットワークと併用できるように設計されています。お気に入りのソーシャルメディア・アプリに、追跡される恐怖を感じることなく機密情報を投稿できるようにする、Pepperを利用した「匿名モード」が組み込まれている様子を想像してみてください。

まとめ

Pepperは、高速で匿名のメールシステムです。「誰が自分であるかを知られることなく、どうすれば巨大なファイルを送れるのか？」という問題に対し、メッセージの全隊列を一度の移動で送り、別途の事務所を必要としない組み込み型のチケットシステムを用い、さらに「ゴースト・ドライバー」の群衆の中に本当のメッセージを紛れ込ませて足跡を隠すことで解決しています。それは、以前のどのシステムよりも高速で、効率的であり、導入が容易です。

技術要約: Pepper

問題提起

匿名ブロードキャスト・プロトコル（ABP）は、内部告発や検閲耐性のある出版といったプライバシーに敏感なアプリケーションにとって不可欠であるが、実用的な高帯域幅での展開には依然として根強い課題が存在する。Torのような従来のシステムは低遅延のルーティングを提供するが、グローバルなトラフィック相関攻撃に対して脆弱なままである。Dining Cryptographersネットワーク（DC-net）やミックスネットに基づく暗号学的に保証された代替案は、より強力な匿名性を提供する一方で、以下の決定的な限界を抱えている：

外部依存性: SpectrumやExpressといった最先端のシステムは、チャネル割り当てのために、未指定の外部「ダイヤリング」または登録サービスに依存しており、エンドツーエンドのプロトコル仕様に空白を残している。
スループットのボトルネック: 既存のDC-netのバリアントは、通常、ブロードキャスターを1エポックあたり1メッセージに制限しており、大規模なデータ転送（例：1GBのファイルをブロードキャストするのに13時間以上かかる）には不向きである。
複雑な監査: 強固なアクセス制御と監査メカニズムは、重い計算オーバーヘッドを課すか、あるいは非現実的な信頼仮定（例：サーバーの誠実な過半数）を必要とする。
統合の欠如: 先行研究は、Torやフェデレーション型ソーシャルネットワークのような既存の分散型インフラストラクチャとの互換性を十分に探求しておらず、これらは自然なカバートラフィックやサーバーリソースを提供できる可能性がある。

メソドロジー

Pepperは、2サーバー構成のDC-netアーキテクチャに基づいた、斬新で統合された設計を通じてこれらの限界に対処する。本システムは、**登録（Registration）とメッセージング（Messaging）**という2つの連続するサブプロトコルで動作し、高度な暗号プリミティブを利用して送信者の匿名性と効率的なスループットを確保する。

1. 自己完結型の匿名登録

先行システムとは異なり、Pepperは外部のダイヤリングサービスを不要とする完全な登録サブプロトコルを規定している。

メカニズム: ブロードキャスターは、**検証可能分散点関数（VDPF）**を使用して、匿名でメッセージチャネルを取得する。
プロセス: ブロードキャスターは、公開鍵、開始チャネルID、および要求帯域幅を含む登録メッセージを構築する。これは2つの集約サーバー間で秘密分散される。
検証: サーバーは、VDPF検証トークンを用いて共同監査を行い、ターゲットとなるチャネルやブロードキャスターの身元を学習することなく、シェアが適切に構成されており、有効なリクエストに対応していることを確認する。登録が成功すると、公開鍵がパブリックな掲示板上の特定のチャネル範囲に紐付けられる。

2. 効率的な監査を伴うバッチ・メッセージング

Pepperは、単一のブロードキャスターが1エポック内に最大 $t$ 個の異なるチャネルへメッセージを送信できる、バッチ・メッセージングのサポートを導入している。

メカニズム: 本システムは、分散マルチポイント関数（DMPF）とその検証可能バリアントであるVDMPFを活用する。これにより、単一の非ゼロ点から複数の非ゼロ点へとDPFを一般化し、単一の鍵ペアで複数のメッセージをエンコードすることが可能になる。
アクセス制御: チャネル所有者のみが書き込みを行えるようにするため、Pepperは**秘密分散上のシュノール証明（SPoSS）**を統合している。これにより、サーバーはメッセージを再構成することなく、クライアントが登録されたチャネルに対応する秘密鍵を保持していることを検証できる。
カバートラフィック: システムは「ファントム・チャネル（Phantom Channels）」を導入している。これは、普遍的に既知の秘密鍵（例： $g^1, g^2$ ）を持つ特別なチャネルであり、カバートラフィック・クライアントが登録された身元を必要とせずに、有効なダミー書き込みを生成することを可能にする。
監査の効率性: 決定的なことに、Pepperの監査メカニズムは、 $t$ 個のメッセージ全体のバッチを単一の操作で検証する。これは、 $t$ 個の個別の検証を必要とするシステムと比較して、バッチサイズに関わらず1組の監査トークンのみを交換するため、検証オーバーヘッドを大幅に軽減する。

3. システムアーキテクチャと互換性

Pepperは、既存の分散型ネットワークと共に実用的に展開できるように設計されている。

集約サーバー: システムは、サーバーのコホート（集団）を2つ使用する。これらはTorリレーやMastodonインスタンスとして共同展開することができる。
ディレクトリサービス: ディレクトリサービスは、アクティブなサーバーペアのレジストリを維持し、クライアントが動的にコホートを選択できるようにする。
フォールトトレランス: システムは「エニー・トラスト（any-trust）」モデル（各コホートに少なくとも1つの誠実なサーバーが存在すること）を想定しており、サーバーペアを追加することで水平方向のスケーラビリティをサポートする。

主な貢献

統合された匿名登録: VDPFを用いた完全で自己完結型の登録サブプロトコルの設計により、SpectrumやExpressで必要とされる外部ダイヤリングシステムへの依存を排除した。
高スループットのバッチ・メッセージング: VDMPFとSPoSSを組み合わせた軽量なアクセス制御メカニズムの構築。これにより、バッチ書き込み（最大 $t$ メッセージ）を単一の証明交換で効率的に検証することが可能となり、実効スループットを大幅に向上させた。
実装と評価: 約8,000行のGoおよび約2,900行のC/C++によるオープンソースの実装により、ミリ秒単位の登録監査と、数千のチャネルに及ぶスケーラブルなパフォーマンスを実証した。
実用的な展開パス: Torを利用したカバートラフィックやサーバーリソースの活用、およびフェデレーション型ソーシャルネットワークとの統合の可能性を示すことで、既存のインフラストラクチャとの互換性を実証した。

結果

著者らは、通信コスト、監査時間、スループット、およびレイテンシの観点から、Pepperを最先端のベースライン（Spectrum、Express、およびPACLs）と比較評価した。

監査レイテンシ: 登録監査は、16,000個のチャネルに対してもミリ秒単位で完了する。メッセージングにおいて、Pepperのバッチ監査は効率的にスケールし、バッチサイズ $t=8$ 、メッセージサイズ5KBの場合、1リクエストあたりの監査時間においてSpectrumに対して10.8倍〜12.4倍、PACLsに対して2.3倍〜3.6倍優れた性能を示した。
実効スループット: 単一リクエストのスループットは（バッチ処理のための高い1リクエストあたりの計算量により）Spectrumよりも低いが、実効メッセージングレートは大幅に高い。 $t=8$ の場合、Pepperは様々なチャネル数において、PACLsよりも1.2倍〜5.0倍、Spectrumよりも13.6倍〜20倍高いレートを実現した。
エンドツーエンド・レイテンシ: ファイル転送テスト（100KBから100MB）において、Pepperは一貫して最も低いレイテンシを達成した。100MBのファイル転送において、PACLsが約16.7時間、Spectrumが推定約274時間かかったのに対し、Pepperは約10.2時間であった。
通信オーバーヘッド: Pepperは競争力のある通信コストを維持している。バッチ処理をサポートするためにVDMPFキーは標準的なDPFよりもわずかに大きいが、サーバー間での監査トークンの交換回数の削減（ $t$ 回ではなく1回）が、大きなバッチにおけるコストを相殺している。

意義

本論文は、Pepperが、高帯域幅の匿名ブロードキャストの実用的な展開に向けた重要な一歩であることを主張している。外部依存性を排除し、効率的なバッチ・メッセージングをサポートし、TorやMastodonのような既存の分散型ネットワークとシームレスに統合することで、Pepperは従来のDC-netシステムを阻んできたスループットとスケーラビリティのボトルネックに対処している。本システムは、非現実的な信頼仮定を強いることなく、匿名性の保証を犠牲にすることなく、匿名ファイル共有やメディア配信といった実世界のアプリケーションに適したパフォーマンス指標を伴って、暗号学的な送信者匿名性が達成可能であることを示している。