computational puzzles and sybil defenses

1. Computational Puzzles and Sybil Defenses Nikita Borisov University of Illinois at Urbana-Champaign

3. Motivation (mine) I build p2p anonymous networks Anonymity requires decentralized trust Chains of forwarders with diverse interests Must compromise every link in the chain Sybil attacks reduce diversity Arbitrary fraction of peers may be compromised

4. Motivation (yours) Centralized admission control is� Expensive Error-prone Dangerous E.g. denial of service attacks may be aimed at the centralized admission control Do we have another option?

5. Threat Model Attackers are limited to running peers in the network But arbitrarily many Attacker may try to: Flood network with requests Disrupt request routing Violate anonymity Selectively deny service

6. DoS in DHTs Distributed hash table: Key space partitioned among nodes Regular graph structure Efficient lookup algorithms Attacks on key space partitioning Occupy large sections of key space Occupy key space around result to perform selective DoS

7. DHT Security Castro et al: use certificates to partition key space Verify key assignment using signatures Density estimation to stop selective DoS Path diversity to route around malicious nodes Our approach: use puzzles to assign key partitions space

8. Computational Puzzles First suggested by Naor and Dwork in 1992 Moderately hard function Costly to compute Fast to verify E.g. given y, find x such that h(x)1..k=y 2k calls to h() to compute 1 call to h() to verify

9. Puzzles Uses Email protection Compute a puzzle based on the hash of the message you want to send Implemented by HashCash DoS protection on web/other services Compute a puzzle posed to you by webserver before getting a web page [Juels & Brainard]

10. Limitations Puzzle must be cheap enough for �minimally capable node� Old computers vs. Moore�s law Only effective at preventing large-scale attacks Economic argument sometimes fails Laurie & Clayton: HashCash won�t work Economic trade-off is fundamental! Even with centralized admission control

11. Interactive Puzzles Idea 1: Follow the client-puzzle approach Whenever one peer contacts another a puzzle must be solved Problems: Introduces high latency Work is proportional to the number of peer contacts, not the number of sybils Not great for anonymity, since we need a low c/n.

12. Id-based puzzles Idea 2: Solve a puzzle based on identity Suggested by Castro et al Limits rate of joining the network Does not limit number of sybils long term Include day in the puzzle Precomputation is still possible

13. Freshnesss Idea 3: All-to-all broadcast Each round, every node picks a random challenge ci, broadcasts to each other node Challenge = h(c1 || � || cn || node ID) Freshness guaranteed Inefficient

14. Limited broadcast Broadcast ci to each neighbor Node i with neighbors j, k, l ci� = h(cj || ck || cl || ri) cj, ck, cl are the incoming challenges for node i ri is selected randomly by node i

15. Diagram

16. Entanglement After m rounds, ci depends on challenges from nodes m hops away from i After O(log N) rounds, ci depends on challenges from all nodes This dependency can be proven by verifying hash values

17. Verifying Challenges Node i can prove that c_i� depends on c_j by showing: c_i� = h(x || c_j || y) Node j can now ask node p to prove whether c_p�� depends on c_j� and so on To verify a challenge for a node m hops away, need to start with own challenge from m rounds ago

18. Diagram

19. Computing Challenges Every t time steps, generate a puzzle based on the current challenge value Also include public key and node ID Public key used in routing failure test Can always show current puzzle depends on challenge t steps ago But current puzzle may not be solved yet Start verification from d + 2t time steps back Store old hashes for d+2t rounds

20. Churn Nodes may have joined, left after 2t+d time steps Solution: use old routes for 2t+d time steps after change New nodes: on probation Failed nodes: ?

21. Route around failure

22. Static Resilience How often can we do this? Study of static resilience in [Gummadi�03]

23. How big should t be? If t is too small, online puzzle solutions may be possible If t is too large, route repair will be too slow We suggest t=3min Median lifetime of nodes in P2P networks is 60 minutes 2t+d interval will see something like 10% churn

24. Comparison with Certificates Selective DoS is still possible with puzzles Nodes can occupy positions of their choice Certificates can restrict ID selection Load balancing is easier with puzzles Density test used in [Castro et al] more reliable 2- or k-choice load balancing possible with certificates Decreases attacker cost by factor of k

25. Conclusions Computation puzzles can be used to address Sybil attacks Completely decentralized solution May be realistic for very large-scale p2p networks

26. Future Work Reduce overhead due to failed nodes Optimistically use new routes Remember old routes, exploit pareto distribution of node lifetimes Can we use distributed randomness for non-computational puzzles? E.g. storage, CAPTCHA Other uses for distributed randomness