A Protocol for File Sharing, Anonymous and

Confidential, Adapted to P2P Networks

Mohamed Amine RIAHLA, Karim Tamine, Philipe GABORIT

University of Limoges

XLIM Laboratory UMR CNRS 6172

Limoges, FRANCE

meda.riahla@gmail.com, karim.tamine@xlim.fr, philippe.gaborit@unilim.fr

Abstract—Peer-To-Peer networks have become increasingly

common as a means of transferring files over Internet. However,

user anonymity and privacy are not typically protected in such

peer-to-peer systems. An adversary can gain knowledge about

not only the content of the files being transferred but also the

senders and receivers of the files. In this paper, we describe the

design and experimentation of AnonymP2P a new Anonymous

and confidential P2P system. AnonymP2P works on the principle

of social networks with nodes identified by virtual addresses

where each node can change randomly its neighbors to avoid an

attacker to surround it. AnonymP2P uses also a process of data

request and file sharing that differs from that found in other P2P

networks; indeed the “path” of the file transfer is not necessary

the reverse “path” of the data request but a set of “paths” built

by a set of control message. The “path” of the data request and

the “paths” of the file transfer are used by sender and receiver to

exchange a secret by the Diffie-Helman protocol and thus reduce

the probability of success of Man-In-The-Middle attack. We

show that our protocol presents a good trade-off between

efficiency on the side and anonymous and confidential

communications on the other side.

Keywords-component, anonymity, cryptography, mobile multi

agent systems, P2P networks.

I. INTRODUCTION

Peer-to-Peer networks have become increasingly common

as a means of transferring files over the internet [1]. However,

data sent via Peer-To-Peer applications is vulnerable to traffic

analysis. An adversary can gain knowledge about, not only the

content of the files transferred but also the sender and receiver

of the files [2] [3]. To this end, various system designs have

been proposed. Some of these, such as Onion Routing [4],

provide a different type of anonymity but are difficult to apply

in a Peer-To-Peer setting. Others, like Freenet [5], Mute [6]

AntsP2P [7] and OneSwarm [8] have design flaws that make

them susceptible to many kinds of attacks.

FREENET is efficient software to protect the anonymity of

nodes but it has some limitations, as the recovery time of a

resource, and its complex system of keys broadcast. MUTE

uses static virtual addresses for routing messages in network,

according to a technique inspired from ants colony.

However, this protocol cannot resist some attacks for the

preservation of anonymity as described in this example:

Indeed, an attacker can "monitor" communications of a

neighboring node and deduce information about this node.

AntsP2P protocol has similarities with MUTE protocol (using

search and transfer data algorithms based on the ants colony

method) but it also uses end to end encryption. Queries are

encrypted asymmetrically, meaning that all nodes can consult

the search query, but only the applicant node can decrypt

results of request. However, AntsP2P is vulnerable to Man-in-

the-middle attacks [9]. Indeed, spy nodes can totally intercept

queries and replay them with their own encryption keys. The

spy user can know in this way the results of the query or the

files in transit, knowing that the path of query is the same as

that of the response. OneSwarm is a P2P data sharing system

that provides users with explicit, configurable control over

their data: data can be shared publicly or anonymously, with

friends, with some friends but not others, or only among

personal devices. The search cancel message is forwarded

along the same paths as the corresponding search message.

However, we think that this method can allow an attacker to

locate the search source by a study of the traffic, and this will

cause to a loss of anonymity.

In this paper, we describe the design and experimentation

of AnonymP2P a new Anonymous and confidential P2P

system.

Our protocol was designed with the following three goals:

to protect the identity of providers of files (senders), to protect

the identity of consumers (receivers) and to protect the contents

of files transferred through the network. AnonymP2P works on

the principle of social networks with nodes identified by virtual

addresses where each node can change randomly its neighbors

to avoid an attacker to surround it. AnonymP2P uses also a

process of data request and file sharing that differs from what

is in other P2P networks; indeed the “path” of the file transfer

is not necessary the reverse “path” of the data request but a set

of “paths” built by a set of control message. The “path” of the

data request and the “paths” of the file transfer are used by

sender and receiver to exchange a secret by Diffie-Helman

protocol [10] and thus reduce the probability of success of

Man-In-The-Middle attack [9].

Our measurements performed by the PeerSim Simulator

[11] show that the performance obtained in our protocol

2012 6th International Conference on Sciences of Electronics, Technologies of Information and Telecommunications (SETIT)

978-1-4673-1658-3/12/$31.00 ©2012 IEEE 549

support the comparison with Gnutella [12] witch is a P2P

protocol data exchange not confidential and not anonymous.

This paper is organized as follows: in Section 2 we describe

in detail the protocol AnonymP2P. We conduct a brief security,

performance and anonymity analysis in Section 3, evaluate our

system in Section 4, and conclude our work in Section 5.

II. THE ANONYMEP2P PROTOCOL: OPERATION

PTINCIPLE

AnonymP2P allows any node in the network to search and

retrieve resources while ensuring the anonymity of the

applicant (receiver) and the supplier (sender) of these

resources. To maintain anonymity during exchanges, several

elements are set up:

The P2P network works on the principle of a virtual

social network; in fact every node possesses a virtual

identity, which is used during a search request. Each

node is identified to the network through a connection

to neighboring nodes which modifies them randomly

over time. When a node wishes to download a

resource, it launches a request through its neighbors;

this request is routed through a set of control messages

that operates as a Mobile Multi-Agent system; each

agent is created by each node and sent randomly

through the network. There is no broadcast of query

like the other P2P systems. On the contrary it is the

collaborative Mobile Agents which are responsible for

the propagation of this request. Each agent transports

one or more resources requests and establishes routes

between nodes of the network during its life cycle.

Several routes will be built, by collaborative agents,

between each pair of nodes; so the downloads are fast

and multi-sources.

A management of loss of packets and broken links

between nodes is possible using routing information

broadcasted by agents.

Each network node stores its own requests and as well

as those of other nodes for further performance in one

hand, and in another one to preserve the anonymity of

the search node (applicant) as will be explained later.

Once the applicant node sends its request via the

Mobile Agents, it changes probably some of its

neighbors and initiates the computing of paths for the

transfer of this resource. Hence, the “path” of the

request is different from “paths” of response. This

original process of route calculations during request

and transfer allows the applicant and the supplier to

share resources encrypted using a secret key

established by a Diffie-Helman-based protocol and

allows thus to reduce the risk of Man-in-the-middle

attacks as will be explained later in this paper.

Finally, to strengthen the anonymity of exchanges, the

protocol sends in the network only encrypted packets

which have appreciably the same size; in this way it is

difficult for the attackers listening to the traffic to

make a difference between control packets, or data

packets.

Fig. 1. Basic principle of a social network in AnonymP2P

III. DETAILLED OPERATION OF THE PROTOCOL

A. Notations and Terminology

The used notations are defined as follows:

IDA: Virtual identity created by the node A.

PKAB: Public key of the node B received by

neighboring node A.

KA: Secret generated by the virtual node A.

KAB: Secret shared by the nodes IDA and IDB.

EPKAB (M): The message M is encrypted by the public

key of node B and sent from node A to node B.

EKAB (M): The message M is encrypted by the secret

key KAB exchanged between the virtual nodes IDA and

IDB.

DH1 (.): The first information corresponding to the

Diffie-Helman protocol sent by the applicant.

DH2(.): The second information corresponding to

Diffie-Helman protocol sent by the supplier.

Signs(M): The message M is encrypted and signed by

the secret key s.

Applicant: The search source node.

Supplier: The data source node.

B. Managing identities and connectivity

Each AnonymP2P user is named using a virtual identity

(chosen by the node) that identifies this user among its peers.

Each user generates a public/private RSA key pair when

installing the client, the public key serving as its

communications with its neighbors. Each node has a limited

number of neighbors. Initially, when a node wants to fit into

the network, its neighbors are retrieved by querying a set of

well-known nodes on the network. To select the closest nodes

as neighbors, the protocol establishes proximity measures of

each node newly known, by calculating the round trip time

(RTT) of a package through a direct communication using TCP

protocol. Each network node decide periodically, in a

probabilistic manner, to make proximity computations with

other nodes (especially the nodes newly inserted in the network

and which want to be its neighbors) in order to choose them as

new neighbors and delete the former once. This method allows

a node to have dynamic neighbors and makes an analogy

550

between nearness in terms of real computer network and a

nearness of P2P subset. To preserve the property of anonymity,

a node can be forced to choose other neighbors that are not

necessarily nearest and delete the former once. This principle

of dynamic neighborhood allows to simulate the mobility of a

node in the network and to disrupt an attacker who would like

to surround any given node. It is supposed that during the

process of connecting a node to its neighbors, an exchange of

public keys which allows the nearby nodes to have encrypted

exchanges is established. Therefore AnonymP2P ensures an

encrypted stream between a node and its neighbor. The

communication between two neighboring nodes is encrypted

using an AES symmetric key that is encrypted with public key

(RSA) of the neighboring node. The used AES secret key is a

session key that is modified for each new sent stream.

C. Locating and transferring data

We have described how AnonymP2P peers join and

maintain overlay connections and update the connectivity

information. We now present the protocol used for search and

transfer data between nodes.

In order to allow some network nodes to accomplish

resource requests and then retrieve them via other nodes, the

protocol uses a set of control messages that work like a Multi

Agents Mobile System. Each Mobile Agent (control message)

is created by a node and sent randomly in the network, with a

TTL (Time to live) value chosen also randomly. Each Mobile

Agent has a set of information that allows nodes to cooperate

in order to compute search paths resources, and the paths of

transferring these same resources.

In other words, each node makes available to the other

network nodes a set of Mobiles Agents that locate the resources

requested by different nodes and also establishes anonymous

paths between these different nodes.

Each Mobile Agent transfers two types of information: a

list of resources requests initiated by nodes (cf. section Process

of search) and a list containing routing information for the

computation of anonymous paths in order to transfer resources

between applicant and supplier nodes (cf. section Determining

anonymous paths).

The information contained in these lists are dynamically

exchanged and updated by the different nodes during the

mobility of Agents in the network.

In the remainder of this section, we present the search and

transfer process of resources between different nodes.

1) Process of search: When a node wants to retrieve a

resource in the network, it does not broadcast the request but it

randomly selects a Mobile Agent moving through this node

and inserts the following information:

EPKAV((<IDA><keywords><DH1(KA)><IDA_session><TT

L>) when <IDA> represents the virtual address chosen by the

applicant node, and which will be distributed in the network

during this request, < keywords > is a keyword list of the

searched resource , <DH1(.)> is part of the secret that will

exchange the applicant and the supplier by Diffie-Helman's

method [10] (Other part of the secret will be sent by the

supplier during the answer to the request and this will be

explained later in this paper), <TTL> the number of times that

the request will be forwarded by the current node (this value

will be decremented every time that the node forwards this

request), and finally <IDA_session> is an integer generated

randomly by the applicant node, in order to identify the request

and avoid loops. All these information is encrypted with the

public key EPKAV where V is a neighbor chosen randomly by

the node which will receive the Mobile Agent. Similarly, The

Mobile Agents disseminate this information along the various

nodes traversed. To ensure the anonymity of the applicant

node, a node does not only stock its own requests but also

those of the other network nodes, Therefore, even if an attacker

may observe requests exiting from a node without being

received, he cannot deduce if they are requests of the

monitored node or of the other nodes.

The storage duration of a query in a node is managed as

follows: In the reception of a request, this last one arrives with

an integer value TTL; this TTL value does not mean the

number of times that the request will forwarded (case of the

majority of the existing protocols) but the number of times that

this request will be forwarded by each node that receives the

request through a Mobile Agent. For example, if a node stores

Fig. 2. Process of search with AnonymP2P

551

a request with a TTL=3, this mean that it can forward it 3 times

towards its various neighbors before deleting this request.

2) Determining anonymous paths: One of the objectives of

AnonymP2P protocol protocol is to protect the supplier of a

resource by preserving its anonymity. Unlike the existing

protocols which instead of sending the resource along the

inverse “path” of search, the possessor node of a resource will

transfer its resources along other “paths” initiated by the

applicant. When an applicant node has sent its request, it

proceeds with some probability to change its neighborhood,

then initiates the calculation of “paths” for transferring the

resource. The applicant node will initiate this path, by

inserting in its anonymous paths table the following entry:

<IDA><IDA_session><distance><neighbor_node> where

<IDA> corresponds to the virtual address of the applicant

node, <IDA_session> allows to identify the request,

<distance> is an integer generated by the applicant

corresponding to the distance (in number of hops) which

separates the applicant node to a ‘fictitious’ node generated by

the applicant and finally <neighbor_node> corresponds to a

nearby node chosen randomly by the applicant. The Mobile

Agents will disseminate this information in order to allow to

different nodes to update their tables of ‘anonymous’ paths

corresponding to all resources requests of the other nodes.

The tables entries of anonymous “paths” are updated as

follow: if the entry <ID> <ID_session> <distance> contained

in a Mobile Agent coming from a node x corresponds to a new

virtual address in the table of the current node, then the entry:

<ID><ID_session>< distance +1><x> is inserted into the

anonymous routing table of the current node. Thus, in this way

the anonymous “paths” will be progressively built between the

supplier node and the applicant node, as soon as the

anonymous supplier routing table contains entries with a

destination towards the virtual address of the applicant node.

3) Response and Data transfer: To strengthen the property

of anonymity, the protocol will make circulate in the network

only encrypted packets which have approximately the same

size. It is then difficult for the various nodes which listen to

the circulating packets in the network to distinguish between

control packets or data packets. The supplier node sends a

response via the anonymous “paths” calculated during the

previous phase. The reply messages include a search

identifier, a list which identify resources that correspond to the

search (Each proposed resource has a unique identifier

<Id_resource>).

The supplier node sends also with the response the key

<DH2(.)> which is the other part of the information that

exchange the supplier and the applicant in order to establish a

secret with a Diffie-Helman protocol. To reduce the risk of

Man-in-the-middle attack type, the responses to the request and

the <DH2(.)> key will be sent through all the different

anonymous “paths” previously created. The applicant node can

avoid the Man-In-The-Middle attack by choosing the right

DH2(.) key. This key must the same value those received

through all “paths”.

Fig. 3. Response and Data transfer

552

The applicant node determines the resource to download

through the inverse paths of the anonymous paths by sent as

message the following packet: EPKdv (<Idr>, <IDd>, <IDf>,

<ID_session>), where <Idr> represents the identifier of the

retrieved resource (identifier sent with the reply messages),

<ID_session> is the identifying number of the request, <IDd>

is a virtual address of applicant for the resource and <IDf> is a

virtual address of the resource supplier node; the <Idr>, <IDd>

and <ID_session> values are encrypted by the secret Kdf

shared between the applicant and the supplier during the

previous phases. When a supplier node wants to send the

requested resource, and in order to respect the size constraint of

the messages circulating in the network, it cuts the resource f at

a set of packets f1, f2, fn with approximately size equal and

sends them along different anonymous “paths”. Each message

has the following structure: EPKAV ((<IDf>, <IDapp>,

<SignKdf(fi,i)>, <ID_session>)), where < IDf> and <IDapp>

represent the virtual address of the supplier and applicant

during the request phase, <SignKdf (fi,i)> is the fi part of the

resource encrypted using the secret Kdf. <IDf> and

<ID_session> are also encrypted with Kdf. Moreover in order

to ensure the integrity and the confidentiality of the message,

this part of the resource is signed. This message is encrypted by

the public key EPKAV where V represents the next neighboring

node which is on the anonymous “path” built in the previous

step.

D. Managing packet losses

It would be possible that an applicant node does not receive

the totality of the resource parts sent by a supplier node (caused

essentially by a loss of packets in the network or a topology

change). In this case, the protocol allows the node to ask

anonymously for the missing messages. The applicant node

will send through the anonymous paths, the following request:

EPKdv(<liste_of_indices>, <IDd>, <IDf>, <ID_session>), where

<liste_of_indices> represents the index list of missing

messages, <ID_session> is the number identifying the

requested resource, <IDd> is the virtual address of resource part

applicant and <IDf> is the virtual address of the supplier node ;

the <liste_of_indices>, <IDd> and <ID_session> values are

encrypted using the secret (Kdf) between the applicant and the

supplier. Once the supplier node receives this message, it will

resend the missing fi by applying the same process described

above.

E. Managing link losses with neighbors

When a node loses links between one or more of its

neighbors, an update of anonymous route tables is necessary.

To do this, the node sends a rectifier control message to its

neighbors in order to inform them by this loss of link; this

allows neighboring nodes to update their anonymous route

tables. Each neighbor node will inform the whole of its

neighbors by this failure. This allows anonymous routing tables

to be updated and refreshed in every change of the network

topology.

IV. ANONYMITY AND PERFORMANCE ANALYSIS

In this section, we examine how the protocol insures a

certain level of confidentiality and anonymity during the

request phases and transfer of resources between various

nodes. We restrict our attention to what we believe to be the

most likely attackers conducting the most likely attacks.

Fig. 5. Managing losses of links with neighbors

Fig. 4. Sending requests by AnonymP2P

553

A. The applicant anonymity

The protocol ensures anonymity of the applicant with the

following properties:

The resource requests are not broadcasted by the applicant

node to all its neighbors (the case of the majority of the

existing protocols), but distributed by the Mobiles Agents that

moves randomly through the nodes (so it is difficult for an

attacker to deduce which is the search source node. Cf. figure

5).

In AnonymP2P, each node has resource requests with TTLs

that correspond to the number of times the request can be

forwarded by the current node (not by all nodes that processes

this request). This may disrupt an attacker that tries to deduce a

data source by analyzing the TTLs.

Each applicant node stores and sends the resource requests

of the other nodes in addition to its own. Consequently the

neighbor node which receiving a request (by one or more

Mobile Agents) cannot know which is the query owner, even if

he knows that it is inserted by this node. We will illustrate this

through the example of Figure 6.

Case1: The node V1 is an attacker.

In this case, the node V1 cannot know if it is the node N

which sends the request or it is just a request relay.

Case 2: The nodes V1 and V4 are both attackers and

form a coalition

In that case, we suppose that the node V4 can communicate

with V1 and deduce that the node N inserted a resource

request. Even if it is unlikely to have this topology, our

protocol resists to this attack as follows:

The node N does not only save its own requests, but it

saves in its cache the requests from other nodes (which may be

those of V2, or V3 or V5 or even a request coming from

another network node). Therefore, there is no proof for the V1

and V4 nodes that the node N is an applicant.

Case 3: All the neighbors of the node N are attackers

and form a coalition.

In this case, all neighboring nodes of N can communicate

one with each other, and therefore they can deduce that node N

has made a request that never transited through these

neighbors. Although, this is a very unlikely scenario, our

protocol resist well to this attack. Indeed, the neighboring

nodes cannot deduce that N is an applicant; this is because the

request might be an old request still residing in node N cache

and was received through an old neighbor before neighborhood

change.

B. The supplier anonymity

The AnonymP2P protocol ensures the supplier anonymity

based on the following:

Timing attack: By measuring the round trip time

(RTT) of search response pairs, an attacker can

estimate the proximity of a data source. Usually, paths

are lengthy, making the chances of being next to any

particular data source quite low. For a small number of

requests, however, an attacker might be directly

connected to a data source and also be able to identify

it as such based on the low RTT of response messages.

To frustrate this attack, the protocol OneSwarm

artificially inflates delays for queries received from

untrusted peers; all responses to untrusted peers are

delayed by a random but deterministic amount

(computed based on the content hash) in order to

emulate the delay profile of forwarded traffic from one

or more hops away. We think that this method

decreases performance of the protocol. In AnonymP2P

protocol, the request “path” is different from response

“paths”, therefore the node that tries this attack, will

not even receive a reply. In the case where the two

paths (request and response) are the same, we can add

a small random waiting delay (to simulate the fact that

the request has been propagated through other nodes).

Collusion attack: This attack is carried out by multiple

nodes whose form a coalition as illustrated in figure 7.

A sends a targeted search to T, receives a search

response, and observes whether the search was

forwarded to colluding peers C1, C2,..Ck.

Fig. 7. An attacker, A, with C1…Ck colluders tests if a target T is sharing a file

Although effective, this attack requires both the attacker

and its accomplices to be directly connected to the target.

However, this attack cannot be realized in our protocol,

because the topology of the network is dynamic. Although this

topology is very unlikely, protection against collusion attack

will be strengthened when adding our specificities.

Fig. 6. Sending requests by AnonymP2P

554

Since, in AnanymP2P, a request is not automatically

"broadcasted" to all neighbors, but sent just to a few neighbors

randomly selected by the Mobile Agents. Therefore if the

nodes C1, C2, ... Ck do not receive the request, the node A

cannot deduce anything, because it is possible that Mobile

Agents did not move through the nodes C1, C2, ... Ck. When the

node A receives the response (see figure 7), it cannot deduce

that the node T is a data source because it may be a response

generated by a neighbor of node T before its neighborhood

change.

Deconstructing overlay paths: We next consider the

more generic attack of attempting to locate any data

source for a particular object, but without having a

specific target a priori. This requires first

deconstructing the overlay path to a potential data

source before testing if it is sharing the object. To do

this, a group of attackers can use coordinated

measurements of search response message propagation

to infer the likely next hop along an overlay path,

monitor or attempt to peer with that client, and then

repeat. The feasibility of this attack depends on the

length, stability, and diversity of paths to the object. In

AnonymP2P, the virtual network topology changes

randomly and the diversity of anonym “paths” between

the applicant and the supplier can avoid this attack.

The attackers will not even have time to make their

statistical analysis before the topology will be changed.

C. Confidentiality and integrity of data exchanged

The supplier sends its encrypted response together with the

second part of Diffie-Hellman key via all anonymous paths,

even if the resource request path can cross with one of the

response paths. Although the crossing of paths might result in a

possible Man-in-the-middle attack, the applicant has a

definitive way to check that. This is done by sending the

second part of the key by multiple paths, allowing him to note

and ignore the answers that go through Man-In-The-Middle

nodes (Cf. section 4.3).

The integrity of messages exchanged between the applicant

and the supplier is provided by the Diffie-Helman secret key

exchanged during the request/response phases and using a

signature protocol.

V. SIMULATION AND RESULTS

Our protocol is simulated using PeerSim simulator.

PeerSim is a Peer-to-Peer simulator. It has been designed to be

both dynamic and scalable.

A. Performance measurements

The following study shows the behavior of two protocols

AnonymP2P and Gnutella. Gnutella is a popular unstructured

Peer To Peer file sharing; accounting for over 40% of all P2P

users. A comparison of their performance in terms of

information search was carried out. We analyzed their

scalability according to two parameters:

The number of nodes in the network.

The number of resources requests in the network.

The metric used in this paper is:

The satisfied requests: which represent the ratio of the

requests satisfied in the network (requests which have at least

one response)

Fig. 8. Ratio of requests satisfied as a function of the number of nodes

Fig. 9. Ratio of requests satisfied as a function of the number of requests

Our key goal is to reduce the performance cost of

anonymity and confidentiality. Our simulations on the system

show that performance (in terms of information retrieval)

obtained in the anonymous data transfers, can be compared

with non-anonymous systems such as Gnutella [12] (see figure

8 and 9). This is due essentially to the optimal use of

collaborative agents (which adapt themselves well to the

decentralized P2P networks and to social networks) and to the

management of packet losses and link breaks between nodes.

B. The diversity of paths

In the following figure we show the average number of

paths between any two nodes of the network, as a function on

the number of nodes. As we have previously proved, the

diversity of anonymous “paths” increases the anonymity of the

applicant and the integrity of shared resources.

555

Fig. 10. The average of the number of paths between two anonymous nodes as

a function of the number of nodes

The graph shows that there is a diversity of paths between a

source node and a destination node with AnonymP2P, which

offers the following advantages:

Downloads (transfers in general) will be fast, multi-

source, tolerant to congestion of intermediate nodes.

Better resistance against the attack "deduce the

network topology" (studied in Section 3).

Several answers paths are possible, so the path of the

resource request is not the only path for response.

By having several paths between two network nodes,

the supplier can send its answer and the second part of

Diffie-Hellman key through all anonymous paths, thus

allowing the applicant to have the means to ignore the

Man-in-the-middle attack.

C. Probability success of the Man-In-The-Middle attack

In order to estimate a Man-In-The-Middle attack to

succeed, we consider the following:

Assume that exists a network node can monitor a group of

nodes consisting of nbmalicious nodes.

We consider nbnodes the total number of nodes in the

network, nbaverage the average number of nodes contained in

a path between any two nodes on the network and nbpaths the

average number of paths connecting any two nodes on the

network.

The calculation of the probability that all nodes of any path

are not compromised is given by the following formula:

C

C=P )nbnodes(

)nbaverage(

)snbmaliciounbnodes()nbaverage(

(1)

Therefore the probability there exist at least one node

compromised among nodes of any path between two nodes of

the network is:

)P-1(

The Man-In-The-Middle attack described in the paper will

be successful, if at least one node compromised on each path

connecting any two nodes in the network. Therefore the

probability that the Man-In-The-Middle attack successful is

given by the following formula:

nbpath

MiddleInMan )P1(=P

To estimate the value of probability as described in Eq. 3,

we consider the following values:

According to Figure10 and simulations we have performed,

we note that from a total number of nbnodes=600, the average

number of paths between any two nodes of the network is

stabilized at nbpath=14.

The simulations have shown also that the average number

of intermediate nodes in a path connecting any two nodes of

the network is nbaverage=18.

We assume that there is a network node which control 10%

of all the network nodes (which is considerable for a P2P

network), so nbmalicious=60.

The Eq. 3 then gives us:

11.0=P Middle-In-Man

This result confirms what we have discussed in section 3.

D. Supplier anonymity

The graph shows the percentage of responses sent by a

resource supplier to neighbor node, which brought the request

as function of the number of nodes and the number of requests.

We note that with AnonymP2P the supplier rarely sends the

resource on the inverse route of the request, allowing it to resist

to the Timing attack (explained in the section 3).

Fig. 11. Ratio of responses that are sent (by the supplier of a resource) to the neighbor, which brought the request as a function of the number of nodes

Fig. 12. Ratio of responses that are sent (by the supplier of a resource) to the

neighbor, which brought the request as a function of the number of requests

556

VI. CONCLUSION

We have proposed a new protocol for sharing files adapted

for P2P networks. Our protocol is based on two main ideas.

The first allows each network node to change its neighbors

randomly thus allowing to have a dynamic network. The

second idea is the fact that the construction of routes for

resource discovery differ of paths to transfer of these resources.

These two features of the protocol will permit a better

anonymity and a better protection against attack Man-In-The-

Middle that existing protocols. The simulations show that our

protocol maintains a very good efficiency for good

management of anonymity and confidentiality of files

exchanged.

APPENDIX: AUTHOR DISCOUNT

University of Limoges

XLIM Laboratory UMR CNRS 6172 83,

rue d’Isle, 87000 Limoges,

FRANCE

Fax: +33 5 55 43 99 77

Phone: +33 5 55 43 69 75

REFERNCE

[1] Vinod Muthusamy. An Introduction to Peer-to-Peer Networks. Presentation for MIE456 - Information Systems Infrastructure II, October 30, 2003.

[2] Tom Chothia and Konstantinos Chatzikokolakis. A survey of anonymous peer-to-peer file-sharing, in Proc. EUC Workshops, 2005, pp.744-755.

[3] Baptiste Prétre. Attacks on Peer-to-Peer Networks, Dept. of Computer Science Swiss Federal Institute of Technology (ETH) Zurich Autumn 2005.

[4] P. Syverson, D. Goldschlag and M. Reed. Anonymous connections and onion routing. In Proceedings of the IEEE Symposium on Security and Privacy (1997).

[5] Clarke, O. Sandberg, B. Wiley, and T. W. Hong. Freenet: a distributed anonymous information storage and retrieval system. In Proc. of Privacy Enhancing Technologies, 2001.

[6] The MUTE home page, http://mute-net.sourceforge.net/, 2011.

[7] The Ants p2p home page, http://antsp2p.sourceforge.net/, 2011.

[8] Tomas Isdal, Michael Piatek, Arvind Krishnamurthy, and Thomas Anderson. Privacy-preserving P2P data sharing with OneSwarm. In Proc. of ACM SIGCOMM, September 2010.

[9] Alberto Ornaghi and Marco Vallerie. Man in the middle attacks demos. Blackhat conference-USA 2003.

[10] E. Rescorla. Diffie-Hellman Key Agreement Method, RFC 2631, IETF Network Working Group, http://www.ietf.org/rfc/rfc2631.txt, 2011.

[11] The PEERSIM home page, http://peersim.sourceforge.net/, 2011.

[12] Jem E. Berkes. Decentralized Peer-to-Peer Network Architecture: Gnutella and Freenet, University of Manitoba Winnipeg, Manitoba Canada, April 9, 2003.

557