# P2P の匿名性：デジタル調査とエンドツーエンドのトラフィック相関

# P2P の匿名性、デジタル調査、エンドツーエンドのトラフィック相関に関する研究レポート

**バージョン：2026-08**
**テーマ：BitTorrent / VPN / Mullvad / Tor / I2P / Traffic Correlation / Traffic Analysis Defense**

---

## 要約

現代のネット上の匿名性という中心的な問題は、もはや「実際の IP を隠しているか」に単純化できません。より完全なモデルでは、次を同時に考慮する必要があります。

\[
\text{ネットワーク上の識別情報}
+
\text{プロトコルのメタデータ}
+
\text{セッションの連結可能性}
+
\text{時間的相関}
+
\text{行動フィンガープリント}
+
\text{レイヤー間の識別情報}
+
\text{端末の証拠}
\]

匿名システムの目標は、次の最大化として形式化できます。

\[
H(U\mid O)
\]

ここで \(U\) は実際の利用者、\(O\) は攻撃者が持つすべての observations です。ネットワーク、時刻、アカウント、端末、プロトコルなどの情報を観察した後も、身元に関する不確実性を最大限残すことを意味します。

一方、調査者は次を通じて、

\[
O_1+O_2+\cdots+O_n
\rightarrow
\text{エンティティ解決}
\rightarrow
\text{帰属判断}
\]

次の状態を目指します。

\[
H(U\mid O_1,\ldots,O_n)
\downarrow
\]

したがって現代の調査は通常、直接「VPN を破る」「WireGuard を破る」のではなく、**metadata correlation、timeline analysis、graph correlation、traffic analysis、account records、endpoint forensics、複数出所の証拠融合**によって候補集合を徐々に絞り込みます。

このレポートの中心的な結論は次のとおりです。

> **VPN は「自宅 IP → Internet activity」という直接の関連付けを断つことに最も優れますが、activity unlinkability、traffic-analysis resistance、long-term anonymity を自動的に提供するものではありません。**

低遅延通信の両端を同時に観察できる強力な攻撃者に対しては、**低遅延、低帯域オーバーヘッド、強い匿名性**を兼ね備える実用的で汎用的な解法は現在もありません。Tor 公式もこの制約を明示的に認めており、匿名通信研究の Anonymity Trilemma はこの基本的な trade-off をさらに形式化しています。

---

# 1. P2P の基本的な匿名性の問題

## 1.1 BitTorrent は本質的に匿名プロトコルではない

BitTorrent の第一の目標は、

> 他の peers を効率よく見つけ、データを交換すること。

であり、次ではありません。

> 誰がある swarm に参加しているかを隠すこと。

そのため BitTorrent には本来、複数の観察可能な面があります。

```text
                  ┌── トラッカー
                  │
BitTorrent クライアント ├── DHT
                  │
                  ├── PEX
                  │
                  ├── ピア
                  │
                  └── ローカルピア探索
```

標準的な UDP Tracker announce には次が含まれます。

- `info_hash`
- `peer_id`
- `downloaded`
- `left`
- `uploaded`
- `event`
- 待ち受けポート

tracker は当然、送信元の network endpoint も確認できます。

したがって tracker は容易に次を形成できます。

\[
(IP,\ InfoHash,\ Timestamp)
\]

さらには、

\[
(IP,\ InfoHash,\ Uploaded,\ Left,\ Event,\ Timestamp)
\]

これは BitTorrent protocol の通常の設計であり、脆弱性ではありません。

---

# 2. DHT と PEX の露出面

BitTorrent DHT（BEP-5）は分散型の peer discovery システムです。

その中心的な操作の 1 つである

\[
get\_peers(info\_hash)
\]

は、ある torrent に対応する peer contact information を取得します。`announce_peer` は、その torrent に参加していることを DHT に通知します。

BEP-5 は `announce_peer` が使う token を照会元 IP に結び付けることも要求し、照会されたノードは最終的にその送信元 IP と port を対応する infohash の下に保存します。

したがって DHT は次のように理解できます。

> **分散型の `infohash → peer endpoint` discovery database。**

PEX は BitTorrent 接続を確立した peers 間で他の peer 情報を交換し、別の peer discovery surface になります。

したがって、

```text
DHT 無効
PEX 無効
```

によって公開の discovery surface は減らせますが、匿名になるわけではありません。

```text
Tracker → endpoint は依然として見える
Peers   → endpoint は依然として見える
```

「自宅 IP が露出するか」を決める主な要因は、依然として network routing boundary です。

---

# 3. P2P の大規模監視はもはや理論上の問題ではない

USENIX LEET 2010 の **Spying the World from Your Laptop** は、1 台のコンピューターと BitTorrent の公開基盤だけで、利用者と torrent 活動の mapping を長期間、大規模に構築できることを示しました。

同研究は 103 日間でおよそ次を収集しました。

- 1 億 4,800 万の IP
- 約 20 億件の content-copy observations

また、観察した多数の新規 torrent について、コンテンツの最初の提供者を推測できたと報告しています。

一方で、逆の方向を示す重要な研究もあります。

HotSec 2008 の

**Why My Printer Received a DMCA Takedown Notice**

は、tracker が返す IP 情報だけに基づくと false attribution が生じ、実際にデータ交換していない端末にまで権利侵害通知が届く可能性を示しました。

そのため forensic evidence では、次の区別が必要です。

\[
tracker\ に掲載された\ IP
\]

と、

\[
検証済みの内容を\ 実際に交換した\ IP
\]

この 2 つは証拠としての強さが異なります。

---

# 4. 匿名性は異なる Security Properties に分けるべき

「匿名」は単一の Boolean ではありません。

より完全なモデルは次のように書けます。

\[
P=
(P_{IP},
P_{identity},
P_{activity},
P_{cross},
P_{fingerprint},
P_{timing},
P_{longitudinal})
\]

## 4.1 実 IP の秘匿

目指すのは、

```text
Tracker（トラッカー）
Peer（ピア）
DHT
Web サイト
```

自宅／会社の WAN IP が見えないことです。

VPN が最も得意とするのはこの層です。

---

## 4.2 身元の匿名性

ある活動を見ても、次は分かりません。

```text
活動 X
    ↓
誰か？
```

---

## 4.3 活動の非連結性

次が存在しても、

```text
活動 A
活動 B
活動 C
活動 D
```

次を容易に判断できないことです。

\[
A=B=C=D=\text{同じ操作者}
\]

これは単なる IP hiding より強い性質です。

---

## 4.4 レイヤー間の非連結性

次が、

```text
ブラウザの識別情報
      │
      ├── Web サイトのアカウント
      │
P2P の識別情報
      │
      └── Tracker/DHT
```

同じ entity に属すると証明されるのを防ぎます。

---

## 4.5 フィンガープリントの最小化

次のような、

```text
クライアントのバージョン
Peer ID のパターン
User-Agent
プロトコル拡張
OS／アプリケーションの動作
```

software fingerprint を減らします。

qBittorrent の Anonymous Mode は主にこの分類に属します。公式は、それ自体では強い匿名性を提供せず、BitTorrent client が露出する identifying information を減らすものだと明示しています。

---

## 4.6 時刻／トラフィック解析への耐性

入口の

\[
X(t)
\]

と出口の

\[
Y(t)
\]

が同じ communication だと判断されにくくすることです。

これは Tor、VPN、多くの low-latency anonymity systems にとって最も難しい問題の 1 つです。

---

## 4.7 長期匿名性

匿名性は単に、

> 1 回の活動で漏えいがあったか。

ではなく、次の問題です。

> 数百、数千回の活動を行った後、過去の observations が徐々に identity を明らかにするか？

したがって研究すべきなのは、

\[
H(U\mid O^{(1)},O^{(2)},...,O^{(n)})
\]

であり、単一 session だけではありません。

---

# 5. 現代の調査者モデル

現代のデジタル調査は次のように抽象化できます。

```text
                 観察可能な出来事
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     ネットワーク    サービス      端末
     証拠            証拠          証拠
        │              │              │
        ├──────────────┼──────────────┤
                       ▼
                    時系列
                       │
                       ▼
                エンティティ解決
                       │
                       ▼
                候補の順位付け
                       │
                       ▼
                 裏付け
                       │
                       ▼
                   帰属判断
```

調査者は必ずしも 1 つの決定的な証拠を必要としません。

より一般的なのは、

\[
E_1+E_2+E_3+\cdots+E_n
\]

がすべて同じ hypothesis を支えることです。

---

# 6. グラフに基づく帰属モデル

この問題は次のモデルに適しています。

\[
G=(V,E)
\]

nodes には次が含まれます。

```text
人物
アカウント
端末
IP
VPN 出口
セッション
ブラウザ
Torrent
Infohash
Tracker のイベント
サーバー
支払い
メール
タイムスタンプ
```

edges には次が含まれます。

```text
connected_from
logged_in_from
observed_at
announced
created
controlled_by
paid_for
same_session
same_device
temporally_correlated
```

調査の本質は、多くの disconnected components から、

```text
A        B        C
```

信頼できる cross-component edges を徐々に見つけ、

```text
A ───── B ───── C
```

最終的に entity cluster を形成することです。

---

# 7. ベイズ的な帰属判断

次を仮定します。

\[
H_A=\text{Alice は Activity X の操作者である}
\]

次の証拠があるとき、

\[
E_1,E_2,\ldots,E_n
\]

次を継続的に更新します。

\[
P(H_A\mid E_1,\ldots,E_n)
\]

これは「多数の弱いシグナルが徐々に強い attribution を形成する」過程をよく表します。

ただし実務では、単純に次を仮定できません。

\[
P(E_1,E_2|H)
=
P(E_1|H)P(E_2|H)
\]

多くの evidence が共通の原因を持つか、同じ observation source に由来するためです。

そうしないと **double counting evidence** が起きやすくなります。

---

# 8. 交差攻撃

もう 1 つの重要な匿名性モデルは、候補集合の交差です。

次を仮定します。

\[
S_0
\]

はすべての可能な利用者の集合です。

最初の出来事の時点でオンライン：

\[
S_1
\]

2 回目：

\[
S_2
\]

継続すると：

\[
S^*
=
S_1\cap S_2\cap\dots\cap S_n
\]

次が生じ得ます。

```text
10000
  ↓
3000
  ↓
600
  ↓
80
  ↓
12
  ↓
2
```

I2P 自身の threat model も、timing、intersection、predecessor、Sybil、traffic analysis などを考慮すべき匿名性攻撃として明示しています。

したがって、

> **長期的で反復的、規則的な匿名活動そのものが、リスクの蓄積です。**

---

# 9. P2P の第一段階の防御：Network Isolation

セキュリティ要件が次だけなら、

> **BitTorrent の実際の自宅 IP は、tracker、DHT、swarm に絶対に入ってはいけない。**

工学的に最も信頼できる security invariant は次のとおりです。

\[
\forall p\in P2PTraffic:
OutgoingInterface(p)=VPN
\]

さらに、

\[
VPN\downarrow
\Rightarrow
P2PTraffic=0
\]

つまり **fail closed** です。

---

# 10. VPN＋アプリケーションのバインド

qBittorrent は指定した VPN network interface に自らを bind できます。

公式資料はこの機能を、VPN kill-switch に加える漏えい防止層と明示しています。VPN interface が存在しない場合、qBittorrent は通常の物理 interface に切り替わるべきではありません。

典型例：

```text
eth0 = 物理 WAN
wg0  = VPN

qBittorrent
     │
     └── wg0 にバインド
```

---

# 11. Fail-Closed ファイアウォール

さらに進めると、

\[
P2P\ プロセス
\land
oif\neq wg0
\Rightarrow DROP
\]

つまり、

```text
               ┌── wg0  → 許可
qBittorrent ───┤
               └── eth0 → 遮断
```

これにより、次のような

- VPN daemon のクラッシュ
- 経路設定の誤り
- 再接続
- インターフェースの変更

障害状況に対処できます。

---

# 12. ネットワーク名前空間

より強い構成は次のとおりです。

```text
物理ネットワーク名前空間
│
└── eth0 / wlan0
        │
        └── 暗号化された WireGuard ソケット


P2P 名前空間
│
├── qBittorrent
└── wg0
```

P2P namespace にはそもそも次がありません。

```text
eth0
wlan0
```

したがって VPN route が消えても、通常の WAN fallback path は存在しません。

WireGuard 公式資料はこの方式を直接示しています。container/network namespace 内に `wg0` だけを置けば、利用可能な Internet route は WireGuard だけになります。

単に次へ依存するよりも、

```text
デフォルトルート → VPN
```

kernel-level security invariant を確立しやすくなります。

---

# 13. Routing-only VPN が理想的とは言えない理由

USENIX Security 2023 の **Bypassing Tunnels** は、多くの VPN client のセキュリティ境界が routing-table manipulation に基づき、routing exceptions が通信漏えいの攻撃面になり得ることを示しました。研究者は複数のプラットフォームと VPN client で routing-based VPN bypass を実証しました。

TunnelVision / CVE-2024-3661 は、DHCP Option 121 からより specific な routes を注入し、一部の VPN 通信を tunnel から迂回させる方法を示しました。研究者は Linux network namespace も強力な mitigation として挙げています。

したがって、

```text
VPN connected = true
```

は必ずしも次を意味しません。

```text
∀ 通信 → VPN
```

---

# 14. IPv6、DNS、その他の迂回経路

P2P isolation では次を同時に扱う必要があります。

\[
IPv4
\]

と、

\[
IPv6
\]

そうしなければ次が生じ得ます。

```text
IPv4 → VPN
IPv6 → 物理 WAN
```

DNS も同じ network boundary に含めるべきです。

DNS leak は通常、ISP が torrent の `infohash` を自動的に知る意味ではありませんが、次のような

```text
tracker.example.org
```

service-level information が露出する可能性があります。

---

# 15. Seedbox

Seedbox が変えるのは network location です。

```text
自宅
 │ HTTPS/SSH
 ▼
Seedbox
 │
 ▼
BitTorrent Swarm（参加ノード群）
```

したがって、

\[
ResidentialIP\notin Swarm
\]

ただし、

```text
Swarm → Seedbox IP
```

は依然として存在します。

したがって seedbox が提供するのは、

> **ネットワーク上の所在の分離**

であり、次ではありません。

> 完全匿名。

信頼境界は単に次から、

```text
VPN プロバイダー
```

次へ移るだけです。

```text
ホスティング／Seedbox プロバイダー
```

---

# 16. Tor と P2P

Tor は低遅延の匿名 communication network です。主要なセキュリティ上の考え方は、単一 relay が次を同時に知るのを避けることです。

```text
利用者
+
宛先
```

ただし Tor 公式は次を明示しています。

> 攻撃者が communication channel の両端を同時に観察できる場合、timing と volume による correlation を確実に防ぐ実用的な low-latency system は現在ありません。

したがって Tor の主要戦略は「correlation を消す」ことではなく、

> 攻撃者が両端の observation position を同時に得る可能性を減らすことです。

---

# 17. I2P

I2P の BitTorrent モデルは、通常の clearnet BitTorrent と異なります。

匿名 identity は clearnet の

```text
IP:port
```

を application peer identity に直接使わず、I2P overlay の Destination と tunnel infrastructure を使います。

したがってこれは、

> **プロトコルレベルの匿名 P2P オーバーレイ**

であり、次ではありません。

> clearnet の BitTorrent＋VPN。

ただし I2P 自身も、timing、intersection、traffic analysis などの攻撃が threat model の一部であることを明示的に認めています。

---

# 18. Nyaa / CODA / JHA の事例

2026 年 7 月、日本の京都府警は、Nyaa の first uploader として NHK などのコンテンツを共有した疑いのある男性を逮捕しました。

CODA は公式に次を確認しています。

- CODA は METI が支援する CBEP 計画の下で Nyaa を調査した。
- Japan Hacker Association が analytical tool を開発した。
- CODA はそのツールを使って容疑者に関連する情報を取得した。
- 京都府警は関連情報を基にさらに捜査し、容疑者を特定した。

ただし現在、公式は**そのツールの algorithm を公開していません**。

したがって、次のような

```text
CDN ログ
Cookie
ログイン履歴
VPN ログ
```

具体的な手法を確認済みの事実として扱ってはいけません。

比較的妥当な技術的仮説には、次が含まれます。

```text
索引のメタデータ
        +
Tracker のメタデータ
        +
時間的相関
        +
過去の観察
        ↓
候補の特定
```

ただし、これは依然として推論です。

---

# 19. Mullvad の匿名性モデル

Mullvad は privacy-oriented VPN であり、完全な anonymous communication network ではありません。

主に解決するのは、次の

\[
ResidentialIP
\rightarrow
InternetActivity
\]

直接的な関連付けです。

主な仕組みは次のとおりです。

- 共用 VPN 出口
- 番号付きアカウント
- 活動ログを保存しない
- Multihop
- DAITA
- RAM-only サーバー基盤

---

# 20. Mullvad のノーログ方針

2026 年時点の Mullvad 公式ポリシーは、次を永続保存しないと述べています。

- トラフィック
- DNS 要求
- 接続タイムスタンプ
- 切断タイムスタンプ
- セッション継続時間
- IP アドレス
- 利用者の帯域使用量

connection validation に必要なリアルタイム状態は temporary memory で処理され、永続保存されません。

したがって Mullvad は、次の

\[
(SourceIP,\ Account,\ ExitIP,\ Timestamp)
\]

retrospective connection table の形成を避けようとしています。

---

# 21. Numbered Account と支払い

Mullvad は従来の email/password identity を求めません。

ただし payment 自体が別の attribution surface になる可能性があります。

例えば一部の支払い方法には、次に関連する

```text
支払い
   ↓
Mullvad アカウント
```

記録があり、公式データポリシーは支払い方法ごとの保存方法を明示しています。

そのため、

\[
Person\rightarrow Account
\]

が成立する場合があります。

ただし connection logs がなければ、

\[
アカウント
\rightarrow
ExitIP@time
\]

の直接的な過去の mapping は依然として欠けます。

---

# 22. Mullvad の RAM-only 基盤

Mullvad は 2023 年に VPN infrastructure の RAM-only migration の完了を発表しました。VPN server は一般的な persistent disk を運用基盤とせず、infrastructure audit もこの architecture を検査しています。

その安全性上の意義は、次による

```text
サーバーの押収
   ↓
過去のディスク残留データ
```

データ残留の危険を減らすことです。

ただし RAM-only は、

\[
\neq
\]

「すべての攻撃者がリアルタイムに traffic を観察できない」。

---

# 23. Mullvad Multihop

通常の VPN：

```text
利用者
 │
 ▼
VPN
 │
 ▼
宛先
```

Multihop：

```text
利用者
 │
 ▼
入口 VPN
 │
 ▼
出口 VPN
 │
 ▼
宛先
```

Mullvad 公式は、Multihop の目的の 1 つが、observation positions を異なる server/location/provider に分散して incoming/outgoing traffic correlation を難しくすることだと述べています。

それでも Tor 型の複数運営者による trust distribution とは異なります。

---

# 24. DAITA

DAITA：

**AI によるトラフィック解析への防御**

の主目的は cryptographic strength を増すことではなく、encrypted traffic の observable shape を変えることです。

Mullvad 公式が挙げる主要技術は次のとおりです。

- ランダムなバックグラウンド／ダミー通信
- 固定パケットサイズ型のパディング
- トラフィックパターンの攪乱
- 接続ごとの動的設定

DAITA v2 は dummy traffic overhead をさらに減らし、接続ごとに異なる tunnel traffic characteristics を使います。

したがって主に作用するのは、

\[
TrafficFingerprint
\]

と、

\[
TrafficCorrelationSignal
\]

であり、次ではありません。

\[
AES/WireGuardCryptography
\]

---

# 25. エンドツーエンドのトラフィック相関

これはレポート全体で最も重要な技術的問題です。

ingress observation を次とします。

\[
X=\{(t_i,s_i,d_i)\}_{i=1}^{n}
\]

ここで、

- \(t_i\)：タイムスタンプ
- \(s_i\)：パケットサイズ
- \(d_i\)：方向

出口は、

\[
Y=\{(t'_j,s'_j,d'_j)\}_{j=1}^{m}
\]

攻撃者が解くのは、

\[
Match(X,Y)?
\]

すなわち、

> 入口 flow X と同じ communication なのは、どの出口 flow か？

---

# 26. Encryption はすべての Metadata を隠せない

次であっても、

\[
C=Enc_K(M)
\]

攻撃者には次が見える可能性があります。

```text
パケットの時刻
パケット数
パケットサイズ
方向
バースト構造
アイドル区間
フローの継続時間
総量
```

したがって、

\[
Encryption\neq Traffic\ Unobservability
\]

これも Tor 公式がエンドツーエンドの correlation threat を明示的に認める理由です。

---

# 27. 最も基本的な Correlation Attack

時間を window に分けます。

\[
x_k=
bytes(X,t_k,t_k+\Delta t)
\]

\[
y_k=
bytes(Y,t_k,t_k+\Delta t)
\]

lagged correlation を計算できます。

\[
C(\tau)
=
Corr(x_k,y_{k+\tau})
\]

次の場合、

```text
候補 A = 0.17
候補 B = 0.10
候補 C = 0.91
候補 D = 0.05
```

C は明らかに追加分析の対象となります。

実際の modern classifier はより複雑な feature representation を使えますが、主要な情報源は変わりません。

\[
Timing+Volume+Direction
\]

---

# 28. Data Conservation が中心的な問題

cumulative bytes を定義します。

\[
B_X(t)=
\sum_{i:t_i\leq t}s_i
\]

低遅延 proxy は ingress data をほぼ即時に egress へ転送する必要があります。

そのため通常、次が成立します。

\[
B_Y(t+\delta)\approx B_X(t)
\]

ここで \(\delta\) は network delay です。

実データが ingress に届く前に egress に現れることはありません。

したがって low-latency forwarding 自体が causality constraint を生みます。

---

# 29. Mutual Information モデル

理想的な匿名システムが目指すのは、

\[
I(X;Y)\rightarrow0
\]

つまり、

> ingress traffic を知っても、egress traffic の推測にほとんど追加情報を与えないこと。

ただし通常の VPN / Tor は次のように抽象化できます。

\[
Y=T(X)+N
\]

ここで、

- \(T\)：中継／ネットワークの変換
- \(N\)：ジッター、輻輳、パケット化のノイズ

通常、

\[
I(X;Y)>0
\]

であり、かなり高い場合もあります。

---

# 30. False Positive と Base Rate

Traffic-correlation 論文では、次だけでなく、

\[
TPR
\]

次も見る必要があります。

\[
FPR
\]

次を仮定します。

\[
FPR=10^{-3}
\]

次の数の

\[
10^7
\]

candidate comparisons では、なお次が生じ得ます。

\[
10^4
\]

偽陽性。

したがって、

> 特定対象に関する仮説の確認

と、

> インターネット規模での特定

は非常に異なる問題です。

---

# 31. Passive と Active Correlation

### 受動的観察

次だけを観察し、

```text
入口
出口
```

statistical matching を行います。

### 能動的攻撃

攻撃者は flow に次を注入し、

```text
遅延
破棄
レートの攪乱
```

特有の temporal pattern を作り、反対側に対応する pattern が現れるかを観察できます。

Active attack は通常、純粋な passive observation より強力です。

---

# 32. 匿名性のトリレンマ

匿名通信の基本的な trade-off の 1 つは次のように書けます。

### 強い匿名性

\[
I(X;Y)\rightarrow0
\]

### 低遅延

\[
L\rightarrow0
\]

### 低い帯域オーバーヘッド

\[
B_{dummy}\rightarrow0
\]

研究結果は、anonymous communication systems が次を同時には達成できないことを示しています。

> 強い匿名性＋低い遅延オーバーヘッド＋低い帯域オーバーヘッド。

PoPETs 2020 の Comprehensive Anonymity Trilemma は、impossibility result を user coordination を含むより広い匿名システムへ拡張しました。

つまり問題は単に、

> 「十分に優れた padding algorithm がまだ発明されていない。」

ということではなく、より根本的な制約があります。

---

# 33. なぜ Trilemma が生じるのか？

利用者が現在 idle だとします。

observer に次を判断させたくなければ、

```text
利用者はアイドル状態
```

次を送り続ける必要があります。

\[
DummyTraffic>0
\]

したがって、

\[
BandwidthOverhead\uparrow
\]

逆に Alice が突然大量の traffic を生成したとします。

output に burst を即座に反映させたくなければ、

### 方法 A

データを遅らせる：

\[
Latency\uparrow
\]

### 方法 B

普段から大量の cover traffic を送る：

\[
Bandwidth\uparrow
\]

そのため、

\[
StrongPrivacy
\]

必然的に何らかの資源を消費します。

---

# 34. 防御 1：固定レートの整形

最も強力で高価な方法の 1 つ：

\[
R(t)=R_0
\]

real traffic があるかどうかにかかわらず、

```text
実データ
ダミー
ダミー
実データ
ダミー
```

observer に常に見えるのは、

```text
████████████████████████
```

次を大きく隠せます。

- バーストの時刻
- パケット数
- 通信量の形状
- アイドル期間

ただし、

次の場合、

\[
R_{real}<R_0
\]

結果は、

\[
BandwidthWaste=R_0-R_{real}
\]

次の場合、

\[
R_{real}>R_0
\]

queue は、

\[
Q(t)\uparrow
\]

そして、

\[
Latency\uparrow
\]

これが Anonymity Trilemma の最も直感的な具体例です。

---

# 35. 防御 2：適応型パディング

より現実的な方法は、

\[
X'=X+N
\]

ここで \(N\) は selective dummy traffic です。

常に constant rate にする必要はなく、fingerprint information の多い traffic pattern にだけ cover を追加します。

利点：

- latency はほとんど増えない
- bandwidth overhead を制御できる
- 既存の VPN/Tor に導入できる

欠点：

\[
I(X;X')>0
\]

は通常、依然として成立します。

---

# 36. DeTorrent

PoPETs 2024 の DeTorrent は、competing neural networks で padding-only defense を自動設計します。

防御者：

\[
D_\theta(X)
\]

攻撃者：

\[
A_\phi(D_\theta(X))
\]

adversarial optimization に似た構造を形成します。

\[
\min_\theta\max_\phi L
\]

同研究の flow-correlation 評価は、非常に低い FPR operating point で攻撃 TPR を大きく下げ、real traffic を遅延させる必要もないことを示しています。

その価値は、

> padding policy が完全に人手の heuristic による設計ではなくなることです。

---

# 37. 防御 3：一時的な防御

固定した defense 自体が fingerprint になることがあります。

例えば全利用者が次を使うと、

```text
パディングの分布 = θ
```

攻撃者は次を学習できます。

\[
P(X'\mid\theta)
\]

PoPETs 2026 の **Ephemeral Network-Layer Fingerprinting Defenses** は次を提案します。

\[
\theta_i\sim P(\Theta)
\]

各 connection に異なる traffic-defense configuration を使わせます。

同研究は手法を WireGuard に統合し、Mullvad 環境で多数の日常利用者向けに実際に導入したと報告しています。

Mullvad DAITA v2 の dynamic configurations も近い方向にあります。

---

# 38. 防御 4：混合＋遅延

padding より根本的な方法：

```text
A ─┐
B ─┼─► 混合
C ─┤
D ─┘
      │
      ├── 遅延
      ├── 並べ替え
      └── カバートラフィック
```

次の状態を目指します。

\[
t_{out}
\not\approx
t_{in}+\delta
\]

これは input/output timing dependency を実際に崩します。

---

# 39. Loopix

Loopix はこの方式の代表例です。

次を使用し、

- Poisson 混合
- ランダム遅延
- カバートラフィック
- ループメッセージ

global network adversary を含む threat model に対して traffic-analysis resistance を提供します。

代償として message latency 全体が**秒単位**になります。mixnet としては比較的低いとしてもです。

したがって、次により適しています。

```text
メッセージの送受信
非同期通信
メールに類するシステム
```

であり、次ではありません。

```text
ゲーム
SSH
リモートデスクトップ
対話型の低遅延 Web
```

---

# 40. 防御 5：複数利用者の集約

もう 1 つの重要な方向は、偽の traffic を増やすのではなく、

> 他の利用者の実際の traffic を自分の cover traffic にすることです。

例えば、

```text
Alice ─┐
Bob ───┤
Carol ─┼── 集約器／ミキサー
Dave ──┤
Eve ───┘
```

入力：

\[
X_A,X_B,X_C,\ldots
\]

が共同で次を形成します。

\[
Y_1,Y_2,Y_3,\ldots
\]

調査者は次だけを解けばよいのではなく、

\[
X_A\leftrightarrow Y_A
\]

permutation / assignment problem を解く必要があります。

これにより次を増やせます。

\[
H(Y\mid X)
\]

しかも、すべての cover traffic を dummy bytes にする必要はありません。

---

# 41. 防御 6：通信の分割

1 本の flow を、

\[
X
\]

次に分割し、

\[
X_1,X_2,X_3
\]

異なる path に流します。

```text
             ┌── 経路 A
通信 ─────┼── 経路 B
             └── 経路 C
```

adversary が一部の path だけを観察できるなら、

\[
I(X;X_i)
<
I(X;X_1+X_2+X_3)
\]

correlation を効果的に減らせます。

ただし真の global observer には、

\[
X_1+X_2+X_3
\]

再集約される可能性があります。

したがって multipath の主な利点は、

> partial observer のコストを増やすことです。

---

# 42. 防御 7：出口変換

従来の padding が主に変えるのは、

```text
入口の形状
```

一方、出口の connection topology は次のままかもしれません。

\[
1\ 入口\ フロー
\leftrightarrow
1\ 出口\ フロー
\]

より踏み込んだ設計では次を行え、

```text
実フロー
   ↓
分割／並べ替え
   ↓
仮想フロー A
仮想フロー B
仮想フロー C
```

次を直接崩せます。

\[
FlowTopology_{in}
\approx
FlowTopology_{out}
\]

これは単なる packet padding よりも研究する価値のある方向です。

---

# 43. 私が研究に値すると考える新しい構成

現在の研究を総合すると、次を提案できます。

# 遅延を有界にした複数フローのミックスネットワーク

構成：

```text
利用者

A ─┐
B ─┤
C ─┤
D ─┼── 入口集約器
E ─┤
F ─┘
          │
          ▼
   一時的な整形器
          │
          ▼
   遅延を有界にしたミキサー
          │
     ┌────┼────┐
     ▼    ▼    ▼
   経路 1 経路 2 経路 3
     │    │    │
     └────┼────┘
          ▼
      出口ミキサー
          │
          ▼
 分割／並べ替え／統合
          │
          ▼
     宛先
```

目標は perfect anonymity ではなく、次の条件の下で、

\[
Latency<L_{max}
\]

\[
Bandwidth<B_{max}
\]

次を最小化することです。

\[
I(X;Y)
\]

---

# 44. レイヤー 1：一時的な整形

各 flow について、

\[
\theta_i\sim P(\Theta)
\]

次をランダムに決定します。

- パディングのスケジュール
- ダミーの分布
- パケットサイズの方針
- バースト動作

固定した defense fingerprint の形成を避けます。

---

# 45. レイヤー 2：有界ランダム遅延

各 packet/message について、

\[
D_i\sim P_D
\]

ただし、

\[
D_i<D_{max}
\]

例えば異なる application class では、

```text
ゲーム         → 非常に小さい Dmax
Web            → 小さい Dmax
ストリーミング → 中程度の Dmax
メッセージ     → 大きい Dmax
```

つまり privacy policy を QoS-aware にします。

---

# 46. レイヤー 3：複数利用者の混合

aggregation queue を利用し、

```text
A のパケット
B のパケット
C のパケット
A のパケット
D のパケット
```

再 scheduling して、

```text
C
A
B
D
A
```

latency budget の範囲で 1 対 1 の timing mapping を崩します。

---

# 47. レイヤー 4：実通信をカバーとして使う

queue にすでに次があるとすると、

\[
X_A,X_B,X_C
\]

次を優先して、

\[
X_B,X_C
\]

A の anonymity cover として使います。

anonymity deficit が高すぎる場合にだけ、

\[
inject\ dummy
\]

これにより次を大きく減らせる可能性があります。

\[
DummyBandwidth
\]

---

# 48. レイヤー 5：出口フローの変換

出力時にさらに次を実行し、

```text
統合
分割
並べ替え
接続の移行
```

次のような、

\[
IngressTopology
\leftrightarrow
EgressTopology
\]

の識別可能性を下げます。

---

# 49. 適応型プライバシー制御器

machine learning を最も活用すべき場所は、単なる「ランダム padding」ではなく constrained optimization です。

\[
\min_\pi
\left[
\lambda_1L_{privacy}
+
\lambda_2L_{latency}
+
\lambda_3L_{bandwidth}
\right]
\]

制約条件：

\[
Latency<L_{QoS}
\]

\[
Bandwidth<B_{budget}
\]

ここで、

\[
L_{privacy}
\]

は次によって、

- 攻撃の ROC
- 対照的な照合の正確度
- 推定相互情報量
- 匿名集合のエントロピー

共同で近似できます。

---

# 50. 防御者と攻撃者の敵対的学習

防御者：

\[
D_\theta(X)
\]

defended trace を出力します。

攻撃者：

\[
A_\phi(D_\theta(X),Y)
\]

出力：

\[
P(match)
\]

研究課題は次のように書けます。

\[
\min_\theta\max_\phi
L_{attack}
\]

同時に次を加えます。

\[
L_{latency}
\]

と、

\[
L_{bandwidth}
\]

正則化／制約。

action space は padding だけでなく、次も含められます。

```text
パディング
遅延
バースト整形
多重化
分割
並べ替え
接続の移行
```

---

# 51. Classification Accuracy だけを安全性指標にしてはいけない

例えば、

```text
攻撃の正確度：
90% → 20%
```

は安全性を直接証明しません。

なぜなら、

> 特定の固定 attacker architecture に overfit しているだけかもしれないためです。

より完全なテストには次を含めるべきです。

\[
TPR
\]

\[
FPR
\]

\[
ROC
\]

\[
適合率
\]

\[
再現率
\]

さらに candidate population size です。

---

# 52. Mutual Information はより追求する価値のある方向

本当に減らしたいのは、

\[
I(X;Y)
\]

あるいは増やしたいのは、

\[
H(X\mid Y)
\]

理想的な状態：

\[
P(Y\mid X_A)
\approx
P(Y\mid X_B)
\]

つまり、異なる ingress flow が observer にとって increasingly indistinguishable になることです。

これは、

> 「ある CNN の accuracy を下げること」

よりも実際の security property に近いものです。

---

# 53. P2P プライバシー実験環境

研究する場合は、合法的なデータのみの使用を推奨します。

```text
ランダムなテストファイル
Linux ISO
自作データセット
```

次を構築し、

```text
クライアント VM
   │
   ▼
VPN
   │
   ├── トラッカー VM
   ├── ピア VM
   └── 観察者 VM
```

次の各 observation point で、

```text
入口
VPN インターフェース
物理 NIC
Tracker（トラッカー）
Peer（ピア）
```

traffic を capture します。

---

# 54. ネットワーク隔離の障害注入

テストすべき項目：

```text
VPN 切断
VPN サーバーに到達不能
経路の変更
IPv6 の有効化
DNS の変更
Wi-Fi ↔ Ethernet の切り替え
サスペンド／復帰
再起動
VPN より先にクライアントが起動
VPN の再接続
```

中核となる acceptance criterion：

\[
VPN\downarrow
\Rightarrow
P2PTraffic=0
\]

---

# 55. トラフィック相関の実験環境

続いて次を構築します。

```text
入口のキャプチャ：
X

出口の候補：
Y1
Y2
...
Yn
```

比較：

### ベースライン

```text
WireGuard
```

### 防御 A

```text
WireGuard＋パディング
```

### 防御 B

```text
DAITA に似た一時的な整形
```

### 防御 C

```text
有界遅延
```

### 防御 D

```text
複数利用者の集約
```

### 防御 E

```text
集約＋整形＋出口変換
```

---

# 56. 推奨する主要 Metrics

### 相関

\[
Corr(X,Y)
\]

### 相互情報量

\[
I(X;Y)
\]

### 攻撃の ROC

\[
TPR(FPR)
\]

特に次のような、

\[
FPR=10^{-3}
\]

\[
10^{-4}
\]

\[
10^{-5}
\]

実際に attribution-sensitive な operating regions を観察します。

### 遅延

\[
P50,P95,P99
\]

### 帯域オーバーヘッド

\[
O_B=
\frac{Bytes_{defended}}
{Bytes_{real}}-1
\]

### 匿名集合

\[
|S|
\]

または entropy：

\[
H(U\mid O)
\]

---

# 57. 防御能力の比較

| 構成 | Real-IP 保護 | Activity unlinkability | Timing resistance | 遅延 | 帯域コスト |
|---|---:|---:|---:|---:|---:|
| BitTorrent encryption | 低 | 低 | 低 | 極低 | 極低 |
| qBittorrent Anonymous Mode | 低 | 低 | 低 | 極低 | 極低 |
| VPN | 高 | 低 | 低 | 低 | 低 |
| VPN + bind + firewall | 非常に高 | 低 | 低 | 低 | 低 |
| VPN + network namespace | 極めて高 | 低 | 低 | 低 | 低 |
| Seedbox | 極めて高 | 低～中 | 低 | 低 | 中 |
| Mullvad + Multihop | 極めて高 | 中 | 中低 | 低～中 | 低 |
| Mullvad + DAITA | 極めて高 | 中 | 中 | 低 | 中 |
| Constant-rate shaping | 高 | 中～高 | 高 | 中 | 非常に高 |
| Multi-path | 高 | 中 | 中 | 低～中 | 中 |
| Bounded multi-user mixing | 高 | 高い可能性 | 高い可能性 | 中 | 中 |
| Loopix / Mixnet | 高 | 高 | 高 | 秒単位 | 中～高 |
| I2P-native | 高 | clearnet VPN より高い | 中～高 | 中 | 中 |

この表は threat-model レベルの相対分析であり、統一 benchmark ではありません。

---

# 58. 最も重要な Security Boundary

問題全体は 2 つの層に分けられます。

## レイヤー A：ネットワークからの匿名解除

問題：

\[
VPN\ Exit
\rightarrow
実 IP は？
\]

主な防御：

```text
VPN
経路隔離
ファイアウォール
ネットワーク名前空間
インターフェースのバインド
```

---

## レイヤー B：行動／通信の帰属判断

問題：

\[
Activity_A
+
Activity_B
+
時刻
+
Metadata（メタデータ）
\rightarrow
同じ操作者か？
\]

主な研究領域：

```text
トラフィック解析への耐性
混合
パディング
カバートラフィック
交差攻撃への耐性
レイヤー間の非連結性
行動のプライバシー
```

前者を完璧に実現すること：

\[
\nRightarrow
\]

後者が自然に安全になること。

---

# 59. Mullvad の正しい位置付け

Mullvad が特に強いのは、

\[
Network\ Identity\ Separation
\]

+

\[
Provider\ Data\ Minimization
\]

+

\[
Traffic\ Fingerprint\ Reduction
\]

つまり、

```text
共用出口
活動ログを保存しない
番号付きアカウント
Multihop
RAM-only
DAITA
```

ただし依然として、

> **低遅延 VPN の構成**

であり、次ではありません。

> トラフィック解析を受け付けない匿名通信システム。

したがって DAITA が次であっても、

\[
I(X;Y)\downarrow
\]

次を合理的に仮定することはできません。

\[
I(X;Y)=0
\]

---

# 60. 現代の調査者が実際に探すのは「最も弱い Edge」

次を仮定します。

```text
暗号技術           ██████████
VPN の経路制御     ██████████
実 IP の隔離       ██████████
```

ただし、

```text
アプリの識別情報   █████
時刻               ████
端末               ███
アカウント         ███
操作ミス           ██
```

そうなると強力な調査者には次をする理由がありません。

> WireGuard を破る。

代わりに次を行い、

```text
別の手掛かりへ移る
```

次へ進みます。

```text
アカウント
端末
時刻
行動
プロバイダー
メタデータ
```

したがって、

\[
Security(System)
\approx
\min_i Security(Component_i)
\]

正式な security theorem ではありませんが、実際の attribution attack surface を表すのに適しています。

---

# 61. 研究の中心的な結論

研究全体の最も重要な概念は、次の点にまとめられます。

### 第 1

\[
Encryption\neq Anonymity
\]

### 第 2

\[
IP\ Hiding\neq Activity\ Unlinkability
\]

### 第 3

\[
VPN\neq Anonymous\ Communication\ Network
\]

### 第 4

\[
No\ Logs
\]

と、

\[
Strong\ Traffic\ Analysis\ Resistance
\]

は異なる 2 つの security properties です。

### 第 5

低遅延 anonymity の最大の根本問題は、

\[
Output(t)\approx Input(t-\delta)
\]

攻撃者はこの dependency を利用します。

### 第 6

本来の traffic-analysis defense は次に近づくことを目指します。

\[
P(Y\mid X)\approx P(Y)
\]

つまり、

\[
I(X;Y)\rightarrow0
\]

### 第 7

ただし、

\[
Strong\ anonymity
+
Low\ latency
+
Low\ bandwidth
\]

には根本的な trade-off があります。

---

# 62. 今後最も研究する価値のある方向

研究課題を次のように設定するなら、

> **対話性を保つ latency budget の下で、最小の bandwidth overhead により end-to-end traffic correlation を最大限減らすにはどうすればよいか？**

私が最も研究する価値があると考える組み合わせは、次でも、

```text
VPN のホップ数を増やす
```

次でもなく、

```text
暗号化を増やす
```

ではなく、次の問題です。

\[
\boxed{
Ephemeral\ Shaping
+
Bounded\ Delay
+
Multi-user\ Aggregation
+
Real-Traffic\ Cover
+
Egress\ Transformation
}
\]

さらに次を通じて、

\[
\min
\left(
I(X;Y)
+
\lambda_L Latency
+
\lambda_B Bandwidth
\right)
\]

正式な optimization objective を確立することです。

---

# 63. 最終結論

一般的な P2P privacy では、

\[
\boxed{
VPN
+
Interface\ Binding
+
ファイアウォール
+
Network\ Namespace
}
\]

により、次に非常に強く対処できます。

\[
RealIP\ Leakage
\]

WireGuard 公式の network-namespace architecture は、fail-closed engineering boundary として特に適しています。

ただし threat model が次へ引き上げられると、

> 攻撃者は通信の入口と出口を同時に観察し、長期にわたり network metadata を取得できる。

問題はもはや VPN leak ではありません。

ではなく、次の問題です。

\[
\boxed{
Traffic\ Correlation
+
Entity\ Resolution
+
Longitudinal\ Attribution
}
\]

これこそ現在の low-latency anonymity systems の中心的な制約です。

Tor 公式は現在も、communication channel の両端を同時観察する adversary に対し、timing/volume correlation を確実に防ぐ実用的な low-latency architecture は研究界で知られていないと明示的に認めています。

研究における実際に有効な強い防御、例えば Poisson mixing、cover traffic、constant-rate transmission、multi-user mixing は、ほぼすべて次を必要とします。

\[
Latency\uparrow
\]

または、

\[
Bandwidth\uparrow
\]

場合によっては communication semantics の変更さえ必要です。Loopix は典型例で、より強力な network observer に対して traffic-analysis resistance を提供しますが、message latency は秒単位になります。

したがって、今後本当に研究価値のある問いは、

> **「完全に追跡不能な VPN をどう作るか？」**

ではありません。その問い自体の定義が誤っているためです。

より適切な問いは、

> **「与えられた latency、bandwidth、infrastructure budget の下で、ingress と egress の mutual information をどこまで下げられるか？」**

つまり、次を研究することです。

\[
\boxed{
\min I(X;Y)
}
\]

制約条件：

\[
Latency\le L_{max}
\]

\[
BandwidthOverhead\le B_{max}
\]

これにより VPN、DAITA、Tor、I2P、Mixnet、traffic shaping、multi-user aggregation、将来の AI-driven traffic-defense を、同じ定量的な研究の枠組みに置けます。

---

## 主な研究資料

**プロトコル／実装**

- BitTorrent Enhancement Proposals：BEP-5 DHT、BEP-11 PEX、BEP-15 UDP Tracker。
- WireGuard Network Namespace Architecture。
- qBittorrent Anonymous Mode と VPN Interface Binding。
- I2P Threat Model。

**P2P 監視／VPN のセキュリティ**

- Le Blond et al., *Spying the World from Your Laptop*, USENIX LEET 2010。
- Piatek et al., *Why My Printer Received a DMCA Takedown Notice*, HotSec 2008。
- Xue et al., *Bypassing Tunnels*, USENIX Security 2023。

**匿名通信／トラフィック解析**

- Piotrowska et al., *The Loopix Anonymity System*, USENIX Security 2017。
- Das et al., *Comprehensive Anonymity Trilemma*, PoPETs 2020。
- Holland et al., *DeTorrent*, PoPETs 2024。
- Pulls et al., *Ephemeral Network-Layer Fingerprinting Defenses*, PoPETs 2026。

**現在の導入状況／Mullvad**

- Mullvad No-Logging Policy，2026。
- Mullvad Multihop。
- Mullvad DAITA / DAITA v2。
- Mullvad RAM-only VPN infrastructure。

**事例研究**

- CODA：2026 Nyaa First Uploader Arrest / JHA Analytical Tool。