DHT Corruption
Routing Poisoning
A routing poisoning attack corrupts the DHT by injecting fake routing entries. Unlike Sybil attacks that create real (if malicious) nodes, routing poisoning advertises entries pointing to non-existent peers, causing lookups to silently fail.
This is particularly insidious because the attack degrades gradually — peers don't crash, they just become increasingly unable to find content.
Healthy Routing Table
Each peer maintains a Kademlia routing table with k-buckets indexed by XOR distance. Lookups route through O(log n) hops, each hop getting closer to the target key. All routing entries point to real, honest peers.
Poisoner Joins Network
The attacker joins the network as a normal peer but begins generating fake routing entries — random Peer IDs with fabricated addresses (/ip4/10.0.x.x/tcp/4001). These entries look valid but point to non-existent nodes.
Fake Entries Propagate
The poisoner responds to FIND_NODE queries with fake peer entries mixed in with real ones. Honest peers add these entries to their routing tables, unknowingly contaminating their k-buckets. The fake entries spread as peers share routing information.
Lookup Degradation
With ~40% of routing entries poisoned, DHT lookups frequently route to non-existent peers. Lookup latency spikes as peers timeout waiting for responses from fake addresses. Content resolution fails for many queries — the attacker achieves denial of service without flooding.
Defense: Record Validation
py-libp2p defends against routing poisoning through: (1) Provider record validation — verifies entries before adding to routing table; (2) Connection probing — attempts to connect before trusting a routing entry; (3) Reputation tracking — peers that provide stale entries get deprioritized. Combined with S/Kademlia's disjoint path lookups, poisoning effectiveness drops significantly.
Technical Details
Poisoning Impact Formula
The lookup success probability degrades linearly with the ratio of poisoned entries in the DHT buckets.