Los primeros trabajos Experimentando |

Our system consists of many identical peers, each of which can fulfil five different roles:

• Publisher p. The node which has a document and wishes to make it available and censorship resistant.

• Storer s. A node which stores part of a document.

• Forwarder a. A node which has an anonymous pointer to a node storing part of a document.

• Client c. A node which retrieves a document.

• Decrypter l. A node which decrypts part of a document and sends it off to the client.

The system is built on top of an existing Peer-to-Peer document storage service such as PAST [DR01]. PAST itself is built on top of Pastry [RD01], a Peer-to-Peer routing scheme. Pastry can be viewed as a network of machines (peers), each with a unique identifier. The only thing required to send a message to a machine is its id, furthermore, Pastry guarantees that the message takes around log N hops, where N is the number of nodes in the system. Using an existing Peer-to-Peer architecture allows us to abstract away routing, clients leaving and joining the network, and other low level issues.

On top of Pastry, PAST also provides robustness: neighbouring machines (machines within a certain distance of each other within a logical namespace) share state. This is further discussed below. We also assume a public key infrastructure, so any peer is able to learn any other peer’s public key. This is further discussed in Section 8.4. Finally, we make use of an anonymous connection system such as Mixminion [DDM03] which is capable of handling replies.

As usual in censorship resistant systems, the operations available to a node are publishing and retrieval. There is no search facility, therefore we rely on a broadcast

PSfrag replacements

p

a0 a1 a2 a3

s0 s1 s2 s3

h0 h1 h2 h3

Figure 8.1: Publishing. Zig-zag lines indicate anonymous connections. mechanism such as an anonymous newsgroup to transmit retrieval information to potential readers. We do not support content deletion or modification.

8.2.1 Publishing

The overall publishing process is illustrated in Figure 8.1. The main idea is to split the documents into many parts or shares hi, and store them (encrypted) on machines

si, while making them accessible through machines ai which forward requests for the

appropriate shares anonymously.

Publisher:

To publish a document (see Figure 8.2), the publisher p splits it into n + 1 shares hi,

any k + 1 of which can be combined to form the whole document again. This can be done using one of the standard algorithms such as Shamir’s secret sharing [Sha79]. He then generates n + 1 keys ki and encrypts each share with the corresponding key.

He now picks n + 1 peers a0. . . an at random to act as forwarders and constructs

onions to send (via the anonymous connections layer) each of them the encrypted share_{hi}ki, the corresponding key ki2 and a (large) random integer vi together with

a return address (reply onion)3 rp. The publisher can now wait for a confirmation to

come back from each of the ai’s (via the reply onion) saying whether the publishing

has been successful or not. If the operation failed, the publisher should try different ai’s.

2_Both

{hi}ki and ki are sent to minimize the work which has to be done by the forwarder.

3_{A return address is a kind of onion which, if included in an anonymous message, can be used to}

a)

b)

PSfrag replacements s0 s0 (v00,{h0}k0, ra0) ra0 f rs0 a0 a0 (v0 0,{h0}k0) (v00,{h0}k0) p p (v0, v00, k0,rfs0) (v0, v00, k0, rp) “ok” ({h0}k0, k0, v0, rp) rp Share h0 Key k0 Storer s0 Random numbers v0, v00 Return addresses rp,rfs0, ra0

Figure 8.2: Inserting share h0. All communication is done via the anonymous con-

nection system using randomly constructed onions. If the message is sent using a return address, it is displayed at the base of the arrow. Anonymous return addresses are denoted by r, e.g. ra0

PSfrag replacements s0 s0 (v₀0,{h0}k0, ra0) a0 a0 (v0₀,_{h0}k0) (v00,{h0}k0) (v0, v00, k0,rfs0) (v0, v00, k0,rfs0) rl ({h0}k0, v00) (v₀0, rl) rs0 (k0, r_a0, rc, v00) l l rl ra0 (v0, rc) c c rs0 r_c h0 h0 (k0, rc, v00) (k0, rc, v00) Share h0 Key k0 Storer s0 Client c Decrypter l Random numbers v0, v00 Return addresses ra0, rs0, rl,rfs0, rc Figure 8.3: Retrieval Forwarder:

The forwarder (all of them perform the same operation, here we use a0as an example)

receives the message, finding an encrypted share _{h0}k0, a key k0 and a random

number v0 and the publisher’s return address. He then picks a storer s0 to store

the share and a number v0₀ which the storer should associate the share with. He constructs an onion for delivering these to the storer. Thus, he puts the encrypted share, v0₀, as well as his own anonymous return address ra0 into the onion as the

message and sends it off (see Figure 8.2a). He remembers v0, v00, k0 and rp. When

the onion is received by s0, it stores the share and issues a number of different return

addresses rfs0 (to be used for retrieval), sending them back to a0 via the return

address ra0. Now a0 associates v0, v00 and k0 with the return addresses rfs0, forgets

s0, and replies “ok” to the publisher via rp. Once all the shares have been stored,

the publisher destroys them and announces the name of the file, together with the n + 1 pairs (ai, vi) to potential users.

8.2.2 Retrieval

To retrieve a document (see Figure 8.3), the client c asks the forwarder a0 (and

each ai in the same way) to retrieve the share h0 by sending them an anonymous

message with v0and their anonymous return address rc. The forwarder a0 then picks

a random server l to act as a decrypter and sends it k0, the key it is storing which

decrypts the stored share, v₀0, rc, and a return address ra0, getting back a return

address for l. Now a0 forwards rl and v00, which identifies the share, to s0 via one of

ther_fs0 (rs0). Now s0 looks up the encrypted share corresponding to v00 and forwards

it and v0₀ to l, which decrypts the share and sends it to the client via rc. The process

continues until c has accumulated enough shares to reconstruct the document. We note that when the forwarder starts running out of return addresses for the storer (you can use each one only once), all the forwarder needs to do is request some more via one of the return addresses it still has.

The other important detail which we have so far left out of the description of the system is that the Peer-to-Peer storage layer (PAST) replicates state among neigh- bouring nodes. This enables requests to be routed to any of the nodes which contain the replicated state. In particular, the forwarder shares (v0, v00, k0,rfs0) with neigh-

bouring nodes which can therefore also answer requests. Similarly, the storer shares (v₀0,_{h0}k0). The decrypter does not need to share anything as he will only get one

request to decrypt the share and will then give up this role.

In document Jóvenes, delito, educación y trabajo : Aportes al análisis de la cotidianeidad de jóvenes en situación de vulnerabilidad socio-penal en la ciudad de Viedma, provincia de Río Negro (página 128-132)