You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a developer, in libp2p, I'd like to have more control over how much information the lookup protocol leaks and how the lookup peer 'candidate list' is populated. Instead of sending a GET_VALUE request to a peer - which conceals what content ID the initiator is looking for - I'd like to request the peer's full routing table and make the decision locally about how to populate the candidate list.
This changes the Kademlia protocol considerably (as in specs), so I'm thinking of building a simple protocol on top of the current overlay. The idea would to define the protocol /p3lib/rt/1.0.0 that would request the authenticated routing table of a destination peer (how to secure the routing table against bias and other active attacks is another topic to be covered separately).
Having this feature in place is a first step towards implementing a privacy preserving lookup which does not disclose the target ID to a local passive adversary that controls up to 10-20% of network nodes. This lookup protocol is still open to range estimation attacks [ref] when the adversary controls more than one of the peers used to resolve the final peer ID. That can be mitigated by using multiple query paths with dummy requests [ref]. Other protocols can be used to mitigate the range estimation attacks, but the above mentioned mechanism is always a requirement for any DHT lookup protocol that does not leak information about the initiator's interests to local, passive adversaries.
The text was updated successfully, but these errors were encountered:
As a developer, in libp2p, I'd like to have more control over how much information the lookup protocol leaks and how the lookup peer 'candidate list' is populated. Instead of sending a GET_VALUE request to a peer - which conceals what content ID the initiator is looking for - I'd like to request the peer's full routing table and make the decision locally about how to populate the candidate list.
This changes the Kademlia protocol considerably (as in specs), so I'm thinking of building a simple protocol on top of the current overlay. The idea would to define the protocol /p3lib/rt/1.0.0 that would request the authenticated routing table of a destination peer (how to secure the routing table against bias and other active attacks is another topic to be covered separately).
Having this feature in place is a first step towards implementing a privacy preserving lookup which does not disclose the target ID to a local passive adversary that controls up to 10-20% of network nodes. This lookup protocol is still open to range estimation attacks [ref] when the adversary controls more than one of the peers used to resolve the final peer ID. That can be mitigated by using multiple query paths with dummy requests [ref]. Other protocols can be used to mitigate the range estimation attacks, but the above mentioned mechanism is always a requirement for any DHT lookup protocol that does not leak information about the initiator's interests to local, passive adversaries.
The text was updated successfully, but these errors were encountered: