P2P プライバシーの本当の境界：IP の露出からエンドツーエンドのトラフィック相関まで

1 回のダウンロードから考える：他者には何が見えるのか？

BitTorrent は 1 つのファイルを個別に取得できるピースに分割し、参加者同士がデータを提供し合えるようにします。同じ torrent に参加するノードの集まりを swarm、実際に接続してデータを交換するノードを peer と呼びます。クライアントはまず相手の連絡先を見つけ、その後に接続を確立する必要があります。これが転送負荷を効率よく分散できる基盤であり、ネットワークエンドポイントが観察可能な情報になる理由でもあります。^[1]

まず、どこから観察するのかを正しく捉えましょう。あなたとピースを交換する peer に見えるのは、接続相手の IP と port です。アクセス回線の ISP に見えるのは、その回線から送信されるパケットです。VPN 運営者は、暗号化トンネルの終端に位置します。それぞれの位置で得られる情報は異なり、ある位置から見えない情報は、別の位置へ移っただけかもしれません。

内容の機密性、IP の分離、活動のリンク不能性

暗号化が守るのは、内容を読めるかどうかです。VPN は、swarm 内で見える送信元を VPN の出口へ変えられます。さらに一歩進んだ 活動のリンク不能性 では、2 つの活動を観察した人が、それらが同じ送信元によるものか判断できるかを問います。本名が分からなくても、複数の活動を同じグループとしてまとめられる可能性があります。

また、peer 自体がデータの受信者です。ピースを相手へ送る以上、その接続の暗号化によって相手からもピースを隠せるとは期待できません。本当に考えるべきなのは、どの中間観察者から、どのエンドポイント情報を守るのか、そしてそれらを他のデータと結び付けられるかです。こうした問いを分けてこそ、VPN、プロトコル暗号化、匿名ネットワークの用途が明確になります。

仲間を見つけると同時に、連絡先も公開される

1 回のダウンロードには、通常 3 つの役割が関わります。インデックスサイト は torrent ファイルや magnet link を見つける場を提供し、発見機構 はクライアントが peers を取得するのを助け、データ接続 が実際にファイルのピースを運びます。インデックス、tracker、peer を同じ組織が管理する必要はありません。そのため、「誰があるサイトを訪れたか」と「誰がある swarm に参加したか」は、もともと異なる観察なのです。^[1][2]

Infohash が参加者を同じ torrent へ導く

infohash は、torrent の info dictionary をエンコードしたもののハッシュで、torrent の記述を識別するために使われます。v1 は SHA-1、v2 は SHA-256 を使用し、v2 の一部のプロトコルフィールドでは切り詰めた 20 bytes を使用します。これは利用者アカウントではなく、ファイル全体を 1 回ハッシュして得る汎用的な名前でもありません。記述自体が異なる場合があるため、同じ内容が異なる torrent に対応することもあります。^[1]

エンドポイント情報には、もう 1 つ見落としやすい点があります。通知された待ち受け port、パケットの実際の送信元 port、NAT が外部に割り当てた port は、同じ番号とは限りません。意味を区別せずに IP:port だけを記録すると、後で異なる段階のデータを誤って結び付ける可能性があります。^[2]

公開する情報を減らすことと、接続経路を制限すること

DHT や PEX を無効にすれば、それに対応する発見経路は減ります。しかし peer と直接接続している限り、相手にはその接続のエンドポイントが見えます。Private torrent の private 設定は、発見先を指定された tracker に限定し、主にそのアクセス制御を維持します。swarm 内の通信には、引き続きエンドポイント情報が必要です。ローカルネットワークの Local Service Discovery は、multicast で infohash と待ち受け port を通知することがあり、別の局所的な可視範囲を持ちます。^[5]

qBittorrent の Anonymous Mode は、主に user-agent、バージョン、追加の IP フィールドなど、自己申告する情報を減らします。実際の動作は libtorrent のバージョンや torrent の種類によって異なります。公式ページにある、旧バージョンで DHT／LSD／UPnP を無効にする動作を、すべてのバージョンに当てはめることはできません。実際のパケット送信に使うネットワークエンドポイントは、引き続き socket、ルーティング、分離の構成によって決まります。^[7]

VPN は信頼境界を移動させる

VPN 経路では、端末がまず内側の IP パケットを暗号化トンネルに包みます。VPN サーバーがその包みを解き、内側のトラフィックを宛先へ送ります。peer から見ると、応答データの宛先は通常 VPN の出口です。アクセス回線の ISP から直接見える接続相手は、VPN サーバーです。^[6]

この分離には大きな価値がありますが、VPN 運営者は新たな信頼の位置に立ちます。パケットの転送には、その時点の状態を維持する必要があります。同じ管理者が入口と出口を制御しているなら、構造上は両側を観察する能力があります。この点は、次の別の問いと分ける必要があります。その対応関係を、後から検索できる記録として保存しているのか？

No-log は履歴データの問題、RAM-only は残留先の問題

Mullvad の公開ポリシーを例にすると、利用者の活動記録を保存しないと表明する一方、アカウント、WireGuard 設定、支払い、その他必要なデータの取り扱いも説明しています。ランダムな番号によるアカウントは、登録時に求める識別情報を減らします。ただし支払方法によっては、「支払人とアカウント」の関係が生じることがあります。それでも、その関係だけでは「このアカウントが、ある時刻に特定の出口トラフィックを発生させた」という対応まで埋めるには不十分です。^[8]

一方、RAM-only サーバーが焦点を当てるのは、永続ディスクへの残留です。再起動後に通常のディスク上へ稼働状態を残さないことで、ある種の事後フォレンジックのリスクを下げる助けになります。稼働中のメモリ、ネットワークの観察、他のシステムが保存したデータは、それぞれ別の問題です。Mullvad は 2023 年に RAM-only への移行完了を発表しました。ここで引用しているのは事業者の公開説明であり、本記事が運用環境を独立に監査した結果ではありません。^[8]

マルチホップで位置を分けても、誰が管理するかは別途問う必要がある

マルチホップは、入口ノードを利用者側、出口ノードを宛先側に配置します。一方しか観察できない人にとっては、両側を結び付けにくくなる可能性があります。しかし同じ観察者が両端のトラフィックを取得できるなら、中継数を増やすだけでは時刻や流量の相関が残ることがあります。同じ事業者の複数サーバーも、自動的に互いに独立した管理者になるわけではありません。^[9][11]

VPN は、アプリケーション層のログイン、アカウント、端末情報も取り除きません。既知のアカウントを使って活動していれば、サイトはネットワークのリズムから身元を推測し直す必要がありません。この意味で、ネットワークの匿名性とアプリケーション上の身元は、互いに影響し合うものの、それぞれ理解する必要がある別の層です。

トンネルが切れた後、パケットはどこへ向かうのか？

「VPN に接続している」は、その瞬間の状態を表します。自宅の IP が swarm に現れる可能性を理解するには、トンネルが機能しなくなった後の動作も見る必要があります。アプリケーションは送信を止めて待つのか、それとも別の利用可能な経路で送り続けるのか？Fail-closed とは、保護された経路が機能しなくなったときに、保護対象の通信も停止し、安全な経路が復旧するまで再開しないことです。

ルーティングテーブルは次のホップを選び、インターフェースへのバインドはアプリケーションが使えるネットワークインターフェースを制限し、ファイアウォールは誤った出口へ向かうパケットを拒否できます。Linux の network namespace はさらに一歩進めて、プロセスに独立したネットワーク環境を与え、特定のインターフェースと経路だけが見えるようにします。これらはそれぞれ異なる制御点を扱う仕組みであり、実際の効果はどのトラフィックを対象にしているかによって決まります。^[6][10]

デフォルトルートを変えるだけでは、なぜ隙間が残り得るのか？

システムには、より具体的な経路、ローカルネットワーク向けの例外、インターフェース再作成後の新たな選択肢が存在し得るからです。Bypassing Tunnels と TunnelVision の研究では、それぞれ経路の例外と DHCP のルーティング情報によって VPN が迂回される状況が示されました。これらは、経路の優先順位とトラフィックの分離の違いを示しています。各製品の現在の状態は、バージョンと修正状況に応じて判断する必要があります。^[12]

インターフェースへのバインドにも細かな違いがあります。ローカル IP へのバインドと、socket を特定のネットワークデバイスに制限することは、すべてのシステムで完全に同じ効果を持つわけではありません。TCP peer、UDP tracker、DHT は、それぞれ異なる socket を使うこともあります。ある種類のトラフィックだけ動作が異なる場合は、アプリケーションの接続アイコンだけを見るのではなく、実際にどの出口を制御しているのかを確認するべきです。^[10]

IPv6、DNS、管理インターフェースを分けて考えるのはなぜか？

IPv4 が VPN に送られていても、IPv6 では peer に直接接続できるなら、相手には別のアドレスファミリーからあなたのエンドポイントが見える可能性があります。DNS クエリをトンネル外で行うと、どのサービスのドメインを問い合わせたかが漏れることがあります。ただし、通常のドメイン問い合わせ自体に torrent の infohash が自動的に含まれるわけではありません。両者が漏らす情報は異なり、同じ「IP 漏えい」というラベルだけで片付けることはできません。

Web UI、検索拡張、ホスト上の DNS プロキシは、別のプロセスが処理している場合もあります。ダウンロードエンジンを制限しても、それらのプロセスの経路まで自動的に制限されるわけではありません。Port forwarding が扱うのは、外部の peer から接続を開始できるかどうかです。VPN の出口で開くのと、自宅のルーターで開くのとでは、関わるネットワーク上の位置が異なります。これらは構成要素と接続経路から導かれる違いであり、すべてのクライアントに同じ問題があるという主張ではありません。^[10]

Namespace による分離は、ホストのカーネルとネットワークを変更できる権限が引き続き信頼できることを前提とします。アプリケーションが意図せず別の出口を使う機会は減らせますが、高い権限で支配されたホストを完全に保護することはできません。ここまでで扱ったのは、あくまで「パケットがどこを通るか」です。次の問いは、正しい経路を通った後にも、パケットがどんな形を残すかです。

暗号化で内容を隠しても、通信にはリズムが残る

要求を続けて送ると、遠隔側がデータを返し始めます。受信側が忙しければ一時停止し、バッファに空きができると次の波が来ます。暗号化はパケット内のバイト列を変えますが、アプリケーションとネットワークが一緒に生み出すこうした時間的な変化は、外側にも現れる可能性があります。

エンドツーエンドのトラフィック相関 が解こうとするのは、2 つの観察点で取得したトラフィックが同じ通信に属するか、という問題です。攻撃者には、両側の対応するデータを見られる能力が必要です。ある VPN 出口の IP を知っているだけでは、利用者側のトラフィックを取得したことにはなりません。Tor 公式も、「通信の両端を同時に観察すること」を、防御しない脅威モデルとして明示しています。^[11]

最も単純な方法：時間窓ごとに合計し、少しのずれを許容する

ある方向のパケットを固定の時間窓に分け、各窓で観察したバイト数を合計します。窓幅が Δ 秒なら、xₖ と yₖ は、両側の k 番目の時間窓の流量です。転送遅延を許容するために、2 本目の系列を数区間だけ前後にずらし、その変化を比較できます。

この単純なモデルは、信号がどこから生まれるかを説明しているだけです。研究では、学習された表現、長さの異なる窓、複数の特徴も使われます。より複雑なモデルでも観察データは必要であり、データ収集方法、実際のネットワーク変動、許容する偽陽性率の影響を受けます。2026 年に著者が公開した ESPRESSO の原稿は、人工データと実際の Tor トラフィックの間の隔たりを特に研究しています。^[13]

1 本の VPN トンネルには、多くの接続が入っていることが多い

上の図では、意図的に近い計数レイヤーから始めています。実際のネットワークでは、物理 NIC に見えるのは VPN の外側のパケットで、出口に見えるのは特定の peer 接続かもしれません。入口のトンネルには、他の peers、DNS、ウェブ閲覧、バックグラウンド同期も同時に入っています。トンネル全体の総量をそのまま単一の peer flow と見なすと、比較対象がすでに変わってしまいます。

カプセル化のヘッダー、再送、ACK、MTU、パケットの分割、輻輳、パディングも、数や長さを変えます。妥当な直感は、データは転送されて初めて届き、低遅延の転送では因果関係に由来するリズムがある程度残りやすい、ということです。そこからさらに、入口の各パケットに対して出口に同じ長さ・同じ間隔の複製が 1 つずつあると仮定することはできません。^[6][13]

この 2 つの問題では似た特徴を使えますが、評価結果をそのまま相互に置き換えることはできません。受動的な攻撃者は既存のトラフィックを観察するだけです。遅延、パケット損失、速度に影響を与えられる能動的な攻撃者は、反対側に識別可能な反応を生じさせることもあります。ある観察モデルを防げても、別のモデルまで自動的にカバーするわけではありません。^[14][17]

似て見えることと「同じ人物」であることには、どれほど隔たりがあるのか？

相関係数 r = 0.91 は、この比較方法では 2 組の数値がよく似ていることを示します。「91% の確率で同じ通信である」という校正済みの確率を直接示すものではなく、端末、アカウント、自然人の間の隔たりを埋めるものでもありません。多数の候補、多数の時間のずれ、多数の窓を同時に探索して最高点を選べば、偶然似る機会も増えます。

同様に、tracker の一覧と実際のデータ交換は、異なる強さの観察を提供します。ネットワーク上の出来事を操作した人の身元へ結び付けるには、通常、他の情報源の証拠が必要であり、共有 IP、時計の誤差、記録の欠落にも対処しなければなりません。IPv4 を共有している場合は、特に送信元 port、正確な時刻、関連するトランスポート情報が必要です。契約者へ対応付けられても、誰が操作したかが自動的に確定するわけではありません。^[21][23]

偽陽性率が非常に低くても、誤った候補が多数生じ得る

ある分析に 1,000,001 個の候補があり、正しい対応がちょうど 1 つだけ含まれるとします。モデルが正しい対応を見つける確率は 90%、誤った各候補を誤検出する確率は 10 万分の 1 にすぎません。この偽陽性率は低く聞こえますが、100 万個の誤った候補に対しては、平均で 10 個の偽陽性が生じます。

正しい対応がそもそも候補群に入っていないのに、システムに「最も似たもの」を必ず選ばせると、すべて誤った候補の中の最高点を答えと誤認する可能性があります。研究でクローズドワールドとオープンワールドを区別するのも、このためです。前者は答えが既知の範囲にあると仮定することが多く、後者は「この中にはない」を認める必要があります。^[13]

証拠が増えたなら、情報も本当に増えていなければならない

同じ tracker 記録から 3 つのレポートを出力しても、観察としては 1 件にすぎないかもしれません。それらを互いに独立した 3 つの裏付けとして掛け合わせると、結論の確かさを過大評価します。時系列もそろえる必要があります。タイムゾーン、時計のずれ、NAT マッピングの変化、ログの時刻がイベント発生時刻なのか書き込み時刻なのかによって、対応付けの結果が変わる可能性があります。

長期間の観察は、候補集合を徐々に狭める可能性があります。たとえば複数の活動で送信元がオンラインである必要があれば、すべての観察時間帯に当てはまる人は少なくなるかもしれません。しかし、オフライン判定の誤り、観測漏れ、バックグラウンドプログラム、異なる端末は、この推論の前提を崩します。I2P の脅威モデルでも、この種の交差攻撃を論じています。人数が減る曲線を描くだけで、最後には必ず 1 人の操作者が残ると仮定してはいけません。^[19]

パディングはパケットの外観を変え、DAITA は接続ごとに戦略を変える

パケットのサイズや間隔が手がかりを残すなら、パケット同士をもっと似せる、というのは自然な発想です。パディング は短いパケットを指定サイズまで埋めることができます。一方、dummy traffic は、同量の実データがないときに、相手が識別して破棄できるダミーデータを加えます。前者はサイズを変え、後者は一部の空白やバーストの形も変えられます。

DAITA の焦点は形であり、暗号アルゴリズムの変更ではない

Mullvad が公開した DAITA の設計は、固定パケットサイズ、バックグラウンドのダミートラフィック、パターンの撹乱を組み合わせています。2025 年に発表された DAITA v2 は、VPN 接続の確立時に動的な設定を割り当て、接続ごとに異なる dummy 挿入戦略を使います。再接続時にも設定が変わります。作用する単位は VPN 接続であり、BitTorrent の各 peer flow が独立した戦略を持つとそのまま見なすことはできません。^[15]

v2 の発表にある「dummy パケットの使用量を約半減」は、その種の追加パケットの調整を指します。すべてのワークロードで総トラフィックのオーバーヘッドが一律に半減するという意味ではありません。同様に、固定パケットサイズが固定送信レートを直接約束するわけでもありません。効果は、元のトラフィック、パディング戦略、ボトルネックの帯域、攻撃者が観察する位置によって変わります。

防御が変われば、観察者も学習し直せる

Ephemeral Network-Layer Fingerprinting Defenses（PoPETs 2026）は、接続ごとに異なる防御を使う戦略を研究し、WireGuard との統合と Mullvad での導入経験を報告しています。主な評価対象は circuit、website、video fingerprinting です。これらの結果を、BitTorrent の両端相関が成功または失敗する割合へ直接換算することはできません。^[16]

同じ論文は、必要な反証的結果も示しています。指定されたクローズドワールドのシミュレーションでは、攻撃者により多くの訓練とデータ拡張の機会があると、評価した複数の padding-only 防御の効果が大幅に弱まりました。blocking／遅延を加える防御には効果が残りましたが、やはりモデルとコストの制約を受けます。設定をランダムにすれば固定テンプレートを当てはめにくくなりますが、攻撃者が設定の分布全体を学習することは防げません。

DeTorrent：敵対的学習でパディング戦略を探索する

DeTorrent（PoPETs 2024）は、防御を生成するモデルとトラフィックを識別するモデルを競わせ、dummy の挿入戦略を探索します。研究対象は Tor などの匿名通信環境であり、ウェブサイト指紋識別とトラフィック相関を別々に評価しています。名前に Torrent が入っているからといって、あらゆる BitTorrent 転送への適用が証明されたわけではありません。論文では、指定の FC 設定において、FPR が 10⁻⁵ のとき TPR を約 0.12 まで下げられると報告しています。これはその実験の動作点であり、利用者のリスクが 12% だけになるという意味ではありません。^[14]

Padding-only は、戦略として実パケットを意図的に保持して待たせないことを意味します。それでも追加データは帯域、CPU、キューを消費します。回線が飽和に近い場合、「スケジューリングによる遅延がない」ことと、実際の遅延が増えることは両立します。アルゴリズムの動作とネットワーク全体での結果を分けてこそ、こうした研究の価値と限界が理解できます。

リズムを平らにするには、帯域か待ち時間を支払う必要がある

固定レートは、分かりやすい思考実験です。アプリケーションにデータがあってもなくても、接続は毎秒一定量を送ります。実データが足りないときは dummy で埋め、急に割り当て量を超えたときはキューに入れます。観察者から見える短期的なレートは安定しますが、コストは別の見える場所へ移ります。

この 5 秒間に送るのは合計 10 MiB で、そのうち実データは 7 MiB だけです。追加の 3 MiB は、外観を安定させるためのコストです。2 秒目のバーストは出力へすぐに全量が反映されません。そのうち 3 MiB がキューに残るためです。データは消えたのではなく、少し遅れて届くのです。

長期的な入力レートが R を上回ると、キューは増え続けます。平均入力が R を下回っていても、大きなバーストは裾の長い待ち時間を生じさせる可能性があります。メモリを制限するには、アプリケーションへ圧力を返す、追加の入力を拒否する、または戦略を変える必要があります。出力レートを一時的に引き上げると、負荷の変化が再び露出する可能性があります。

高くつくのは、むしろアイドル時間であることが多い

一方向の通信を継続して 20 Mbit/s に維持すると、1 日 24 時間で約 216 GB を送信します。計算は 20,000,000 × 86,400 ÷ 8 です。ここでは 10 進数の GB を使い、その他のカプセル化や再送は無視しています。その日に本当に送る必要があるデータが 10 GB だけなら、残りの約 206 GB はすべて、このスケジュールを維持するための容量コストです。実データに対する追加量は約 2,060% になります。これは算術上の例であり、どの製品の既定値にも対応していません。

そのため、防御の性能を見るときは、 goodput、つまり実際に届いた有用なデータ量にも注意する必要があります。回線上の毎秒の bytes が多くても、dummy が多いだけかもしれません。実データ量がゼロなら、追加量／実データ量の比率は定義できません。その場合は、割合を示すより毎秒のカバートラフィックを直接見るほうが明確です。

匿名通信で、このトレードオフに繰り返し直面するのはなぜか？

「誰が、いつ、突然データを持ったか」を隠す一般的な方法は、データがないときにも送信するか、データを一時的に保持して他のメッセージと混ぜることです。前者は帯域を、後者は時間を使います。Comprehensive Anonymity Trilemma は、こうした制約を形式モデルに取り込み、利用者間の協調も分析に含めています。その結論は、特定の匿名性の定義、観察能力、プロトコルモデルに依存します。^[18]

それでも、限定された攻撃者と現実的な予算のもとで防御を改善することは可能です。意味のある進歩とは、同じ条件のもとで、より少ない帯域や待ち時間で、利用可能な信号をより多く取り除くことです。固定レートにも境界があります。開始・終了の時刻、戦略の切り替え、スケジュールで処理しきれない過負荷、保護されていない別の経路は、引き続き情報を残す可能性があります。

マルチホップ、複数利用者による共有、本当のミキシング

中継ノードを増やすと観察位置を分散でき、多くの人が出口を共有すれば同じ外向き IP に複数の人を対応させられます。しかし、すべての入力が反対側から直ちに送り出されるなら、時間的な対応関係は依然として鮮明な場合があります。集約 は単にトラフィックをまとめることですが、ミキシング はさらに、観察者が入力と出力を 1 対 1 に結び直すことを難しくしようとします。

ミックスノードは、まずメッセージを保持し、その後、異なるメッセージの送信順序を変えることができます。暗号化によるカプセル化でも、入力と出力に直接照合できる外観が残らないようにする必要があります。そうしなければ、順序を入れ替えても、観察者は同じバイト列を直接照合できるかもしれません。実際の匿名ネットワークでは、パケット形式、経路、リプレイ、破棄、悪意のあるノードなどの条件にも対処する必要があります。^[17]

Loopix が数秒待つことを受け入れるのはなぜか？

Loopix（USENIX Security 2017）は、複数層の mix、カバートラフィック、loop messages を組み合わせた、メッセージ指向の匿名通信システムです。その Poisson mixing は、各メッセージをそれぞれランダムな時間だけ待たせ、すべてのノードが同じ同期ラウンドを一緒に待つ必要をなくします。論文は指数分布に従う独立した遅延を採用し、そのモデルのもとで、ネットワーク全体を見られる観察者と能動攻撃を分析しています。^[17]

Loopix のメッセージ全体の遅延は秒単位です。「比較的低遅延」という表現は mix-system の文脈で使われており、対話的な VPN が目指す体感とは異なります。待ち時間を許容できる通信へこの仕組みを広げることには示唆がありますが、メッセージシステムの分析を、高速で持続的かつ双方向の BitTorrent に対する既存の保証と直接見なすことはできません。

多数の利用者は、実際に区別しにくいトラフィックをもたらす必要がある

登録アカウントが 1 万あっても、ある時間窓に有効な候補が 1 万存在するとは限りません。大半がオフラインだったり、トラフィックの形を容易に見分けられたりするかもしれません。また、多数のメッセージが攻撃者自身の管理するノードから来ている可能性もあります。カバーを提供するのは、関連する時間、経路、観察条件のもとでなお区別しにくいトラフィックであり、単なる総ノード数ではありません。^[17][18]

マルチパスにも同様の条件があります。一部の経路しか見えない観察者に対しては、データを分散すると得られる情報を減らせる可能性があります。しかし同じ攻撃者が全経路を再集約できるなら、分流自体は相関を消しません。論理上 3 本の線を描くだけでなく、それらが本当に異なる観察・管理範囲を通るか確認する必要があります。

仕組みを VPN、Seedbox、Tor、I2P に当てはめる

可視性、分離、ミキシングを理解すると、異なる構成を比較できます。重要なのは、通信のどの区間を変え、新たな信頼をどこに置くかです。すべての方式を 1 つの匿名性スコアに押し込めると、もともと異なる問いに答えていることを見落とします。

Seedbox が移すのは実行場所

Seedbox 上のクライアントが swarm に直接参加し、自宅の端末はそれを管理するか、ファイルを取得するだけです。構造上、自宅のネットワークと swarm のエンドポイントを分離できますが、代わりにファイル、アプリケーションの状態、アカウントは別のホストに置かれます。これは通信経路から導かれる結論です。実際の記録と信頼条件は、サービスや自主管理の方法によって異なります。

Tor は情報を分散して、単一地点からの可視性を下げる

Tor の経路設計では、異なる中継が関係の一部ずつを把握します。しかし低遅延の転送には、照合可能なリズムが残る可能性があります。また、Tor は通常の BitTorrent クライアントを汎用的に包む仕組みではありません。Tor 公式は、クライアントからの漏えいや出口ノードの負荷などを指摘し、Tor 経由で Torrent クライアントを使うことを推奨していません。この利用上の制限と、匿名通信研究における Tor の価値は、どちらも分けて明確にする必要があります。^[11][25]

I2P は、アプリケーションが相手を見つける方法を変える

I2P アプリケーションは Destination のような暗号学的なエンドポイント識別子を使い、outbound と inbound tunnels を通じて相手へメッセージを届けます。BitTorrent over I2P の tracker と peer の表現も、このモデルに合わせる必要があります。通常の公開 swarm をそのまま別の VPN 出口につなぐわけではありません。^[19]

アプリケーションのエンドポイントが自宅の IP と直接同じではなくても、下位層の router 同士で IP がまったく見えないという意味ではありません。I2P の脅威分析は、タイミング、交差、Sybil、トラフィック分析などを扱っています。こうした観察能力と照らし合わせるほうが、「何ホップ増えたか」で匿名性を推測するより有益です。旧脅威モデルのページには適用バージョンが 0.8.1 と記されているため、ここでは脅威の分類を参照しており、現行バージョンの安全性評価として扱ってはいません。^[19]

大量のファイル転送にミキシングを取り入れるなら、ネットワークは何を変える必要があるのか？

ここまでの仕組みから、自然に 1 つの考えが生まれます。複数の人の実トラフィックを集め、接続ごとに整形戦略を変え、許容できる遅延の範囲で混ぜ、異なる経路に送り出すというものです。他の人の実データがカバーになれば、dummy がすべてを担う必要はありません。

難しいのは、アプリケーションの転送には固有の意味論があることです。TCP は信頼性のある順序付きバイトストリームを提供し、接続にはシーケンス番号、確認応答、状態もあります。1 本の peer TCP 接続を任意に 3 本の外向き接続へ切り分けて、変更していない peer がそれらを同じストリームとして扱うと仮定することはできません。^[20]

オーバーレイ内で分割し、外部に対しては元の通信を維持する

比較的分かりやすい方法は、協調する入口・出口プロキシが、まず転送を引き受けることです。2 つのプロキシの間では、各ストリームを内部メッセージへ分割し、整形、待機、マルチパス転送を行えます。出口では各ストリームの論理的な順序に沿って再構成し、元の peer との通信を維持します。

これにより途中のネットワークから見える形は変えられますが、出口は依然として元の相手へデータを送る必要があります。異なる外向き接続をさらに統合する、接続の識別情報を移す、peer のプロトコル動作を変えるといったことには、受信側や追加のプロキシの協力が必要です。矢印に「split／merge」と書くのは簡単ですが、転送の意味論を維持することこそ実際の難しさです。これらは TCP とプロキシモデルから導かれる工学的な制約です。^[20]

遅延に上限があると、何が難しくなるのか？

各メッセージが最大 50 ミリ秒しか待てないなら、低負荷時には他の送信元が到着する前に送り出さなければならないかもしれません。遅延上限は、混ぜられる時間範囲を狭めます。dummy を増やせば外観の一部を補えますが、やはり帯域を支払う必要があります。高負荷時には、バッファ、バックプレッシャー、テール遅延の問題にも直面する可能性があります。

これが、Loopix の安全性の結論をそのまま流用できない理由でもあります。指数分布の遅延には、固定された有限の上限がありません。それを打ち切ったり、deadline を加えたり、輻輳時に戦略を変えたりすると、メッセージが出ていく分布と観察可能な動作が変わります。50 ミリ秒は上記の思考実験の数値にすぎず、検証済みの安全なしきい値を表すものではありません。^[17]

機械学習で戦略を探索できても、未知の環境には向き合う必要がある

学習型コントローラーは、帯域、遅延、特定の攻撃モデルの性能の間で折り合いを探せます。しかし、「現在のこのモデルに推測を誤らせる」ことと、「今後のあらゆる観察者にも識別できなくする」ことには、なお隔たりがあります。攻撃者は再訓練し、異なる特徴を使い、より長い時間や別の経路からデータを取得するかもしれません。^[14][16]

したがって、複数ストリームを混合する研究の価値は、どの可視信号が本当に弱まるのか、そしてそのために待ち時間と転送量がどれだけ増えるのかを理解することにあります。少人数、多人数、バックグラウンドトラフィック、資源枯渇、長期観察を同じ全体像へ戻して初めて、見た目のよいトラフィックの形がどの条件で意味を持ち続けるかが分かります。

研究や報道された事件から、何が分かるのか？

公開 P2P の観察可能性には、長年の研究があります。しかし「観察できる」ことと「毎回正しく帰属を特定できる」ことは、併せて読む必要があります。成功した結果と失敗例を一緒に見ることで、匿名化ツールを過大評価する一方で、監視能力も過大評価してしまうことを避けられます。

1 台のコンピューターで大量の記録を集められるが、エンドポイントを誤解することもある

2010 年に発表された Spying the World from your Laptop は、2009 年 5 月 13 日から 8 月 23 日までの計 103 日間の観測に基づき、約 1.48 億の IP アドレスと約 20 億のコンテンツコピーに関する観察を報告しました。これは、当時の公開インフラを使って大量の IP—コンテンツ関係を構築できたことを示しています。それらの IP をすべて別々の自然人として確認したわけではなく、同数の完全ダウンロードを検証したという意味でもありません。著者らは、NAT、プロキシ、VPN などの交絡要因も論じています。^[22]

2008 年の Why My Printer Received a DMCA Takedown Notice は、別の側面を示しました。研究者が管理するプリンターと無線アクセスポイントが、該当するファイル交換に参加していないにもかかわらず、誤って通知を受け取ったのです。この結果は、間接的な一覧と実際のコンテンツ交換が異なる証拠であることを思い出させます。これは当時の手法に関する実験結果であり、今日のすべての監視サービスが同じ手順を使っているという説明に置き換えるべきではありません。^[23]

Nyaa／CODA／JHA の事例：結果は非公開の手法を説明してくれない

CODA は 2026 年 7 月 28 日、Nyaa の初期アップローダーに関する捜査を発表しました。発表によると、日本ハッカー協会が共同プロジェクトで解析ツールを開発し、被疑者に関する情報の取得を支援した後、京都府警が捜査によって特定に至りました。公開資料は、ツールと捜査協力の存在を裏付けますが、ツールを再構築できるほどのデータ源やアルゴリズムは明らかにしていません。^[24]

したがって、この発表だけでは、どの種類のトラフィック相関を使ったのか、何らかのログを取得したのか、当事者が VPN を使っていたのかは判断できません。「被疑者を特定した」という結果から、何らかの暗号プロトコルが破られたと逆算することもできません。事件で使われる「最初のアップローダー」は、一般的な BitTorrent の seed とも区別する必要があります。seed は通常、完全なデータを持つノードを意味し、最初の公開者とは限りません。^[1][24]

見事な成功率を読んだら、まず分母を探す

モデルが特定のデータセットで多数の正しい対応を見つけたことは、本当の進歩かもしれません。しかし、各サンプルに答えがあることをデータ側ですでに保証していたり、訓練とテストに似た断片が共有されていたり、最も有利なしきい値だけが報告されていたりすれば、未知のトラフィックや大量の誤った候補に対する性能はまだ分かりません。2026 年の Ephemeral と ESPRESSO の研究は、それぞれ攻撃者が十分に訓練した場合と、実際の Tor トラフィックにより近い評価を通じて、条件が結果をどう変えるかを示しています。^[13][16]

「偽陽性が見られなかった」にも標本数が必要です。ほぼ独立で同じ分布に従う負例が m 個あるとすると、偽陽性がゼロだったときの二項モデルによる片側 95% 上限は、およそ 3/m です。そのような負例を 300,000 個テストしても、上限は約 10⁻⁵ です。多数の組み合わせが同じ一群のトラフィックを共有していれば、互いに依存する可能性があります。そのため、組み合わせの総数をそのまま同じ程度の独立した証拠と見なすことはできません。これは統計モデルからの導出であり、特定の研究の実測値ではありません。

同様に、1 回の観察で直接接続がなかったとしても、裏付けられるのは、そのバージョン、その時点の状態、その観察範囲での結論だけです。それと「長期的な活動を関連付けにくい」ことの間には、なお別の問題があります。観察範囲を丁寧に記述してこそ、技術的な結果を使える知識として積み重ねられます。

プライバシーの境界は、観察できる情報の一つひとつにある

1 回のダウンロードをここまでたどると、問題はより具体的になりました。BitTorrent は仲間を見つけるために連絡先情報を交換し、VPN は外向きのエンドポイントを別の場所へ移します。インターフェースへのバインド、ファイアウォール、namespace が制限するのは、データが通れる経路です。これらは異なる露出面に有効に対処できますが、時刻、サイズ、アカウント、長期的な活動が残す関係を自動的に消すものではありません。

観察者が通信の両端を取得できるなら、防御はトラフィックの形そのものに対処する必要があります。パディングは使えるカバーを増やし、整形は送信のリズムを組み替え、ミキシングは異なる送信元を同じ時間・経路の文脈に置きます。どの変更にも条件があり、コストは帯域、待ち時間、バッファ、アプリケーションプロトコルへ移ります。

こう問うことで、VPN による分離の実際の価値と、匿名通信研究がミキシング、動的な整形、複数の送信元によるカバーを探究し続ける理由の両方を理解できます。安全性を見栄えのよい 1 つのスコアに押し込める必要はありません。保護する位置、使える証拠、支払うコストを明確にすること自体が、より信頼できる技術判断です。

出典

出典の参照日：2026-10-25。プロトコルの動作は原文書を基準とします。事業者のポリシーや発表は、その公開声明を表します。研究結果は、それぞれのデータ、攻撃者モデル、実験条件に沿って解釈します。本記事の図解は、描き直した教育用の模式図です。

1. [1] BitTorrent の基礎とコンテンツ識別BEP 3 · The BitTorrent Protocol；BEP 52 · BitTorrent Protocol v2；libtorrent manual · seed の定義原プロトコルと実装の文書。info dictionary、v1／v2 infohash、データのピース。
2. [2] TrackerBEP 15 · UDP Tracker ProtocolAnnounce フィールド、エンドポイント、port、IPv6 形式。
3. [3] 分散型の発見BEP 5 · DHT Protocolget_peers、announce_peer、token、送信元 IP。
4. [4] ピア交換BEP 11 · Peer ExchangePEX の追加／削除の意味論と、信頼できない入力。
5. [5] プライベート torrent とローカル発見BEP 27 · Private Torrents；BEP 14 · Local Service Discoveryアクセス制御、発見の範囲、multicast による通知。
6. [6] WireGuard と Linux による分離Routing & Network Namespace Integrationインターフェースと、その作成時の UDP socket が属する namespace。
7. [7] qBittorrent の識別情報Anonymous Mode公式 Wiki。ページ更新日は 2026-09-03 で、バージョンと private torrent による違いを明記。
8. [8] Mullvad のデータ・インフラポリシーNo-logging of user activity policy；RAM-only VPN infrastructure事業者の声明。活動データのポリシーは 2026-06-17 更新、RAM-only への移行発表は 2023 年。
9. [9] マルチホップ VPNMultihop with WireGuard入口と出口のネットワーク上の位置を分離。
10. [10] インターフェースと socket の動作qBittorrent · VPN interface binding；libtorrent · Settings公式文書。参照した libtorrent のオンラインリファレンスは 2.1.0 と表示されており、これをもとに読者のローカルバージョンを推定することはできません。
11. [11] Tor における両端観察の限界Limitations and remaining attacks against Tor’s anonymityTor 公式の説明。両端の timing correlation に関する脅威モデル。
12. [12] 経路迂回の研究Xue ほか · Bypassing Tunnels；Leviathan · TunnelVisionUSENIX Security 2023／2024 年の研究者による発表。現在のすべてのクライアントに同じ欠陥が残ることを意味しません。
13. [13] 現実の条件により近いトラフィック相関Jeon ほか · Brewing Under Pressure: More Realistic Tor Flow Correlation Considering Low FPRs著者が公開した CCS 2026 の原稿。PDF に記載された会期は 2026-11-15～19 で、本記事の日付時点ではまだ会期前です。
14. [14] 敵対的パディングHolland ほか · DeTorrentPoPETs 2024(1), 98–115。ウェブサイト指紋識別とトラフィック相関を別々に評価。
15. [15] DAITA の公開設計DAITA · Defense Against AI-guided Traffic Analysis；DAITA version 2Mullvad 公式の紹介と 2025-03-28 の v2 発表。固定サイズ、dummy、動的設定。
16. [16] 接続ごとに異なる防御Pulls ほか · Ephemeral Network-Layer Fingerprinting DefensesPoPETs 2026(1), 426–449。導入と実験の範囲、§5.3 の十分な訓練を行った場合の限界。
17. [17] ミキシングとカバートラフィックPiotrowska ほか · The Loopix Anonymity System；原論文の PDFUSENIX Security 2017。Poisson mixing、loop traffic、秒単位のメッセージ遅延。
18. [18] 匿名性とコストの形式的な制約Das ほか · Comprehensive Anonymity Trilemma: User Coordination is not enoughPoPETs 2020(3), 356–383。結論は匿名性の定義と攻撃者モデルに依存して成立。
19. [19] I2P の通信と脅威モデルI2P overview；BitTorrent over I2P；I2P’s Threat Model公式文書。脅威モデルのページは更新 2010-11、適用 0.8.1 と記載されており、分類の理解に用いるもので、現行バージョンの実測ではありません。
20. [20] ストリームの意味論RFC 9293 · Transmission Control ProtocolIETF、2022 年。信頼性のある順序付きバイトストリームと接続状態。
21. [21] 共有 IP とエンドポイント記録RFC 6302 · Logging Recommendations for Internet-Facing ServersIETF、2011 年。送信元 port、正確な時刻、共有 IPv4 の対応付けの問題。
22. [22] 大規模な P2P 観察Le Blond ほか · Spying the World from your LaptopUSENIX LEET 2010。観測は 2009 年に行われ、計 103 日間。
23. [23] 監視における誤った帰属判断Piatek ほか · Why My Printer Received a DMCA Takedown NoticeHotSec 2008。間接的な監視の限界と、プリンターが誤って通知を受け取る実験。
24. [24] Nyaa 事例の一次発表CODA · Nyaa の最初のアップローダー逮捕に関する発表（日本語）2026-07-28。協力と捜査結果を説明した発表であり、再構築可能な解析アルゴリズムは公開していません。
25. [25] Tor と Torrent の利用上の制限Tor Project · Can I use Tor with Torrent?Tor 公式は、Tor 経由で Torrent クライアントを使うことを推奨していません。