Low-Cost and Reliable Mutual Anonymity Protocol in Peer-to- Peer Networks Li Xiao Zhichen Xu Xiaodong Zhang IEEE Transactions on parallel and distributed systems Yu-Chao Lin

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

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

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

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

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

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

Mix-Based Protocol (1/2) I index server I → S : (file_ID)K s Find out that the file is possessed by R, it selects a list of peers p 0, p 1, p 2,..p k at random to generate mix path R S→R : ( (K)K R, (file_ID)K, (K)K I, (p 0, (p 1, (I, fakemix)Kp 1 )Kp 0 )K R ) p0p0 p1p1 R→p 0 : ( (f)K, (K)K I, (p 1, (I, fakemix)Kp 1 )Kp 0 ) p 0 →p 1 : ( (f)K, (K)K I, (I, fakemix)Kp 1 ) p 1 →I : ( (f)K, (K)K I, fakemix )

Mix-Based Protocol (2/2) Mix path : (p 0, (p 1 …(I, fakemix)Kp k..)Kp 0 )K R Only the path is encrypted with an expensive public key encryption, and the content is encrypted with a less expensive DES key

Center-Directing Protocol (1/2) I index server R p0p0 p1p1 I → S : (file_ID)K s 1.Generate a unique label n for the request 2.Generate the first middle node p 0 3.Generate DES key K 4.Generate another node number p j0 randomly S →R : ( (K)K R, (n, file_ID, p 0, p j0 )K, (K)K I ) 1.Generate next middle node p 1 2.Generate another node number p j1 3.Convert the request label n to (n)Kp j0 1.Get K from (K)K R 2.Convert the request label n to (n)Kp j0 R →p 0 : ( (n)Kp j0, (f)K, (K)K I ) S →p 0 : ( (n)Kp j0, (p 1, p j1 )Kp 0 ) p0 →p1 : ( ((n)Kp j0 )Kp j1, (f)K, (K)K I ) S →p 1 : ( ((n)Kp j0 )Kp j1, (I, p j2 )Kp 1 ) p 1 →I : ( (((n)Kp j0 )Kp j1 )Kp j2, (f)K, (K)K I )

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 (p j0, p j1, p j2,……p jk ) 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

Label-Switching Protocol (1/3) Index server produces a path table beforehand, and each peer p i, as a destination, is associated with several path option (p x -p y -..-p i ) Each peer has subtables that related to the path table

Label-Switching Protocol (2/3) Step 1: The initiator I sends a request to S I →S : (file_ID)K s Step 2: S randomly select a path for I (p 0 -p 1 -..p k -I), and path has a label L. S →R: ( (L, p 0 )K, (K)K R, (K)K I ) Step 3: R →p 0 : L, and a persistent connection will be established between R and p 0 Step 4: Similar method with step 3, so we can construct a persistent connection R-L →I : (f)K, (K)K I

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

Shortcut-Responding Protocol (1/2) The initiator I randomly select a list of peers r 0, r 1,.., r kr and build replyblock with I Replyblock : (r kr, (r kr-1..(r 0, (I, fakemix)K r0 )K r1 …)K rkr ) The responder a list of peers o 0, o 1, …,o k0 at random and build Onion Onion : (o 0, (o 1, …(o k0, (relay, fakemix)Ko k0 )Ko k0-1… )Ko0) R →relay →I : (r, (f)K I ) Ip0p0 p1p1 p2p2 p3p3 r0r0 r1r1 p4p4 p5p5 p6p6 R o0o0 o1o1 (r, replyblock, K I ) (r, relay:p3, K I ) Replyblock Onion Reply block Save request r

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

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

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