p2p: assign separate network keys to outbound onion connections #34456

1. 
   frankomosh commented at 6:30 am on January 30, 2026: contributor

   This PR is inspired by sipa’s suggestion in #33464 (comment).

   Outbound onion connections use distinct Tor circuits and appear unrelated externally. Sharing a network_id might allow correlation via addr caching behaviour (e.g., GetAddresses() responses), enabling an observer to link apparently distinct connections.

   Changes proposed here assign each outbound onion connection a unique, deterministic network_id based on its destination address.

   Unchanged:

   • Inbound onion connections continue grouping (already linked through the same hidden service)
   • Clearnet outbound connections continue grouping (already linked through the same source IP)
2. p2p: give each outbound onion connection a unique network_id

   Outbound onion connections appear distinct to external observers (different Tor circuits). Sharing a network_id might allow correlation of inv broadcast timing or addr response caching across apparently unrelated peers. Assign a deterministic network_id per onion destination to break that vector.

   72fd114d8c
3. test: add unit test for per-destination network keys on outbound onion connections

   Verifies that:
   - different onion destinations receive different keys
   - same destination receives same key (deterministic)
   - non-onion outbound remains grouped (no regression)

   c8eb2de639
4. DrahtBot added the label P2P on Jan 30, 2026
5. 
   DrahtBot commented at 6:30 am on January 30, 2026: contributor

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   Reviews

   See the guideline for information on the review process. A summary of reviews will appear here.

   LLM Linter (✨ experimental)

   Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

   • Lookup(“pg6mmjiyjmcrsslvykfwnntlaru7p5svn6y2ymmju6nubxndf4pscryd.onion”, 8333, false) in src/test/net_tests.cpp
   • Lookup(“7fa6xlti5joarlmkuhjaifa47ukgcwz6tfndgax45ocyn4rixm632jid.onion”, 8333, false) in src/test/net_tests.cpp

   2026-01-30 06:30:38

6. 
   ajtowns commented at 6:50 am on January 30, 2026: contributor

   Currently, all outbound onion connections share the same network_id, causing them to broadcast invs and respond to getaddr at correlated times.

   Broadcasting time for invs for outbounds shouldn’t be correlated? m_network_key is only used for inbound connections, outbounds get a random time: tx_relay->m_next_inv_send_time = current_time + m_rng.rand_exp_duration(OUTBOUND_INVENTORY_BROADCAST_INTERVAL);

7. 
   frankomosh commented at 11:09 am on January 30, 2026: contributor

   Broadcasting time for invs for outbounds shouldn’t be correlated? m_network_key is only used for inbound connections, outbounds get a random time: tx_relay->m_next_inv_send_time = current_time + m_rng.rand_exp_duration(OUTBOUND_INVENTORY_BROADCAST_INTERVAL);

   Thanks @ajtowns. I seemingly overstated the inv correlation part. I have updated the description to focus on addr caching.

8. 
   mzumsande commented at 11:20 am on January 30, 2026: contributor

   The motivation of #33464 was to make fingerprinting of identities from different network harder. But this doesn’t apply here, so I wonder what we are trying to prevent / what does an attacker gain from linking the connections?
9. 
   frankomosh commented at 12:47 pm on January 30, 2026: contributor

   The motivation of #33464 was to make fingerprinting of identities from different network harder. But this doesn’t apply here, so I wonder what we are trying to prevent / what does an attacker gain from linking the connections?

   This one focuses on intra-network linkability.

   A scenario: Attacker runs multiple onion sybil peers. When the same victim connects to 3 of them, all 3 connections would share the same m_network_key, thus the same addr cache bucket. For this reason, the attackers might observe identical response contents and timings, and this would be a strong signal these are the same node. (maybe after longer term behavioral analysis the attacker might deanonymize the victim here).

   Separation of network_ids would make each peer to have independent cache buckets, responses differs and therefore correlation becomes much harder.

10. 
    mzumsande commented at 2:01 am on January 31, 2026: contributor

    Addr caching also seems irrelevant because we ignore GETADDR requests from outbound peers - we only send getaddr answers to inbounds. So even if we decided to care about intra-network linkability, I think that this change doesn’t achieve anything.
11. 
    ajtowns commented at 11:57 pm on February 14, 2026: contributor

    Seems like this PR should be closed?
12. fanquake closed this on Feb 15, 2026

    ---

Contributors
frankomosh DrahtBot ajtowns mzumsande

Labels
P2P