Technical Summary: Deanonymizing Monero Transactions in the Tor Network

Problem Statement

Monero is a privacy-focused cryptocurrency that employs the Dandelion++ protocol and anonymity networks (Tor and I2P) to obscure the source IP addresses of transactions. While Dandelion++ separates transaction propagation into "stem" (forwarding to a single neighbor) and "fluff" (broadcasting to all neighbors) phases, and Tor encrypts traffic to hide IP addresses, this paper identifies a fundamental vulnerability in the interaction between Monero's P2P logic and Tor's connection model.

The core problem is that Monero treats "public peers" and "hidden service peers" differently. Specifically, transactions originated by a Monero node over Tor are exclusively forwarded to two outgoing Tor hidden service nodes (proxy nodes) before entering the clearnet. In contrast, relayed transactions are forwarded directly to clearnet neighbors. This creates a protocol-level leakage: if an adversary can occupy these specific outgoing connections and become a proxy node, they can distinguish originated transactions from relayed ones. Furthermore, while the Tor network hides the IP address, it exposes role-dependent identifiers (onion addresses for hidden services, connection-specific IDs for clients) that can be linked to real IPs through traffic analysis.

Existing deanonymization methods for Bitcoin (e.g., analyzing diffusion paths or using address cookies) fail against Monero due to its unique Dandelion++ mechanism and the specific constraints of the Tor integration.

Methodology: ProxyMark

The authors propose ProxyMark, a three-stage deanonymization framework that exploits the Monero-over-Tor P2P behavior without breaking Tor encryption or Monero cryptography.

Stage 1: Node Role Identification

The framework first determines whether a target Tor peer is a Monero Tor Hidden Service Node or a Tor Client Node.

• Mechanism: The adversary probes incoming connections with Timed Sync Request messages.
• Leakage: Hidden service nodes deterministically append their own onion address as the last entry in Timed Sync Response messages sent to outgoing hidden service peers. Tor client nodes do not exhibit this behavior; their responses contain only previously unseen addresses.
• Outcome: By analyzing the last onion address in three consecutive responses, the adversary can classify the node role with 100% precision and extract the target's onion address if it is a hidden service.

Stage 2: Originated Transaction Identification

Once the role is known, the adversary aims to capture transactions originated by the target. This requires two sub-steps:

1. Outgoing Connection Occupation: The adversary populates the target's peer lists (graylist and whitelist) with malicious onion addresses.
   • For Hidden Services, the adversary directly injects addresses via Timed Sync Responses.
   • For Clients, the adversary indirectly populates client lists by first filling the lists of hidden service nodes, which then propagate the malicious addresses to clients.
   • When the target restarts or rotates connections, it selects from these populated lists, increasing the probability that the adversary controls the outgoing connections.
2. Proxy Selection Bias: Monero selects proxy nodes based on blockchain height. The adversary modifies its nodes to advertise falsified, fresher block heights (e.g., current height + 5) and increases the frequency of Timed Sync messages. This ensures that malicious peers are perceived as "fresher" and are preferentially selected as the two proxy nodes for the target's originated transactions.

Stage 3: Node Location Deanonymization

The final stage links the captured transaction (identified by the Tor-level identifier) to the target's real IP address.

• Mechanism: The adversary embeds a role-specific watermark into the timing of Monero P2P messages (specifically Timed Sync Request messages).
  • Hidden Services: The adversary injects the watermark on an incoming connection before the handshake is complete, avoiding protocol-induced noise (white noise and response obligations).
  • Clients: The adversary waits for the client to connect to a malicious node and embeds the watermark on the response path, using noise cancellation techniques to handle protocol traffic.
• Detection: A malicious Tor relay (acting as an entry guard) observes the timing patterns of the encrypted cells. By decoding the carrier message counts in specific time windows, the relay recovers the identifier and binds it to the observed source IP address.

Key Contributions

1. ProxyMark Framework: A novel three-stage pipeline (Role Identification, Transaction Capture, Location Deanonymization) specifically designed for Monero over Tor.
2. Protocol Exploitation: The paper demonstrates that Monero's distinction between public and hidden service peers creates a "choke point" for originated transactions, which can be exploited without breaking cryptographic primitives.
3. New Techniques:
   • Onion Address Analysis: A deterministic method to identify hidden service nodes and extract their addresses based on Timed Sync response structures.
   • Proxy Selection Bias: A method to manipulate block height perception to force the selection of adversarial proxy nodes.
   • Role-Specific Watermarking: A technique to embed identifiers into traffic timing, utilizing handshake-free injection for hidden services and noise cancellation for clients.
4. Empirical Validation: Experiments conducted on the live Tor network, Monero mainnet, and testnet.

Experimental Results

The authors evaluated ProxyMark across its three stages:

• Role Identification: Achieved 100% precision and recall in distinguishing hidden service nodes from client nodes and extracting onion addresses.
• Connection Occupation: Successfully occupied 7–11 of 12 outgoing hidden service connections after node restarts and 8–10 of 10 during periodic replacement cycles.
• Proxy Selection Bias: With just one occupied connection, the bias technique increased the proxy-selection rate from a baseline of 15.3% to 35.7% (a +20.4 percentage point gain).
• Node Location Deanonymization:
  • Hidden Service Nodes: 100% precision, 93.8% recall.
  • Tor Client Nodes: 100% precision, 91.4% recall.
  • The authors note that with repeated injection attempts, the probability of successfully deanonymizing a target with a single adversarial guard relay approaches 99.4% after 8 attempts.

Significance and Claims

The paper claims that Tor transport alone is insufficient to protect Monero users from network-layer deanonymization. The vulnerability stems from a mismatch between Monero's transaction forwarding logic (which treats hidden service connections as a protected layer for originated transactions) and Tor's connection model.

The authors emphasize that:

• The attack does not rely on breaking Tor encryption or Monero's cryptographic privacy features (ring signatures, stealth addresses).
• The attack is a practical feasibility result under specific adversarial capabilities (control of Monero peers and Tor entry relays), rather than a claim that all Monero-over-Tor transactions are automatically deanonymized.
• Effective mitigation requires joint hardening of Monero's P2P behavior and its Tor integration, rather than treating the anonymity network as a standalone shield.

The paper concludes by proposing protocol-level mitigations, such as removing the deterministic onion address in Timed Sync responses, extending Dandelion++ stem-phase forwarding to hidden service connections, and enforcing strict message rate limits to prevent watermarking.