# P2P Anonymity: Digital Investigations and End-to-End Traffic Correlation

# Research Report on P2P Anonymity, Digital Investigations, and End-to-End Traffic Correlation

**Version: 2026-08**
**Topics: BitTorrent / VPN / Mullvad / Tor / I2P / Traffic Correlation / Traffic Analysis Defense**

---

## Abstract

The core problem of modern online anonymity can no longer be reduced to “whether the real IP is hidden.” A fuller model must consider all of the following:

\[
\text{Network Identity}
+
\text{Protocol Metadata}
+
\text{Session Linkability}
+
\text{Temporal Correlation}
+
\text{Behavioral Fingerprint}
+
\text{Cross-Layer Identity}
+
\text{Endpoint Evidence}
\]

The goal of an anonymity system can be formalized as maximizing:

\[
H(U\mid O)
\]

Here \(U\) is the real user and \(O\) is all observations available to the attacker: maximizing the uncertainty about identity remaining after observing network, timing, account, device, protocol, and other information.

Investigators, conversely, seek to use:

\[
O_1+O_2+\cdots+O_n
\rightarrow
\text{Entity Resolution}
\rightarrow
\text{Attribution}
\]

to make:

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

Thus modern investigations usually do not directly “break a VPN” or “break WireGuard”; they gradually narrow the candidate set through **metadata correlation, timeline analysis, graph correlation, traffic analysis, account records, endpoint forensics, and multi-source evidence fusion**.

The core conclusion of this report is:

> **VPNs excel at breaking the direct link “residential IP → Internet activity,” but do not automatically provide activity unlinkability, traffic-analysis resistance, or long-term anonymity.**

Against a powerful attacker who can observe both ends of low-latency communication, there is still no practical general solution combining **low latency, low bandwidth overhead, and strong anonymity**. Tor's official documentation still explicitly acknowledges this limitation; the Anonymity Trilemma in anonymous-communication research further formalizes the underlying trade-off.

---

# 1. The basic anonymity problem in P2P

## 1.1 BitTorrent is inherently not an anonymity protocol

BitTorrent's primary goal is:

> Efficiently finding other peers and exchanging data.

Not:

> Hiding who is participating in a swarm.

BitTorrent therefore natively has several observable surfaces:

```text
                  ┌── Tracker
                  │
BitTorrent Client ├── DHT
                  │
                  ├── PEX
                  │
                  ├── Peers
                  │
                  └── Local Peer Discovery
```

A standard UDP tracker announce can include:

- `info_hash`
- `peer_id`
- `downloaded`
- `left`
- `uploaded`
- `event`
- listening port

The tracker can also naturally see the source network endpoint.

A tracker can therefore readily form:

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

Or even:

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

This is normal BitTorrent protocol design, not a vulnerability.

---

# 2. Exposure surfaces of DHT and PEX

BitTorrent DHT (BEP-5) is a distributed peer-discovery system.

One of its core operations:

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

obtains peer contact information for a torrent; `announce_peer` announces participation in that torrent to the DHT.

BEP-5 also requires the token used by `announce_peer` to be bound to the querying source IP. The queried node ultimately stores that source IP and port under the corresponding infohash.

DHT can therefore be understood as:

> **A distributed `infohash → peer endpoint` discovery database.**

PEX exchanges other peers' information among peers with established BitTorrent connections, forming another peer-discovery surface.

Thus:

```text
DHT OFF
PEX OFF
```

can reduce the public discovery surface, but does not make it anonymous:

```text
Tracker → can still see the endpoint
Peers   → can still see the endpoint
```

The primary determinant of “whether the residential IP is exposed” remains the network routing boundary.

---

# 3. Large-scale P2P monitoring is no longer theoretical

**Spying the World from Your Laptop**, presented at USENIX LEET 2010, demonstrated that a single machine and BitTorrent's public infrastructure could build large-scale, long-term mappings between users and torrent activity.

Over 103 days, the study collected approximately:

- 148 million IPs
- Roughly 2 billion content-copy observations

It also reported inferring the initial content providers for many newly observed torrents.

An important study also points in the opposite direction.

At HotSec 2008:

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

showed that relying solely on IP information returned by trackers can cause false attribution, even leading to infringement notices for devices that never actually exchanged data.

Forensic evidence must therefore distinguish:

\[
IP\ listed\ by\ tracker
\]

from:

\[
IP\ actually\ exchanged\ verified\ content
\]

These have different evidentiary strength.

---

# 4. Anonymity should be separated into distinct Security Properties

“Anonymous” is not a single Boolean.

A more complete model can be written as:

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

## 4.1 Real-IP Confidentiality

The aim is:

```text
Tracker
Peer
DHT
Website
```

cannot see the residential / company WAN IP.

This is the layer VPNs address best.

---

## 4.2 Identity Anonymity

Even if an activity is visible, the observer does not know:

```text
Activity X
    ↓
Who?
```

---

## 4.3 Activity Unlinkability

Even when there are:

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

it should not be easy to determine:

\[
A=B=C=D=\text{same actor}
\]

This is stronger than IP hiding alone.

---

## 4.4 Cross-Layer Unlinkability

Prevent:

```text
Browser Identity
      │
      ├── Website account
      │
P2P Identity
      │
      └── Tracker/DHT
```

from being proven to belong to the same entity.

---

## 4.5 Fingerprint Minimization

Reduce:

```text
client version
peer ID pattern
User-Agent
protocol extensions
OS/application behavior
```

and other software fingerprints.

qBittorrent's Anonymous Mode mainly belongs to this category. Its official documentation explicitly says that it does not provide strong anonymity by itself, but reduces the identifying information exposed by the BitTorrent client.

---

## 4.6 Timing / Traffic-Analysis Resistance

The aim is for the entry:

\[
X(t)
\]

and the exit:

\[
Y(t)
\]

to be difficult to identify as the same communication.

This is one of the hardest problems for Tor, VPNs, and most low-latency anonymity systems.

---

## 4.7 Longitudinal Anonymity

Anonymity is not only about:

> Whether one activity leaked information.

It is also about:

> After hundreds or thousands of activities, do historical observations gradually reveal the identity?

The real subject of study is therefore:

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

not just a single session.

---

# 5. The modern investigator's model

Modern digital investigations can be abstracted as:

```text
                 Observable Event
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     Network        Service        Endpoint
     Evidence       Evidence       Evidence
        │              │              │
        ├──────────────┼──────────────┤
                       ▼
                    Timeline
                       │
                       ▼
                Entity Resolution
                       │
                       ▼
                Candidate Ranking
                       │
                       ▼
                 Corroboration
                       │
                       ▼
                   Attribution
```

Investigators do not necessarily need one decisive piece of evidence.

More commonly:

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

all support the same hypothesis.

---

# 6. Graph-based Attribution Model

This problem is well suited to a model of:

\[
G=(V,E)
\]

Nodes may include:

```text
Person
Account
Device
IP
VPN Exit
Session
Browser
Torrent
Infohash
Tracker Event
Server
Payment
Email
Timestamp
```

Edges may include:

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

The essence of investigation is to start with many disconnected components:

```text
A        B        C
```

and gradually find credible cross-component edges:

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

ultimately forming an entity cluster.

---

# 7. Bayesian Attribution

Assume:

\[
H_A=\text{Alice is the operator of Activity X}
\]

Given evidence:

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

continually update:

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

This aptly describes how many weak signals gradually build strong attribution.

In practice, however, one cannot simply assume:

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

Many pieces of evidence share common causes or come from the same observation source.

Otherwise, **double counting evidence** is likely.

---

# 8. Intersection Attack

Another important anonymity model is the intersection of candidate sets.

Assume:

\[
S_0
\]

is the set of all possible users.

Online at the first event:

\[
S_1
\]

At the second:

\[
S_2
\]

Continuing:

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

may yield:

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

I2P's own threat model explicitly includes timing, intersection, predecessor, Sybil, and traffic analysis among anonymity attacks that must be considered.

Thus:

> **Long-term, repeated, regular anonymous activity is itself an accumulation of risk.**

---

# 9. The first line of P2P defense: Network Isolation

If the security requirement is only:

> **BitTorrent's real residential IP must never reach a tracker, DHT, or swarm.**

The most reliable engineering security invariant should be:

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

And:

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

That is, **fail closed**.

---

# 10. VPN + Application Binding

qBittorrent can bind itself to a designated VPN network interface.

Official documentation explicitly describes this as an extra leak-prevention layer beyond the VPN kill switch: when the VPN interface does not exist, qBittorrent should not switch to an ordinary physical interface.

Typical:

```text
eth0 = physical WAN
wg0  = VPN

qBittorrent
     │
     └── bind wg0
```

---

# 11. Firewall Fail-Closed

Going further:

\[
P2P\ process
\land
oif\neq wg0
\Rightarrow DROP
\]

In other words:

```text
               ┌── wg0  → ALLOW
qBittorrent ───┤
               └── eth0 → DROP
```

This can protect against:

- VPN daemon crash
- routing mistake
- reconnect
- interface changes

and similar failure scenarios.

---

# 12. Network Namespace

A stronger architecture is:

```text
Physical Namespace
│
└── eth0 / wlan0
        │
        └── encrypted WireGuard socket


P2P Namespace
│
├── qBittorrent
└── wg0
```

The P2P namespace has no:

```text
eth0
wlan0
```

Thus, even if the VPN route disappears, there is no ordinary WAN fallback path.

WireGuard's official documentation directly demonstrates this model: a container / network namespace can contain only `wg0`, so its only available Internet route is WireGuard.

Compared with relying solely on:

```text
default route → VPN
```

this makes a kernel-level security invariant easier to establish.

---

# 13. Why routing-only VPNs are less than ideal

**Bypassing Tunnels**, presented at USENIX Security 2023, showed that many VPN clients base their security boundaries on routing-table manipulation, and routing exceptions can become a traffic-leak attack surface. The researchers successfully demonstrated routing-based VPN bypasses across multiple platforms and VPN clients.

TunnelVision / CVE-2024-3661 further demonstrated injecting more-specific routes through DHCP Option 121 to bypass tunnels for some VPN traffic; the researchers also listed Linux network namespaces as a strong mitigation.

Thus:

```text
VPN connected = true
```

does not necessarily imply:

```text
∀ traffic → VPN
```

---

# 14. IPv6, DNS, and other bypasses

P2P isolation must address all of:

\[
IPv4
\]

from:

\[
IPv6
\]

Otherwise, this may occur:

```text
IPv4 → VPN
IPv6 → physical WAN
```

DNS should also be within the same network boundary.

A DNS leak does not usually mean the ISP automatically knows the torrent `infohash`, but may expose:

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

and other service-level information.

---

# 15. Seedbox

A seedbox changes the network location:

```text
Home
 │ HTTPS/SSH
 ▼
Seedbox
 │
 ▼
BitTorrent Swarm
```

Thus:

\[
ResidentialIP\notin Swarm
\]

But:

```text
Swarm → Seedbox IP
```

still exist.

A seedbox therefore provides:

> **network-location separation**

Not:

> perfect anonymity。

The trust boundary merely moves from:

```text
VPN provider
```

to:

```text
hosting / seedbox provider
```

---

# 16. Tor and P2P

Tor is a low-latency anonymous communication network. Its main security idea is to prevent one relay from knowing both:

```text
User
+
Destination
```

However, Tor's official documentation explicitly states:

> If an attacker can observe both ends of a communication channel, no practical low-latency system currently reliably prevents correlation using timing and volume.

Tor's primary strategy is therefore not to eliminate correlation, but to:

> Reduce the likelihood that an attacker simultaneously obtains observation positions at both ends.

---

# 17. I2P

I2P's BitTorrent model differs from ordinary clearnet BitTorrent.

Its anonymous identity does not directly use clearnet:

```text
IP:port
```

as the application peer identity, instead using Destinations and tunnel infrastructure in the I2P overlay.

This therefore is:

> **protocol-level anonymous P2P overlay**

Not:

> clearnet BitTorrent + VPN。

Still, I2P itself explicitly acknowledges timing, intersection, traffic analysis, and related attacks as part of its threat model.

---

# 18. The Nyaa / CODA / JHA case

In July 2026, Kyoto Prefectural Police in Japan arrested a man suspected of sharing NHK and other content as a Nyaa first uploader.

CODA officially confirmed:

- CODA investigated Nyaa under the METI-supported CBEP program;
- The Japan Hacker Association developed an analytical tool;
- CODA used the tool to obtain information related to the suspect;
- Kyoto Prefectural Police investigated further based on that information and identified the suspect.

However, the official sources **have not disclosed the tool's algorithm**.

Therefore:

```text
CDN logs
Cookies
Login history
VPN logs
```

and similar specific methods cannot be treated as confirmed facts.

More plausible technical hypotheses include:

```text
Index metadata
        +
Tracker metadata
        +
Temporal correlation
        +
Historical observations
        ↓
Candidate identification
```

But these remain inferences.

---

# 19. Mullvad's anonymity model

Mullvad is a privacy-oriented VPN, not a complete anonymous communication network.

It primarily addresses the direct link:

\[
ResidentialIP
\rightarrow
InternetActivity
\]

.

Its main mechanisms include:

- shared VPN exit
- numbered account
- no activity logs
- Multihop
- DAITA
- RAM-only server infrastructure

---

# 20. Mullvad No-Log

As of 2026, Mullvad's official policy states that it does not permanently retain:

- traffic
- DNS requests
- connection timestamps
- disconnect timestamps
- session duration
- IP addresses
- user bandwidth

Live state needed for connection validation is handled in temporary memory rather than retained permanently.

Mullvad thus seeks to avoid creating a retrospective connection table of:

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

.

---

# 21. Numbered accounts and payments

Mullvad does not require a traditional email / password identity.

Payment itself may nevertheless create another attribution surface.

For example, some payment methods have records of:

```text
Payment
   ↓
Mullvad account
```

, and the official data policy explicitly describes retention for each payment method.

So:

\[
Person\rightarrow Account
\]

can sometimes be established.

Without connection logs, however:

\[
Account
\rightarrow
ExitIP@time
\]

still lacks a direct historical mapping.

---

# 22. Mullvad RAM-only Infrastructure

In 2023, Mullvad announced completion of its VPN infrastructure's RAM-only migration. VPN servers no longer relied on ordinary persistent disks for operation; its infrastructure audit also examined this architecture.

Its security significance is reducing the risk of residual data from:

```text
server seizure
   ↓
historical disk artifacts
```

.

But RAM-only:

\[
\neq
\]

“no attacker can observe traffic in real time.”

---

# 23. Mullvad Multihop

Ordinary VPN:

```text
User
 │
 ▼
VPN
 │
 ▼
Destination
```

Multihop：

```text
User
 │
 ▼
Entry VPN
 │
 ▼
Exit VPN
 │
 ▼
Destination
```

Mullvad officially states that one purpose of multihop is to make incoming / outgoing traffic correlation harder by distributing observation positions across different servers, locations, and providers.

This is still not Tor-style trust distribution among multiple operators.

---

# 24. DAITA

DAITA：

**Defense Against AI-guided Traffic Analysis**

is primarily about changing the observable shape of encrypted traffic, rather than increasing cryptographic strength.

Mullvad officially lists these main techniques:

- random background / dummy traffic
- constant packet-size style padding
- traffic pattern distortion
- dynamic per-connection configurations

DAITA v2 further reduces dummy-traffic overhead and gives different connections different tunnel-traffic characteristics.

Its main targets are therefore:

\[
TrafficFingerprint
\]

and:

\[
TrafficCorrelationSignal
\]

Not:

\[
AES/WireGuardCryptography
\]

---

# 25. End-to-End Traffic Correlation

This is the report's most important technical problem.

Assume an ingress observation:

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

Where:

- \(t_i\)：timestamp
- \(s_i\)：packet size
- \(d_i\)：direction

At the exit:

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

The attacker must solve:

\[
Match(X,Y)?
\]

That is:

> Which exit flow corresponds to the same communication as ingress flow X?

---

# 26. Encryption cannot hide all metadata

Even if:

\[
C=Enc_K(M)
\]

the attacker may still see:

```text
packet timing
packet count
packet size
direction
burst structure
idle intervals
flow duration
total volume
```

Thus:

\[
Encryption\neq Traffic\ Unobservability
\]

This is also why Tor officially acknowledges the end-to-end correlation threat.

---

# 27. The most basic correlation attack

Divide time into windows:

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

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

Then calculate lagged correlation:

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

If:

```text
Candidate A = 0.17
Candidate B = 0.10
Candidate C = 0.91
Candidate D = 0.05
```

C is clearly worth further analysis.

An actual modern classifier can of course use more complex feature representations, but the core information sources remain:

\[
Timing+Volume+Direction
\]

---

# 28. Data conservation is the core problem

Define cumulative bytes:

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

A low-latency proxy must transfer ingress data to egress almost immediately.

Thus, generally:

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

Here \(\delta\) is network delay.

Real data cannot appear at egress before it has arrived at ingress.

Low-latency forwarding therefore creates a causality constraint in itself.

---

# 29. The mutual-information model

An ideal anonymity system aims for:

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

In other words:

> Knowing ingress traffic provides almost no additional information for inferring egress traffic.

Ordinary VPN / Tor can, however, be abstracted as:

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

Where:

- \(T\)：relay/network transformation
- \(N\)：jitter、congestion、packetization noise

Usually:

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

and it may be quite high.

---

# 30. False positives and base rates

Traffic-correlation papers must look beyond:

\[
TPR
\]

They must also consider:

\[
FPR
\]

Assume:

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

With:

\[
10^7
\]

candidate comparisons, there may still be:

\[
10^4
\]

false positives。

Thus:

> targeted hypothesis confirmation

from:

> Internet-scale identification

are very different problems.

---

# 31. Passive and active correlation

### Passive

Only observes:

```text
Ingress
Egress
```

then performs statistical matching.

### Active

The attacker can inject into the flow:

```text
delay
drop
rate perturbation
```

to create a distinctive temporal pattern, then observe whether a corresponding pattern appears on the other side.

Active attacks are generally stronger than purely passive observation.

---

# 32. Anonymity Trilemma

A fundamental trade-off in anonymous communication can be written as:

### Strong anonymity

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

### Low latency

\[
L\rightarrow0
\]

### Low bandwidth overhead

\[
B_{dummy}\rightarrow0
\]

Research shows that anonymous communication systems cannot simultaneously achieve:

> strong anonymity + low latency overhead + low bandwidth overhead。

The Comprehensive Anonymity Trilemma at PoPETs 2020 extends the impossibility result to a broader class of anonymity systems that includes user coordination.

This means the problem is not simply:

> “A good enough padding algorithm has not yet been invented.”

There are more fundamental limitations.

---

# 33. Why does the trilemma arise?

Assume the user is currently idle.

If the system does not want an observer to determine:

```text
User is idle
```

it must continuously send:

\[
DummyTraffic>0
\]

Thus:

\[
BandwidthOverhead\uparrow
\]

Conversely, Alice suddenly generates substantial traffic.

To keep output from immediately reflecting the burst:

### Method A

Delay the data:

\[
Latency\uparrow
\]

### Method B

Send large amounts of cover traffic routinely:

\[
Bandwidth\uparrow
\]

So:

\[
StrongPrivacy
\]

Some resource must inevitably be consumed.

---

# 34. Defense 1：Constant-Rate Shaping

One of the strongest but most expensive methods:

\[
R(t)=R_0
\]

Whether or not real traffic exists:

```text
REAL
DUMMY
DUMMY
REAL
DUMMY
```

The observer always sees:

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

It can substantially hide:

- burst timing
- packet count
- volume shape
- idle periods

However:

When:

\[
R_{real}<R_0
\]

then:

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

When:

\[
R_{real}>R_0
\]

the queue becomes:

\[
Q(t)\uparrow
\]

which then leads to:

\[
Latency\uparrow
\]

This is the most intuitive embodiment of the Anonymity Trilemma.

---

# 35. Defense 2：Adaptive Padding

A more practical approach is:

\[
X'=X+N
\]

Here \(N\) is selective dummy traffic.

Instead of a permanent constant rate, add cover only to traffic patterns carrying high fingerprint information.

Advantages:

- Almost no increase in latency
- Controllable bandwidth overhead
- Deployable on existing VPN / Tor systems

Disadvantages:

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

generally still holds.

---

# 36. DeTorrent

DeTorrent, published at PoPETs 2024, uses competing neural networks to automatically design padding-only defenses.

Defender：

\[
D_\theta(X)
\]

Attacker：

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

This forms a kind of adversarial optimization:

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

Its flow-correlation evaluation shows a substantial reduction in attack TPR at a very low FPR operating point, without delaying real traffic.

Its value is that:

> Padding policies are no longer designed entirely by manual heuristics.

---

# 37. Defense 3：Ephemeral Defenses

A fixed defense can itself become a fingerprint.

For example, if every user uses:

```text
padding distribution = θ
```

the attacker can learn:

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

**Ephemeral Network-Layer Fingerprinting Defenses**, at PoPETs 2026, proposes:

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

Give every connection a different traffic-defense configuration.

The study integrated its method with WireGuard and reported actual deployment in Mullvad's environment serving many daily users.

Mullvad DAITA v2's dynamic configurations follow a similar direction.

---

# 38. Defense 4：Mixing + Delay

A more fundamental approach than padding:

```text
A ─┐
B ─┼─► MIX
C ─┤
D ─┘
      │
      ├── delay
      ├── reorder
      └── cover traffic
```

to make:

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

This actually breaks input / output timing dependency.

---

# 39. Loopix

Loopix is representative of this approach.

It uses:

- Poisson mixing
- random delays
- cover traffic
- loop messages

and provides traffic-analysis resistance under a threat model that includes a global network adversary.

The cost is overall message latency on the order of **seconds**, even though this is relatively low for a mixnet.

It is therefore better suited to:

```text
messaging
async communication
mail-like systems
```

Not:

```text
gaming
SSH
remote desktop
interactive low-latency web
```

---

# 40. Defense 5：Multi-user Aggregation

Another important direction is not adding fake traffic, but:

> Using other users' real traffic as one's own cover traffic.

For example:

```text
Alice ─┐
Bob ───┤
Carol ─┼── Aggregator/Mixer
Dave ──┤
Eve ───┘
```

Inputs:

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

together form:

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

Investigators no longer need only solve:

\[
X_A\leftrightarrow Y_A
\]

but must solve a permutation / assignment problem.

This can increase:

\[
H(Y\mid X)
\]

without requiring all cover traffic to consist of dummy bytes.

---

# 41. Defense 6：Traffic Splitting

Take one flow:

\[
X
\]

and split it into:

\[
X_1,X_2,X_3
\]

across different paths:

```text
             ┌── Path A
Traffic ─────┼── Path B
             └── Path C
```

If the adversary can observe only some paths:

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

correlation can be effectively reduced.

For a truly global observer, however:

\[
X_1+X_2+X_3
\]

may still be reaggregated.

The main advantage of multipath is therefore:

> Increasing the cost for partial observers.

---

# 42. Defense 7：Egress Transformation

Traditional padding mainly modifies:

```text
Ingress shape
```

But exit connection topology may still remain:

\[
1\ ingress\ flow
\leftrightarrow
1\ egress\ flow
\]

More radical designs can:

```text
Real Flow
   ↓
split / shuffle
   ↓
Virtual Flow A
Virtual Flow B
Virtual Flow C
```

directly breaking:

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

This is a direction more worth researching than packet padding alone.

---

# 43. A new architecture I consider worth researching

Combining current research, we can propose:

# Bounded-Latency Multi-Flow Mixing Network

Architecture:

```text
Users

A ─┐
B ─┤
C ─┤
D ─┼── Entry Aggregator
E ─┤
F ─┘
          │
          ▼
   Ephemeral Shaper
          │
          ▼
   Bounded-Delay Mixer
          │
     ┌────┼────┐
     ▼    ▼    ▼
   Path1 Path2 Path3
     │    │    │
     └────┼────┘
          ▼
      Egress Mixer
          │
          ▼
 split / shuffle / merge
          │
          ▼
     Destinations
```

The goal is not to achieve perfect anonymity, but, under:

\[
Latency<L_{max}
\]

\[
Bandwidth<B_{max}
\]

these conditions, to minimize:

\[
I(X;Y)
\]

---

# 44. Layer 1：Ephemeral Shaping

For each flow:

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

randomly choose:

- padding schedule
- dummy distribution
- packet-size policy
- burst behavior

Avoid creating a fixed defense fingerprint.

---

# 45. Layer 2：Bounded Random Delay

For each packet / message:

\[
D_i\sim P_D
\]

But:

\[
D_i<D_{max}
\]

For example, different application classes:

```text
Gaming       → very small Dmax
Web          → small Dmax
Streaming    → moderate Dmax
Messaging    → large Dmax
```

This makes the privacy policy QoS-aware.

---

# 46. Layer 3：Multi-user Mixing

Use an aggregation queue:

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

reschedule:

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

Break one-to-one timing mappings within the latency budget.

---

# 47. Layer 4：Real Traffic as Cover

Assume the queue already contains:

\[
X_A,X_B,X_C
\]

prioritize using:

\[
X_B,X_C
\]

as A's anonymity cover.

Only when the anonymity deficit is too high:

\[
inject\ dummy
\]

This may substantially reduce:

\[
DummyBandwidth
\]

---

# 48. Layer 5：Egress Flow Transformation

At output, also perform:

```text
merge
split
shuffle
connection migration
```

Reduce:

\[
IngressTopology
\leftrightarrow
EgressTopology
\]

its identifiability.

---

# 49. Adaptive Privacy Controller

The most valuable use of machine learning is not simply “random padding,” but constrained optimization:

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

subject to：

\[
Latency<L_{QoS}
\]

\[
Bandwidth<B_{budget}
\]

Where:

\[
L_{privacy}
\]

can be jointly approximated by:

- attack ROC
- contrastive matching accuracy
- estimated mutual information
- anonymity-set entropy

.

---

# 50. Defender–Attacker Adversarial Training

Defender：

\[
D_\theta(X)
\]

Outputs a defended trace.

Attacker：

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

Outputs:

\[
P(match)
\]

The research problem can be written as:

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

Also include:

\[
L_{latency}
\]

and:

\[
L_{bandwidth}
\]

regularization / constraints。

The action space should include more than padding, potentially including:

```text
padding
delay
burst shaping
multiplexing
splitting
reordering
connection migration
```

---

# 51. Classification accuracy should not be the sole security metric

For example:

```text
Attack Accuracy:
90% → 20%
```

does not directly prove security.

Because:

> It may merely overfit to one fixed attacker architecture.

A fuller evaluation should include:

\[
TPR
\]

\[
FPR
\]

\[
ROC
\]

\[
Precision
\]

\[
Recall
\]

and candidate population size.

---

# 52. Mutual information is a more worthwhile direction

What we truly want to reduce is:

\[
I(X;Y)
\]

Or increase:

\[
H(X\mid Y)
\]

Ideally:

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

Different ingress flows become increasingly indistinguishable to an observer.

Compared with:

> “Lowering the accuracy of one CNN”

this is closer to an actual security property.

---

# 53. P2P Privacy Lab

For research, use only lawful data:

```text
random test files
Linux ISO
self-generated datasets
```

Set up:

```text
Client VM
   │
   ▼
VPN
   │
   ├── Tracker VM
   ├── Peer VM
   └── Observer VM
```

and capture traffic at each observation point in:

```text
Ingress
VPN interface
Physical NIC
Tracker
Peer
```

.

---

# 54. Network Isolation Fault Injection

Test:

```text
VPN disconnect
VPN server unreachable
route mutation
IPv6 activation
DNS change
Wi-Fi ↔ Ethernet handover
suspend/resume
reboot
client starts before VPN
VPN reconnect
```

Core acceptance criterion:

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

---

# 55. Traffic-Correlation Lab

Then establish:

```text
Ingress capture:
X

Egress candidates:
Y1
Y2
...
Yn
```

Compare:

### Baseline

```text
WireGuard
```

### Defense A

```text
WireGuard + padding
```

### Defense B

```text
DAITA-like ephemeral shaping
```

### Defense C

```text
bounded delay
```

### Defense D

```text
multi-user aggregation
```

### Defense E

```text
aggregation + shaping + egress transform
```

---

# 56. Recommended core metrics

### Correlation

\[
Corr(X,Y)
\]

### Mutual Information

\[
I(X;Y)
\]

### Attack ROC

\[
TPR(FPR)
\]

Pay particular attention to:

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

\[
10^{-4}
\]

\[
10^{-5}
\]

and other genuinely attribution-sensitive operating regions.

### Latency

\[
P50,P95,P99
\]

### Bandwidth overhead

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

### Anonymity Set

\[
|S|
\]

Or entropy:

\[
H(U\mid O)
\]

---

# 57. Comparison of defensive capabilities

| Architecture | Real-IP protection | Activity unlinkability | Timing resistance | Latency | Bandwidth cost |
|---|---:|---:|---:|---:|---:|
| BitTorrent encryption | Low | Low | Low | Very low | Very low |
| qBittorrent Anonymous Mode | Low | Low | Low | Very low | Very low |
| VPN | High | Low | Low | Low | Low |
| VPN + bind + firewall | Very high | Low | Low | Low | Low |
| VPN + network namespace | Extremely high | Low | Low | Low | Low |
| Seedbox | Extremely high | Low–medium | Low | Low | Medium |
| Mullvad + Multihop | Extremely high | Medium | Medium–low | Low–medium | Low |
| Mullvad + DAITA | Extremely high | Medium | Medium | Low | Medium |
| Constant-rate shaping | High | Medium–high | High | Medium | Very high |
| Multi-path | High | Medium | Medium | Low–medium | Medium |
| Bounded multi-user mixing | High | High potential | High potential | Medium | Medium |
| Loopix / Mixnet | High | High | High | Seconds | Medium–high |
| I2P-native | High | Higher than clearnet VPN | Medium–high | Medium | Medium |

This table is a relative threat-model-level analysis, not a unified benchmark.

---

# 58. The most important security boundary

The entire problem can be divided into two layers.

## Layer A：Network Deanonymization

Question:

\[
VPN\ Exit
\rightarrow
RealIP?
\]

Main defenses:

```text
VPN
routing isolation
firewall
network namespace
interface binding
```

---

## Layer B：Behavioral / Traffic Attribution

Question:

\[
Activity_A
+
Activity_B
+
Timing
+
Metadata
\rightarrow
SameActor?
\]

Main research areas:

```text
traffic-analysis resistance
mixing
padding
cover traffic
intersection resistance
cross-layer unlinkability
behavioral privacy
```

Perfectly handling the former:

\[
\nRightarrow
\]

the latter is automatically safe.

---

# 59. The right way to position Mullvad

Mullvad is particularly strong at:

\[
Network\ Identity\ Separation
\]

+

\[
Provider\ Data\ Minimization
\]

+

\[
Traffic\ Fingerprint\ Reduction
\]

In other words:

```text
Shared exit
No activity logs
Numbered account
Multihop
RAM-only
DAITA
```

But it is still:

> **low-latency VPN architecture**

Not:

> traffic-analysis-proof anonymous communication system。

Thus, even if DAITA:

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

it is not reasonable to assume:

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

---

# 60. Modern investigators actually look for the weakest edge

Assume:

```text
Cryptography       ██████████
VPN routing        ██████████
Real-IP isolation  ██████████
```

But:

```text
Application ID     █████
Timing             ████
Endpoint           ███
Account            ███
Operational error  ██
```

Then a powerful investigator has no reason to:

> Break WireGuard.

Instead, they will:

```text
pivot
```

to:

```text
account
device
time
behavior
provider
metadata
```

Thus:

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

Although not a formal security theorem, this aptly describes the practical attribution attack surface.

---

# 61. Core research conclusions

The study's most important concepts can be condensed into the following points.

### First

\[
Encryption\neq Anonymity
\]

### Second

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

### Third

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

### Fourth

\[
No\ Logs
\]

from:

\[
Strong\ Traffic\ Analysis\ Resistance
\]

are two different security properties.

### Fifth

The largest fundamental problem in low-latency anonymity is:

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

Attackers exploit this dependency.

### Sixth

True traffic-analysis defense aims to approach:

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

In other words:

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

### Seventh

But:

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

have a fundamental trade-off.

---

# 62. The directions most worth further research

If the research question is:

> **How can end-to-end traffic correlation be reduced as much as possible with minimal bandwidth overhead, within a latency budget that still permits interaction?**

I consider the most promising combination to be neither:

```text
More VPN hops
```

nor:

```text
More encryption
```

It is also about:

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

and use:

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

to establish a formal optimization objective.

---

# 63. Final conclusion

For ordinary P2P privacy:

\[
\boxed{
VPN
+
Interface\ Binding
+
Firewall
+
Network\ Namespace
}
\]

can already provide very strong protection against:

\[
RealIP\ Leakage
\]

WireGuard's official network-namespace architecture is particularly suitable as a fail-closed engineering boundary.

But if the threat model escalates to:

> An attacker can observe both the ingress and egress of communication and obtain network metadata over the long term.

the problem is no longer a VPN leak.

It is also about:

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

This is precisely the core limitation of current low-latency anonymity systems.

Tor's official documentation still explicitly acknowledges that, against an adversary observing both ends of a communication channel simultaneously, the research community knows no practical low-latency architecture that reliably prevents timing / volume correlation.

The genuinely effective strong defenses studied by researchers—such as Poisson mixing, cover traffic, constant-rate transmission, and multi-user mixing—nearly all require:

\[
Latency\uparrow
\]

Or:

\[
Bandwidth\uparrow
\]

or even changes to communication semantics. Loopix is a typical example: it provides traffic-analysis resistance against stronger network observers, but message latency reaches seconds.

Thus the question with real research value for the future is not:

> **“How do we build a completely untraceable VPN?”**

That question is itself ill-defined.

The better question is:

> **“Given latency, bandwidth, and infrastructure budgets, how low can we drive the mutual information between ingress and egress?”**

In other words, study:

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

subject to：

\[
Latency\le L_{max}
\]

\[
BandwidthOverhead\le B_{max}
\]

This places VPNs, DAITA, Tor, I2P, mixnets, traffic shaping, multi-user aggregation, and future AI-driven traffic defenses within one quantifiable research framework.

---

## Main research sources

**Protocol / Implementation**

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

**P2P Monitoring / VPN Security**

- 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。

**Anonymous Communication / Traffic Analysis**

- 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。

**Current Deployment / Mullvad**

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

**Case Study**

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