Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Distributed hash tables are powerful protocols that enable content discovering and routing in P2P networks. In "vanilla" DHT implementations (e.g. Kademlia), peer interactions leak a lot of information about who is in the network, who stores what files and who are the producers and consumers of content. This gives potential attackers a good picture of the network very easily and hinders anonymous and private interactions over P2P DHT overlay networks.
The desirable properties of a private and metadata resistant DHT are:
The main goal of this research thread is to survey and develop schemes that would improve DHT protocol's privacy without affecting performance and usability.
NOTE: this list is discontinued. check these and more papers' summaries at https://github.com/gpestana/p2psec/tree/master/research
Privacy preserving DHT use cases in the wild
Privacy and security in DHTs
Anonymity of lookup initiators and targets in DHTs follows and requires DHT security [a]. Security in DHTs is defined by the ability of malicious nodes to bias lookup requests. Being able to identify and ignore/kick out malicious nodes is important, in order for malicious nodes not to have the opportunity to attack other nodes by 1) poisoning routing tables and 2) answering to lookup requests with other malicious nodes.
notes on DHT threat model (for anonymity)
Privacy and security layering
There are two layers of security in DHT networks (and any other network/centralised system). The different layers have different privacy and security attack surface, targets and types of adversaries:
[a] Octopus: A Secure and Anonymous DHT Lookup
Anonymous neighbour surveillance and decentralised reputation system to prevent bias and routing table pollution attacks on DHTs
Reputation systems can be used as a mechanism to identify and signal malicious nodes in the network. A malicious node can manipulate the routing table before serving other nodes which ask for their routing table.
Routing table pollution and bias attack
Detecting lookup bias attacks, nodes keep a predessessor table which contains all the nodes that contains itself in their routing tables. With this table, node regularly anonymously requests the routing table of all nodes in its predecessor table. If their own IP is not in the table, then it can be assumed that the predecessor node is lying about the routing table and performing lookup bias attacks.
The lookup must be anonymous in order to ensure that the predecessor node cannot recognise whether it is a successor node requesting its routing table. Otherwise, the malicious node could respond accordingly.
For point 1), the algorithm can enforce that a routing table must be hashed and signed by the server node, so no node can tamper the results routing table contents and everyone can verify who generated and served the routing table (integrity and non-repudiation properties).
For 2) Question: how can a node prove that a given routing table is manipulated (e.g. by showing that its ID should be part of the routing table, but it is not)?
Metrics for evaluating reputation system:
[a] Octopus: A Secure and Anonymous DHT Lookup
Onion routing in DHTs
in-DHT Onion routing circuit construction
One possible vulnerability when using in-DHT onion routing is to construct the onion routing so that adversaries cannot learn what are the nodes selected as onion routers - or put it simply, which nodes are part of the onion routing circuit.
Ideas for securing onion circuit construction:
Optimal circuit length
since the probability of a malicious node to be selected for the circuit increases with the length of the circuit itself, it is more secure to chose the least amount of nodes possible that keep anonymity in onion routing. "less onion relays means less attack surface".
 Scalable Anonymous Communication with Provable Security
Group entropy for hiding lookup initiator identity [idea]
In order to create the entropy necessary to hide the lookup initiator in DHTs - similar to mixnets approach - build new groups of nodes which gossip lookup requests and responses within each other. Each node is responsible to forward the requests to other nodes outside the group and gossip back to the group. The lookup initiator will keep looking for when the final responses are returned and pick the best.
DHT group entropy for hiding lookup initiator: A lookup scheme to hide lookup initiator though gossip in small node groups. Conceptually, the idea is that small groups of nodes (maybe 50?) would communicate with each other through gossip, creating a self contained mix network. The message entropy within the group would hide who in the group initiated a particular request. So a node instead of communicate directly with peers in its finger table, it would first gossip the request to its group and all the group members would forward the request based on their finger tables. The lookup replies would also be gossiped within the group, so that the lookup initiator could pick the best responses.
This is a similar approach used by the anonymity system Crowds, which uses the concept of "blending into the crowd" (https://dl.acm.org/citation.cfm?id=290168)
Measuring anonymity / privacy in P2P networks
Measuring anonymity of systems is important to assess, compare and design anonymity of p2p systems. This thread contains research summaries, ideas and notes on how to measure anonymity/privacy in P2P systems and how to apply those measures to production systems.
[moved] check the notes and paper summaries at gpestana/p2psec#3