Low-Cost and Reliable Mutual Anonymity Protocol in Peer-to-Peer Networks

1. Low-Cost and Reliable Mutual Anonymity Protocol in Peer-to-Peer Networks Li XiaoZhichen XuXiaodong Zhang IEEE Transactions on parallel and distributed systems Yu-Chao Lin

2. Outline • Introduction • Mutual Anonymity With Trusted Third Parties • Mutual Anonymity In Pure P2P System • Protocol Analysis • Conclusion

3. Introduction (1/2) • Peer • Publisher : Produce document • Provider : Deliver documents upon requests, also called responder • Requester : Request documents, also called initiator • Type of P2P system • Pure P2P : Peers share data without a centralized coordination • Hybrid P2P : Some operations are intentionally centralized, such as indexing of peers’ files

4. Introduction (2/2) • Mutual anonymity Peer3 Download data Upload data Peer2 Peer1

5. Introduction • Index Server : Keep the whereabouts of the contents that are stored in the peers • Mutual anonymity protocol with trusted server • Mix-Based protocol • Center-Directing protocol • Label-Switching protocol • Mutual anonymity protocol in pure P2P • Shortcut-responding protocol

6. Mutual Anonymity With Trusted Third Parties (1/2) • I : represent the initator • R : represent the responder • S : represent the index server • Pi: represent a peer (i=1, 2, 3, ……) • X -> Y : M : represent X sending a message M to Y • Kx: denote the RSA public key of X • K : denote the DES key • (M)K: represent encrypting the message M with the key K (RSAor DES)

7. Mutual Anonymity With Trusted Third Parties (2/2) • Index server : record index of files that peers want to share with others peers, and has all public keys of peers

8. Mix-Based Protocol (1/2) Find out that the file is possessed by R, it selects a list of peers p0, p1, p2, ..pk at random to generate mix path index server I→S : (file_ID)Ks S→R :((K)KR,(file_ID)K,(K)KI,(p0, (p1, (I, fakemix)Kp1)Kp0)KR) I R p1→I : ((f)K,(K)KI,fakemix) R→p0 : ((f)K,(K)KI,(p1, (I, fakemix)Kp1)Kp0) p1 p0 p0→p1 : ((f)K, (K)KI, (I, fakemix)Kp1)

9. Mix-Based Protocol (2/2) • Mix path : (p0, (p1…(I, fakemix)Kpk..)Kp0)KR • Only the path is encrypted with an expensive public key encryption, and the content is encrypted with a less expensive DES key

10. Generate next middle node p1 • Generate another node number pj1 • Convert the request label n to (n)Kpj0 • Generate a unique label n for the request • Generate the first middle node p0 • Generate DES key K • Generate another node number pj0 randomly Center-Directing Protocol (1/2) index server S →R : ((K)KR,(n, file_ID, p0, pj0)K,(K)KI) I → S : (file_ID)Ks S →p0 : ( (n)Kpj0, (p1, pj1)Kp0 ) I R S →p1 : ( ((n)Kpj0)Kpj1, (I, pj2)Kp1 ) R →p0 : ( (n)Kpj0, (f)K,(K)KI ) p1 →I : ( (((n)Kpj0)Kpj1)Kpj2, (f)K, (K)KI ) • Get K from (K)KR • Convert the request label n to (n)Kpj0 p1 p0 p0 →p1 : ( ((n)Kpj0)Kpj1,(f)K,(K)KI )

11. Center-Directing Protocol (2/2) • The label uniquely identify a message • Each pi keeps a hash table to synchronize between the message from the index server and the message from its previous hop • Randomly generated node has no correlation with nodes in the covert path (pj0, pj1, pj2,……pjk) • This protocol take advantage of the fact that encryption cost is much lower than decryption cost in public key encryption ( encryption/decryption = 543/45.4 Kbps) • The sizes of items that need to be encrypted by public key encryption are independent of the path length

12. Label-Switching Protocol (1/3) • Index server produces a path table beforehand, and each peer pi, as a destination, is associated with several path option (px-py-..-pi) • Each peer has subtables that related to the path table

13. Label-Switching Protocol (2/3) • Step 1: The initiator I sends a request to SI →S : (file_ID)Ks • Step 2: S randomly select a path for I (p0-p1-..pk-I), and path has a label L. S →R: ( (L, p0)K, (K)KR, (K)KI ) • Step 3: R →p0 : L , and a persistent connection will be established between R and p0 • Step 4: Similar method with step 3, so we can construct a persistent connection R-L →I : (f)K, (K)KI

14. Label-Switching Protocol (3/3) • It does not need the synchronization associated with center-directing protocol • It does not need much encryption and decryption operations • But need the spaces for storing the path table and subtables and the time spending on table look-ups • Index server will updating the path table periodically

15. Shortcut-Responding Protocol (1/2) • The initiator I randomly select a list of peers r0, r1,.., rkr and build replyblock with I • Replyblock : (rkr, (rkr-1..(r0, (I, fakemix)Kr0)Kr1…)Krkr) • The responder a list of peers o0, o1, …,ok0 at random and build Onion • Onion : (o0, (o1, …(ok0, (relay, fakemix)Kok0)Kok0-1…)Ko0) • R →relay →I : (r, (f)KI ) Replyblock Onion Replyblock Save request r r0 r1 (r, relay:p3, KI) I p0 p1 p2 p3 p4 p5 p6 (r, replyblock, KI) o1 o0 R

16. Shortcut-Responding Protocol (2/2) • The response path can be shorter than the requesting path • Eliminating the index maintenance overhead and the problem of inconsistency between index records and peer file contents

17. Protocol Analysis

18. Protocol Analysis • The time spent on RSA for the mix-based protocol increase as the number of middle nodes increases. • The time spent on DES and RSA for the center-directing and label-switching protocols are independent of the number of middle nodes

19. Conclusion • Providing a reliable and efficient anonymity protection among peers is highly desirable in a scalable and secured P2P system • If storage space is not a concern, the label-switching protocol is best choice • The center-directing protocol could handle case that if a node in a covert path is down