Prima Pagina

Curiosi
- Cos'è Freenet
- Aiutateci !
- Le persone
- Articoli
- Filosofia
- Traduzioni

Utenti
- Download
- Documentazione
- FAQ
- Applicazioni terze parti
- Segnala un baco
- Mailing Lists

Autori
- Pubblicare

Sviluppatori
- Documentazione
- Architettura
- Area pubblica
- Registratevi!

Login & Edit

Hosted by
SourceForge


Freenet: Un sistema anonimo distribuito di memorizzazione e ricerca di informazioni

Ian Clarke
Uprizer, Inc.
1007 Montana Ave., #323
Santa Monica, CA 90403
USA
ian@octayne.com
Oskar Sandberg
Department of Numerical Analysis and Computer Science
Royal Institute of Technology
SE-100 44 Stockholm
Sweden
md98-osa@nada.kth.se
Brandon Wiley
College of Communication
University of Texas at Austin
Austin, TX 78712
USA
blanu@uts.cc.utexas.edu
Theodore W. Hong[*]
Department of Computing
Imperial College of Science, Technology and Medicine
180 Queen's Gate, London SW7 2BZ
United Kingdom
t.hong@doc.ic.ac.uk

Testo approvato il 1° luglio 2000
Rivisto il 18 dicembre 2000


Sunto:

Viene descritta Freenet, un'applicazione adattiva peer-to-peer in rete che consente di pubblicare, riprodurre e ricercare dati salvaguardando l'anonimato degli autori e dei lettori. Freenet opera come una rete di nodi identici che, collettivamente, mettono in comune il loro spazio di memoria per memorizzare file di dati e cooperano tra di loro per inoltrare le richieste verso le più probabili collocazioni fisiche dei dati stessi. Non vengono utilizzati né la ricerca broadcast né un indice centralizzato delle collocazioni dei dati; il riferimento ai file avviene secondo una modalità indipendente dalle collocazioni, ed i file vengono riprodotti dinamicamente in località vicine ai richiedenti e cancellati dalle località dove non si riscontra interesse. È impossibile scoprire la vera origine o destinazione di un file in transito nella rete, ed è difficile per un operatore di un nodo determinare o attribuirgli la responsabilità del contenuto concreto del suo nodo.




Introduzione

I sistemi computerizzati in rete stanno acquistando sempre maggiore importanza come mezzo preferito per memorizzare e scambiare informazioni. Tuttavia, i sistemi attuali offrono ai loro utenti scarsa privacy e, di norma, memorizzano ogni elemento dei dati soltanto in uno o pochi posti fissi, creando un punto debole centrale. Gli autori ed i lettori desiderano però salvaguardare la propria privacy riguardo a vari tipi d'informazioni delicate[28], ed è inopportuno che vi siano punti deboli centrali, sui quali potrebbe intervenire chi voglia danneggiare il sistema togliendogli dati[11,27] o che, semplicemente, potrebbero rivelarsi sovraccarichi in caso di carico eccessivo[1]; sono quindi necessari sistemi che offrano maggiore sicurezza e affidabilità.

Noi stiamo sviluppando Freenet, un sistema distribuito di memorizzazione e di ricerca d'informazioni, che intende soddisfare queste esigenze di privacy e di disponibilità. Freenet opera come file system distribuito ed indipendente dalla collocazione, attraverso numerosi singoli computer, che consentono di immettere, memorizzare e ricercare i file anonimamente. Gli obiettivi principali di questo progetto sono cinque:

  • Anonimato sia per i produttori chee per i fruitori delle informazioni
  • Immunità per chi mantiene le informazioni
  • Resistenza a tentativi di terzi di negare l'accesso alle informazioni
  • Efficacia nella memorizzazione dinamica e nell'instradamento delle informazioni
  • Decentramento di tutte le funzioni della rete

Il sistema è progettato per rispondere in forma adattiva all'utilizzo, spostando, duplicando e cancellando i file in maniera trasparente secondo le necessità, per offrire un servizio efficiente senza dover ricorrere a ricerche broadcast o ad indici centralizzati delle posizioni dei dati. Non si intende garantire la memorizzazione permanente dei file, anche se si auspica di riunire un numero di nodi aventi capacità di memorizzazione sufficiente per poter conservare a tempo indeterminato la massima parte dei file. Inoltre, il sistema opera al livello delle applicazioni e, pur essendo indipendente dal trasporto, presume la presenza di uno strato di trasporto sicuro. Scopo del sistema è preservare l'anonimato non per l'utilizzo generale della rete ma soltanto per le operazioni con i file di Freenet.

Freenet è attualmente in sviluppo come progetto di software libero su Sourceforge, ed una versione preliminare si può scaricare dal sito http://www.freenetproject.org/. L'origine del sistema è il lavoro iniziale svolto dal primo autore presso l'Università di Edimburgo[12].

Attività correlate

In quest'area si possono identificare diversi settori di attività correlati a Freenet. Il remailer Mixmaster[13] per le email, l'onion routing[19] e Freedom[32] per il traffico tcp/ip generico hanno implementato i canali punto-punto anonimi basati sullo schema mix-net di Chaum[8] Tuttavia questi canali non sono in sè facilmente adattabili alla pubblicazione "uno a molti" e sono meglio visti come complemento a Freenet, dal momento che non supportano l'accesso a file e l'archiviazione.

L'anonimato per gli utilizzatori dell'informazione nel web è fornito da servizi di proxy da browser come Anonymizer[6], sebbene questi non forniscono protezione per chi offre l'informazione e non proteggono gli utilizzatori dal logging del servizio stesso. Le tecniche di recupero di informazioni private[10] danno garanzie molto più valide agli utilizzatori dell'informazione, ma solo per quel che concerne il nascondere quale porzione dell'informazione è stata recuperata e da quale specifico server. In molti casi, il fatto stesso di contattare un particolare server può rivelare ulteriori dati sull'informazione stessa recuperata, e questo sarebbe inutile solo se ogni server mantenesse tutte le informazioni (naturalmente questo ha poco peso). Il lavoro più vicino al nostro è il sistema Crowds di Reiter e Rubin[25], che usa un metodo simile di richieste proxy per gli utenti, sebbene Crowds in sè non memorizza informazioni e non protegge chi offre l'informazione. Berthold et al. propone Web MIXes[7], un sistema più forte che, per aumentare la sicurezza, utilizza il message padding (infarcimento dei messaggi), la riordinazione e i messaggi finti, ma ancora non protegge chi offre l'informazione.

Il Rewebber[26] fornisce un grado di anonimato a chi offre informazioni web per mezzo di un servizio di URL criptate che è essenzialmente l'inverso del proxy da browser, ma con lo stesso limite di non fornire protezione contro la facoltà di "intervento" da parte del servizio stesso. TAZ[18] estende quest'idea utilizzando catene di URL criptate nidificate che puntano a diversi server rewebber contattati in successione, tuttavia questo è vulnerabile all'analisi del traffico utilizzando il "replay". Entrambi si affidano ad un unico server come sorgente ultima delle informazioni. Publius[30] aumenta la disponibilità distribuendo file come porzioni ridondanti tra n webserver, dei quali solo k sono necessari per ricostruire un file; Tuttavia, dal momento in cui l'identità degli stessi server non è anonima, un aggressore potrebbe rimuovere le informazioni forzando la chiusura di n-k+1 servers. La proposta The Eternity [5] mira ad archiviare informazioni permanentemente e in modo anonimo, sebbene manchi di specifiche su come localizzare efficentemente i files archiviati e risultando così più simile a un servizio di backup anonimo. Free Haven[14] è un interessante sistema di pubblicazione anonima che fa uso di una rete fidata e un meccanismo di scambio file per fornire una maggiore responsabilità dal lato server mantenendo l'anonimato.

Distributed.net[15] ha dimostrato il concetto di associazione in larga scala di risorse CPU tra i computer di molti utenti; Altri sistemi che fanno lo stesso, ma per lo spazio disco, sono Napster[24] e Gnutella[17]; il primo si affida a un server centrale per localizzare i files e il secondo impiega un'inefficiente ricerca broadcast. Nessuno dei due replica i files. Intermemory[9] e India[16] sono sistemi cooperanti di fileserver distribuito, pensati per l'archiviazione di dati a lungo termine secondo il concetto di Eternity, per cui i files sono divisi in porzioni ridondanti e distribuiti tra svariati partecipanti. Akamai[2] fornisce un servizio che replica i files nelle aree in cui si trovano gli utenti che ne usufruiscono, ma non è adeguato per chi volesse offrire il servizio a livello individuale (non come organizzazione). Nessuno di questi sistemi cerca di fornire anonimato.

Architecture

Freenet is implemented as an adaptive peer-to-peer network of nodes that query one another to store and retrieve data files, which are named by location-independent keys. Each node maintains its own local datastore which it makes available to the network for reading and writing, as well as a dynamic routing table containing addresses of other nodes and the keys that they are thought to hold. It is intended that most users of the system will run nodes, both to provide security guarantees against inadvertently using a hostile foreign node and to increase the storage capacity available to the network as a whole.

The system can be regarded as a cooperative distributed filesystem incorporating location independence and transparent lazy replication. Just as systems such as distributed.net[15] enable ordinary users to share unused CPU cycles on their machines, Freenet enables users to share unused disk space. However, where distributed.net uses those CPU cycles for its own purposes, Freenet is directly useful to users themselves, acting as an extension to their own hard drives.

The basic model is that requests for keys are passed along from node to node through a chain of proxy requests in which each node makes a local decision about where to send the request next, in the style of IP (Internet Protocol) routing. Depending on the key requested, routes will vary. The routing algorithms for storing and retrieving data described in the following sections are designed to adaptively adjust routes over time to provide efficient performance while using only local, rather than global, knowledge. This is necessary since nodes only have knowledge of their immediate upstream and downstream neighbors in the proxy chain, to maintain privacy.

Each request is given a hops-to-live limit, analogous to IP's time-to-live, which is decremented at each node to prevent infinite chains. Each request is also assigned a pseudo-unique random identifier, so that nodes can prevent loops by rejecting requests they have seen before. When this happens, the immediately-preceding node simply chooses a different node to forward to. This process continues until the request is either satisfied or exceeds its hops-to-live limit. Then the success or failure result is passed back up the chain to the sending node.

No node is privileged over any other node, so no hierarchy or central point of failure exists. Joining the network is simply a matter of first discovering the address of one or more existing nodes through out-of-band means, then starting to send messages.


Keys and searching

Files in Freenet are identified by binary file keys obtained by applying a hash function. Currently we use the 160-bit SHA-1[4] function as our hash. Three different types of file keys are used, which vary in purpose and in the specifics of how they are constructed.

The simplest type of file key is the keyword-signed key (KSK), which is derived from a short descriptive text string chosen by the user when storing a file in the network. For example, a user inserting a treatise on warfare might assign it the description, text/philosophy/sun-tzu/art-of-war. This string is used as input to deterministically generate a public/private key pair. The public half is then hashed to yield the file key.

The private half of the asymmetric key pair is used to sign the file, providing a minimal integrity check that a retrieved file matches its file key. Note however that an attacker can use a dictionary attack against this signature by compiling a list of descriptive strings. The file is also encrypted using the descriptive string itself as a key, for reasons to be explained in section 3.4.

To allow others to retrieve the file, the user need only publish the descriptive string. This makes keyword-signed keys easy to remember and communicate to others. However, they form a flat global namespace, which is problematic. Nothing prevents two users from independently choosing the same descriptive string for different files, for example, or from engaging in "key-squatting"--inserting junk files under popular descriptions.

These problems are addressed by the signed-subspace key (SSK), which enables personal namespaces. A user creates a namespace by randomly generating a public/private key pair which will serve to identify her namespace. To insert a file, she chooses a short descriptive text string as before. The public namespace key and the descriptive string are hashed independently, XOR'ed together, and then hashed again to yield the file key.

As with the keyword-signed key, the private half of the asymmetric key pair is used to sign the file. This signature, generated from a random key pair, is more secure than the signatures used for keyword-signed keys. The file is also encrypted by the descriptive string as before.

To allow others to retrieve the file, the user publishes the descriptive string together with her subspace's public key. Storing data requires the private key, however, so only the owner of a subspace can add files to it.

The owner now has the ability to manage her own namespace. For example, she could simulate a hierarchical structure by creating directory-like files containing hypertext pointers to other files. A directory under the key text/philosophy could contain a list of keys such as text/philosophy/sun-tzu/art-of-war, text/philosophy/confucius/analects, and text/philosophy/nozick/anarchy-state-utopia, using appropriate syntax interpretable by a client. Directories can also recursively point to other directories.

The third type of key is the content-hash key (CHK), which is useful for implementing updating and splitting. A content-hash key is simply derived by directly hashing the contents of the corresponding file. This gives every file a pseudo-unique file key. Files are also encrypted by a randomly-generated encryption key. To allow others to retrieve the file, the user publishes the content-hash key itself together with the decryption key. Note that the decryption key is never stored with the file but is only published with the file key, for reasons to be explained in section 3.4.

Content-hash keys are most useful in conjunction with signed-subspace keys using an indirection mechanism. To store an updatable file, a user first inserts it under its content-hash key. She then inserts an indirect file under a signed-subspace key whose contents are the content-hash key. This enables others to retrieve the file in two steps, given the signed-subspace key.

To update a file, the owner first inserts a new version under its content-hash key, which should be different from the old version's content hash. She then inserts a new indirect file under the original signed-subspace key pointing to the updated version. When the insert reaches a node which possesses the old version, a key collision will occur. The node will check the signature on the new version, verify that it is both valid and more recent, and replace the old version. Thus the signed-subspace key will lead to the most recent version of the file, while old versions can continue to be accessed directly by content-hash key if desired. (If not requested, however, these old versions will eventually be removed from the network--see section 3.4.) This mechanism can be used to manage directories as well as regular files.

Content-hash keys can also be used for splitting files into multiple parts. For large files, splitting can be desirable because of storage and bandwidth limitations. Splitting even medium-sized files into standard-sized parts (e.g. 2n kilobytes) also has advantages in combating traffic analysis. This is easily accomplished by inserting each part separately under a content-hash key, and creating an indirect file (or multiple levels of indirect files) to point to the individual parts.

All of this still leaves the problem of finding keys in the first place. The most straightforward way to add a search capability to Freenet is to run a hypertext spider such as those used to search the web. While an attractive solution in many ways, this conflicts with the design goal of avoiding centralization. A possible alternative is to create a special class of lightweight indirect files. When a real file is inserted, the author could also insert a number of indirect files each containing a pointer to the real file, named according to search keywords chosen by her. These indirect files would differ from normal files in that multiple files with the same key (i.e. search keyword) would be permitted to exist, and requests for such keys would keep going until a specified number of results were accumulated instead of stopping at the first file found. Managing the likely large volume of such indirect files is an open problem.

An alternative mechanism is to encourage individuals to create their own compilations of favorite keys and publicize the keys of these compilations. This is an approach also in common use on the world-wide web.


Retrieving data

To retrieve a file, a user must first obtain or calculate its binary file key. She then sends a request message to her own node specifying that key and a hops-to-live value. When a node receives a request, it first checks its own store for the data and returns it if found, together with a note saying it was the source of the data. If not found, it looks up the nearest key in its routing table to the key requested and forwards the request to the corresponding node. If that request is ultimately successful and returns with the data, the node will pass the data back to the upstream requestor, cache the file in its own datastore, and create a new entry in its routing table associating the actual data source with the requested key. A subsequent request for the same key will be immediately satisfied from the local cache; a request for a "similar" key (determined by lexicographic distance) will be forwarded to the previously successful data source. Because maintaining a table of data sources is a potential security concern, any node along the way can unilaterally decide to change the reply message to claim itself or another arbitrarily-chosen node as the data source.

If a node cannot forward a request to its preferred downstream node because the target is down or a loop would be created, the node having the second-nearest key will be tried, then the third-nearest, and so on. If a node runs out of candidates to try, it reports failure back to its upstream neighbor, which will then try its second choice, etc. In this way, a request operates as a steepest-ascent hill-climbing search with backtracking. If the hops-to-live limit is exceeded, a failure result is propagated back to the original requestor without any further nodes being tried. Nodes may unilaterally curtail excessive hops-to-live values to reduce network load. They may also forget about pending requests after a period of time to keep message memory free.

Figure 1 depicts a typical sequence of request messages. The user initiates a request at node a. Node a forwards the request to node b, which forwards it to node c. Node c is unable to contact any other nodes and returns a backtracking "request failed" message to b. Node b then tries its second choice, e, which forwards the request to f. Node f forwards the request to b, which detects the loop and returns a backtracking failure message. Node f is unable to contact any other nodes and backtracks one step further back to e. Node e forwards the request to its second choice, d, which has the data. The data is returned from d via e and b back to a, which sends it back to the user. The data is also cached on e, b, and a.

Figure 1: A typical request sequence.

This mechanism has a number of effects. Most importantly, we hypothesize that the quality of the routing should improve over time, for two reasons. First, nodes should come to specialize in locating sets of similar keys. If a node is listed in routing tables under a particular key, it will tend to receive mostly requests for keys similar to that key. It is therefore likely to gain more "experience" in answering those queries and become better informed in its routing tables about which other nodes carry those keys. Second, nodes should become similarly specialized in storing clusters of files having similar keys. Because forwarding a request successfully will result in the node itself gaining a copy of the requested file, and most requests will be for similar keys, the node will mostly acquire files with similar keys. Taken together, these two effects should improve the efficiency of future requests in a self-reinforcing cycle, as nodes build up routing tables and datastores focusing on particular sets of keys, which will be precisely those keys that they are asked about.

In addition, the request mechanism will cause popular data to be transparently replicated by the system and mirrored closer to requestors. For example, if a file that is originally located in London is requested in Berkeley, it will become cached locally and provide faster response to subsequent Berkeley requests. It also becomes copied onto each computer along the way, providing redundancy if the London node fails or is shut down. (Note that "along the way" is determined by key closeness and does not necessarily have geographic relevance.)

Finally, as nodes process requests, they create new routing table entries for previously-unknown nodes that supply files, increasing connectivity. This helps new nodes to discover more of the network (although it does not help the rest of the network to discover them; for that, the announcement mechanism described in section 3.5 is necessary). Note that direct links to data sources are created, bypassing the intermediate nodes used. Thus, nodes that successfully supply data will gain routing table entries and be contacted more often than nodes that do not.

Since keys are derived from hashes, lexicographic closeness of keys does not imply any closeness of the original descriptive strings and presumably, no closeness of subject matter of the corresponding files. This lack of semantic closeness is not important, however, as the routing algorithm is based on knowing here keys are located, not where subjects are located. That is, supposing a string such as text/philosophy/sun-tzu/art-of-war yields a file key AH5JK2, requests for this file can be routed more effectively by creating clusters containing AH5JK1, AH5JK2, and AH5JK3, not by creating clusters for works of philosophy. Indeed, the use of hashes is desirable precisely because philosophical works will be scattered across the network, lessening the chances that failure of a single node will make all philosophy unavailable. The same is true for personal subspaces--files belonging to the same subspace will be scattered across different nodes.


Storing data

Inserts follow a parallel strategy to requests. To insert a file, a user first calculates a binary file key for it, using one of the procedures described in section 3.1. She then sends an insert message to her own node specifying the proposed key and a hops-to-live value (this will determine the number of nodes to store it on). When a node receives an insert proposal, it first checks its own store to see if the key is already taken. If the key is found, the node returns the pre-existing file as if a request had been made for it. The user will thus know that a collision was encountered and can try again using a different key. If the key is not found, the node looks up the nearest key in its routing table to the key proposed and forwards the insert to the corresponding node. If that insert causes a collision and returns with the data, the node will pass the data back to the upstream inserter and again behave as if a request had been made (i.e. cache the file locally and create a routing table entry for the data source).

If the hops-to-live limit is reached without a key collision being detected, an "all clear" result will be propagated back to the original inserter. Note that for inserts, this is a successful result, in contrast to situation for requests. The user then sends the data to insert, which will be propagated along the path established by the initial query and stored in each node along the way. Each node will also create an entry in its routing table associating the inserter (as the data source) with the new key. To avoid the obvious security problem, any node along the way can unilaterally decide to change the insert message to claim itself or another arbitrarily-chosen node as the data source.

If a node cannot forward an insert to its preferred downstream node because the target is down or a loop would be created, the insert backtracks to the second-nearest key, then the third-nearest, and so on in the same way as for requests. If the backtracking returns all the way back to the original inserter, it indicates that fewer nodes than asked for could be contacted. As with requests, nodes may curtail excessive hops-to-live values and/or forget about pending inserts after a period of time.

This mechanism has three effects. First, newly inserted files are selectively placed on nodes already possessing files with similar keys. This reinforces the clustering of keys set up by the request mechanism. Second, new nodes can use inserts as a supplementary means of announcing their existence to the rest of the network. Third, attempts by attackers to supplant existing files by inserting junk files under existing keys are likely to simply spread the real files further, since the originals are propagated on collision. (Note, however, that this is mostly only relevant to keyword-signed keys, as the other types of keys are more strongly verifiable.)


Trattamento dei dati

Tutti i sistemi di conservazione delle informazioni devono tenere in considerazione il problema della capacità finita di conservare informazioni. I singoli gestori del nodo di Freenet possono configurare la grandezza dello spazio da dedicare alla memorizzaione dei dati (datastore). La conservazione da parte dei nodi ` trattata come una Cache LRU (Least Recently Used, ovvero usato meno di recente ndt) [29] nella quale i singoli dati sono mantenuti ordinati in ordine decrescente per data della più recente richiesta (o data di inserimento, se una voce non è mai stata richiesta). Quando arriva un nuovo file (o grazie a un nuovo inserimento o per una richiesta andata a buon fine) che potrebbe far aumentare la dimensione del gli utilizzatori oltre la grandezza stabilita, i file usati meno di recente sono espulsi in ordine fino a che si crea lo spazio. Il risultante impatto sulla disponibilità è mitigato dal fatto che le voci della tabella di routing create quando i file espulsi sono arrivati per la prima volta rimarranno per un certo tempo, permettendo potenzialmente al nodo di procurarsi successivamente altre copie dalle fonti di dati originali. (Le voci della tabella di routing, infine, vengono anche cancellate in maniera simile quando la tabella si riempie, anche se saranno conservate più a lungo se sono più piccole.)

A voler essere precisi, il datastore non è una cache, poiché l'insieme dei datastore sono tutte le informazioni che sono lì. Cioè, non c'è una copia "permanente" che viene replicata in una cache. Una volta che tutti i nodi hanno deciso, parlando collettivamente, di eliminare un determinato file, esso non sarà più disponibile per la rete. Riguardo a ciò, Freenet è diversa dai sistemi come Eternity e Free Haven che cercano di dare garanzie sui tempi di vita dei file.

Il meccanismo della scadenza ha un aspetto svantaggioso, comunque, poiché permette che i documenti vecchi svaniscano naturalmente dopo esser stati rimpiazzati da documenti più nuovi. Se un documento vecchio è ancora usato e considerato prezioso per ragioni storiche, resterà in vita fino a quando continuerà ad essere richiesto.

Per ragioni politiche o legali, può essere desiderabile per gli operatori dei nodi non conoscere esplicitamente i contenuti dei loro datastore. È per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file; questo sarebbe impossibile poiché chi fa una richiesta (potenzialmente chiunque) deve essere capace di decrittare il file una volta ricevuto. Piuttosto, la finalità è che il gestore di un nodo possa credibilmente negare ogni conoscenza del contenuto del suo magazzino di dati, poiché tutto ciò che sa a priori è la file key, non la encryption key. Le encryption keys per i dati keyword-signed e signed-subspace possono essere ottenute solo con un procedimento di reverse su un hash, e le encryption keys per i dati content-hash non sono affatto correlate. Con una certa difficoltà, naturalmente, un attacco basato sul dizionario svelerà quali chiavi sono presenti--poiché esso lo deve fare per le richieste per poter funzionare-- ma la fatica che un tale tentativo richiederebbe è intesa a fornire una misura di protezione per i gestori del nodo.


Aggiungere nodi

Un nuovo nodo può unirsi alla rete scoprendo l'indirizzo di uno o più nodi esistenti attraverso canali fuori banda, e poi incominciando a mandare messaggi. Come detto precedentemente, il meccanismo di richiesta abilita naturalmente i nuovi nodi a imparare più cose della rete nel corso del tempo. Comunque, per far scoprire questi dai nodi preesistenti, i nuovi nodi devono in qualche modo annunciare la loro presenza. Questo processo è reso complicato da due requisiti in qualche modo in conflitto. Da una parte per promuovere un routing efficiente, ci piacerebbe che tutti i nodi esistenti fossero lineari nel decidere quali keys mandare ad un nuovo nodo (cioè quale key assegnare ad esso nelle loro tabelle di routing). D'altra parte, causerebbe un problema di sicurezza se qualunque nodo potesse scegliere la routing key, il che esclude il sistema più lineare di raggiungere la coerenza.

Usiamo un protocollo crittografico per soddisfare entrambi questi requisiti. Un nuovo nodo che si unisce alla rete sceglie un seed a caso e manda un messaggio di annuncio che contiene il suo indirizzo e l'hash di quel seed a qualche nodo esistente. Quando un nodo riceve un annuncio di un nuovo nodo, genera un seed a caso e lo XOR-a con l'hash che ha ricevuto, e calcola nuovamente un hash del risultato per creare un vincolo. Esso poi inoltra il nuovo hash a qualche nodo scelto a caso dalla sua tabella di routing. Questo processo continua fino a che le hops-to-live della comunicazione finiscono. L'ultimo nodo che riceve l'annuncio genera semplicemente un seed. Ora tutti i nodi in catena rivelano i loro seeds e la key per il nuovo nodo è assegnata come il XOR di tutti i seeds. Controllare i vincoli abilita ogni nodo a confermare che ognuno ha reso pubblici i loro seeds sinceramente. Questo produce una conseguente key scelta a caso, che non può essere influenzata da un partecipante malizioso. Ogni nodo poi aggiunge una voce per il nuovo nodo nella sua tabella di routing sotto quella key.


Dettagli del protocollo

Il protocollo Freenet è packet-oriented e usa messaggi self-contained. Ogni messaggio include un transaction ID cosicché i nodi possono tracciare lo stato di inserimenti e richieste. Questo design è pensato per permettere flessibilità nella scelta del meccanismo di trasporto per i messaggi, se sia TCP, UDP, o altre tecnologie come packet radio. Per l'efficienza, i nodi che usano un canale persistente come una connessione TCP possono anche mandare messaggi multipli sulla stessa connessione. Gli indirizzi dei nodi consistono in un metodo di trasporto più un identificatore transport-specific come un indirizzo IP e un numero di porta, ad esempio tcp/192.168.1.1:19114. I nodi che cambiano indirizzo frequentemente possono anche usare indirizzi virtuali conservati sotto address-resolution keys (ARK's), che sono signed-subspace keys aggiornate per contenere il vero indirizzo corrente.

Una transazione di Freenet inizia con un messaggio di Request.Handshake da un nodo a un altro, che specifica l'indirizzo di ritorno desiderato del nodo inviante.[*] (L'indirizzo di ritorno del mittente può essere impossibile da determinare automaticamente per il transport layer, o il mittente puo` desiderare di ricevere risposte a un indirizzo diverso da quello usato per mandare il messaggio.) Se un nodo remoto è attivo e risponde alle richieste, risponderà con una Reply.Handshake che specifica il numero di versione del protocollo che esso riesce a capire. Le handshakes vengono mantenute in memoria per qualche ora, e nelle transazioni seguenti tra gli stessi nodi durante questo tempo si potrà saltare questo passaggio.

Tutti i messaggi contengono una transaction ID di 64-bit generata a caso, un limite di hops-to-live, e un contatore di profondità. Sebbene non si possa garantire che l'ID sia unico, la probabilità di una collisione durante il tempo della transazione tra il limitato insieme di nodi che vede è estremamente bassa. Le hops-to-live sono stabilite dalla fonte del messaggio e vengono diminuite a ogni passaggio per prevenire la possibilità che il messaggio venga inoltrato indefinitamente. Per ridurre le informazioni che una persona che tenta di attaccare può ottenere dal valore delle hops-to-live, i messaggi non terminano automaticamente quando le hops-to-live raggiungono 1 ma sono inoltrati con probabilità finite (ancora con hops-to-live 1). La profondità è aumentata ad ogni passaggio ed è usata da un nodo che risponde per stabilire un hops-to-live abbastanza alta da raggiungere un requestor. I requestor dovrebbero inizializzarlo a un piccolo valore a caso per oscurare la loro ubicazione. Come con le hops-to-live, una profondità di 1 non è automaticamente incrementata ma viene passata senza cambiamenti con probabilità finite.

Per richiedere i dati, i nodi invianti mandano un messaggio di Request.Data specificando un transaction ID, le hops-to-live iniziali e la profondità, e una search key. Il nodo remoto cercherà la key nel suo magazzino di informazioni e se non viene trovata, inoltrerà la richiesta a un altro nodo come descritto nella sezione 3.2.

Usando il limite di hops-to-live scelto, il nodo inviante fa partire un timer per la quantità di tempo prevista per contattare quei nodi, dopodiché supporrà un fallimento. Mentre la richiesta avviene, il nodo remoto può periodicamente mandare indietro messaggi Reply.Restart che indicano che i messaggi si sono bloccati aspettando timeouts della rete, cosicché il nodo inviante sa di dover estendere il suo timer.

Se la richiesta è portata a termine con successo, il nodo remoto risponderà con un messaggio Send.Data che contiene i dati richiesti e l'indirizzo del nodo che lo ha fornito (è possibile che esso sia falso). Se la richiesta non è portata a termine con successo e le sue hops-to-live sono state usate completamente cercando di soddisfarla, il nodo remoto risponderà con un NotFound?. Il nodo inviante allora decrementerà le hops-to-live del Send.Data (o del NotFound?) e lo passerà, a meno che esso sia il vero originatore della richiesta. Entrambi questi messaggi termino la transazione e lasciano ogni risorsa che occupavano. Comunque, se ci sono ancora hops-to-live rimanenti, di solito perché la richiesta è andata verso un vicolo cieco dove non c'è nessun sentiero che non genera un loop, il nodo remoto risponderà con una Request.Continue dando il numero di hops-to-live rimanenti. Il nodo inviante allora tenterà di contattare il prossimo nodo dalla sua tabella di routing. Esso manderà anche un messaggio Reply.Restart.

Per inserire dati, il nodo inviante invia un messaggio Request.Insert specificando un transaction ID generato a caso, un hops-to-live e profondità iniziale, e una key proposta. Il nodo remoto cercherà la key nel suo magazzino di informazioni e se non la troverà, inoltrerà l'inserzione a un altro nodo come descritto nella sezione 3.3. I timers e i messaggi Reply.Restart vengono anche usati alla stessa maniera delle richieste.

Se l'inserzione infine genera una collisione tra key, il nodo remoto risponderà o con un messaggio Send.Data contenente i dati esistenti o con un NotFound? (se i dati esistenti non sono stati trovati, ma i riferimenti ad essi nelle tabelle di routing sono stati trovati). Se l'inserzione non incontra una collisione ma finisce i nodi con un numero di hops-to-live rimanenti diverso da zero, il nodo remoto risponderà con un Request.Continue. In questo caso, Request.Continue è un risultato di fallimento che significa che non è stato possibile contattare tanti nodi quanti sono stati richiesti. Questi messaggi verranno passati come nel caso della richiesta. Entrambi i messaggi terminano la transazione e lasciano ogni risorsa che occupavano. Comunque, se l'inserzione scade senza incontrare una collisione, il nodo remoto risponderà con un Reply.Insert, indicando che l'inserzione può andare avanti. Il nodo inviante passer` la Reply.Insert e aspetterà che i suoi predecessori inviino un Send.Insert che contenga i dati. Quando riceve i dati, lo conserverà in locale e inoltrer` il flusso Send.Insert, concludendo la transazione.

Analisi delle prestazioni

Abbiamo eseguito delle simulazioni su un modello di questo sistema per ottenere alcune indicazioni sulle prestazioni ottenibili. Di seguito troverete i risultati più importanti; per avere dettagli completi, guarda [21].

Convergenza della rete

Per testare l'adattività del routing di rete, abbiamo creato un network di 1000 nodi. Ogni nodo permette la memorizzazione di 50 "oggetti" all'interno del proprio datastore e, la gestione di 250 indirizzi nella propria tabella di routing. Ogni datastore è stato inizializzato con valori di default uguali a NULL, e le tabelle di routing secondo una configurazione che prende il nome di "lattice finito" in cui ogni nodo mantiene all'interno della propria tabella, gli indirizzi dei due nodi ad esso più "vicini". Le chiavi associate a questi indirizzi sono state create utilizzando l'hash degli stessi indirizzi remoti. Utilizzare una funzione di hash, ci consente di avere chiavi che sono casuali e consistenti (ogni riferimento ad un dato nodo utilizza la stessa chiave).

Abbiamo inviato alcune richieste di inserimento di chiavi casuali ad altrettanti nodi scelti in modo accidentale, intercalate con alcune richieste (inviate sempre a nodi scelti a caso) per chiavi di cui sapevano già che era stato effettuato l'inserimento (la "profondità" del campo Hops-To-Live è stato impostato a 20 sia per i messaggi di inserimento che per quelli di richiesta). Ogni 100 "passaggi", l'intera rete è stata analizzata al fine di ricavare le prestazioni offerte dall'attuale struttura, utilizzando un set di richieste-prova. Ogni prova consisteva nella richiesta di 300 chiavi precedentemente inserite utilizzando un HTL di 500. Registrando i risultati cosí acquisiti, abbiamo potuto disegnare il grafico degli "hop" richiesti (lunghezza del percorso), prima di trovare i dati. Se la richiesta non andava a buon fine, la lunghezza del percorso la impostavamo a 500.

Figure 2 shows the evolution of the first, second, and third quartiles of the request pathlength over time, averaged over ten trials.

Figure 2: Time evolution of the request pathlength.
<img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img3.gif">

Possiamo vedere come la lunghezza dei percorsi iniziali, inizialmente elevata, decresca rapidamente nel tempo. All'inizio poche richieste di fatto vengono soddisfatte, ma mentre la rete converge, la media della lunghezza delle richieste, crolla a 6.

Scalabilità

Successivamente, abbiamo analizzato la scalabilità di una rete "nascente". Partendo da 20 nodi, inizializzati nel modo visto prima, abbiamo aggiunto nodi con il passare del tempo e misurato il cambiamento nelle "lunghezze del cammino" per raggiungere i dati.

Inserimenti e Richieste sono stati simulati casualmente come visto prima. Ogni cinque passaggi, un nuovo nodo è stato creato e aggiunto alla rete simulando un "node announcement" con un HTL di 10 inviato ad un nodo già esistente. La chiave assegnata da questo "annuncio" è stata scelta come l'hash dell'indirizzo del nuovo nodo. Notate che questa procedura non implica necessariamente una tasso lineare nella crescita della rete, ma piuttosto una relazione lineare tra il tasso di richieste e il tasso di crescita.

Figure 3 shows the evolution of the first, second, and third quartiles of the request pathlength versus network size, averaged over ten trials.

Figure 3: Request pathlength versus network size.

Possiamo notare come i "passi" necessari a raggiungere i dati tendono a crescere, in numero, secondo una funzione logaritmica, con un repentino cambio intorno ai 40.000 nodi. Abbiamo supposto che questo cambiamento (crollo) improvviso sia dovuto al completo riempimento delle tabelle di routing e puó essere facilmente eliminato inserendo alcuni nodi con tabelle decisamente piú "ampie". La sezione 5.4 discute queste questioni piú in dettaglio. Mentre le tabelle di routing da noi utilizzate per la simulazione sono limitate a 250 record, i nodi Freenet reali dovrebbero facilmente contenere migliaia di record. Non di meno val la pena far notare, che anche con una rete così limitata, riusciamo a scalare ad un milione di nodi con un percorso medio di 30 salti.

Fault-tolerance

Per concludere, abbiamo considerato la fault-tolerance del network. Partendo dalla rete di 1000 nodi ottenuta dal metodo precedente, abbiamo progressivamente rimosso (a caso...) alcuni nodi al fine di simularne il guasto degli stessi. La figura 4 mostra il cambiamento dei pathlengh dopo una decina di prove.

Figure 4: Change in request pathlength under network failure.
<img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img5.gif" ALT="\begin{figure}\centerline{ \psfig{figure=03freenet4.eps,width=12cm} } \end{figure}">

La rete è sorprendentemente robusta anche dopo numerosi nodi "guasti". Il pathlenght medio rimane sotto 20 anche con il 30% di nodi falliti.


Small-world model

La scalabilità e le caratteristiche fault-tolerance di Freenet possono essere spiegate in termini di un modello di rete small-world [<a HREF="#Milgram">23,<a HREF="#Watts">31,<a HREF="#Huberman">22,<a HREF="#Albert">3]. In una rete "small-world", la maggioranza dei nodi presenti hanno poche connessioni locali con gli altri nodi, mentre un esiguo numero di nodi possiede un numero elevato e largamente distribuito di connessioni. Una rete "Small-world" permette di avere "tracciati corti" tra punti arbitrari della rete grazie alle connessioni locali della maggioranza dei nodi (come si diceva sopra), come evidenziato dall'esperimento di Milgram [<a HREF="#Milgram">23] e il "gioco dei numeri di Erdös" spiegato da Watts e Strogatz[<a HREF="#Watts">31].

Si può affermare che Freenet è una rete "small-world" ? Un fattore chiave per l'identificazione di una rete "small-world" è l'esistenza di una "distribuzione esponenziale" del numero dei link tra i nodi della rete che induce l'esistenza di nodi "altamente" connessi a forzare brevi percorsi tra di essi. La figura 5 mostra la distribuzione media dei link in una rete Freenet di 1000 nodi utilizzata nella sessione precedente.

Figure 5: Distribution of link number among Freenet nodes.
<img WIDTH="582" HEIGHT="421" BORDER="0" SRC="/images/icsi-img6.gif" ALT="\begin{figure}\centerline{ \psfig{figure=03freenet5.eps,width=12cm} } \end{figure}">

Possiamo vedere come la distribuzione si avvicini ad un andamento esponenziale, eccetto per un punto "anomalo" dovuto al riempimento delle tabelle di routing. Nel momento in cui utilizziamo tabelle di routing di differente capacità, questo punto "critico" si sposta rimanendo invariata il carattere esponenziale della distribuzione.

Oltre a ridurre il "cammino" minimo per raggiungere i dati, la distribuzione esponenziale da ad una rete "small-world" un alto grado di fault-tolerance. I fallimenti casuali di fatto eliminano dalla rete quei nodi che non posseggono un piccolo numero di connessioni. La perdita di nodi "poco connessi", non incidono piú di tanto il processo di routing all'interno della rete. Solo quando il fallimento (guasto n.d.t) di molti nodi comincia a crescere (eliminando dalla rete un significativo numero di nodi "ben connessi"), le performance subiscono un degrado importante.


Sicurezza

L'obiettivo primario della sicurezza di Freenet è proteggere l'anonimato di coloro che richiedono o inseriscono file. Inoltre è importante proteggere l'identità di coloro che fisicamente memorizzano le informazioni. Anche se chiunque può banalmente fare in modo che un nodo memorizzi un dato file, richiedendolo attraverso quel nodo, ciò che è importante è che quel file resti memorizzato anche presso altri nodi non identificabili, in modo che non sia possibile rimuovere il file da Freenet tentando di attaccare tutti i nodi che lo possiedono. I file debbono essere protetti dalla modifica delierata ed il sistema, infine, deve essere resistente ad attacchi di tipo denial-of-service.

Reiter e Rubin[<a HREF="#Reiter">25] propongono un'interessante tassonomia delle proprietà della comunicazione anonima su tre assi. Il primo asse è rappresenta il tipo di anonimato: anonimato del mittente o del destinatario, il che significa rispettivamente che un nemico non può identificare chi ha originato il messaggio o chi è supposto riceverlo. Il secondo asse è il nemico in questione: un intercettatore locale, un nodo maligno o un insieme di nodi maligni coordinati, o un server web (quest'ultimo caso non si applica a Freenet). Il terzo asse è il grado di anonimato, che varia da "riservatezza assoluta" (impossibilità di rilevare il fatto che la comunicazione avviene) a "oltre ogni sospetto" (il vero mittente non ha maggior probabilità di essere identificato come tale rispetto ad altri mittenti potenziali), a "innocenza probabile" (il fatto che il vero mittente sia tale non è più probabile del fatto che non lo sia), a "innocenza possibile", "smascherato", "smascherato con le prove" (il nemico può dimostrare ad altri chi è il mittente).

Poich&eacute la comunicazione su Freenet non è diretta a destinatari specifici, l'anonimato del ricevente può essere interpretato come la riservatezza della chiave, ovvero il celare la chiave che viene richiesta o inserita. Purtroppo, poich&eacute l'instradamento dipende dalla conoscenza della chiave, la riservatezza della chiave non può essere ottenuta con lo schema Freenet di base (vedi però la discussione sul 'pre-routing' più sotto). L'uso di funzioni hash come chiavi permette di difendersi contro l'intercettazione casuale, ma è vulnerabile ad attacchi a dizionario poich&eacute la versione originale della chiave deve essere nota per poter essere utile.

Le proprietà di anonimato di Freenet sulla base di questa tassonomia sono illustrate nella tabella 1.

Table 1: Proprietà di anonimato in Freenet.
Sistema Nemico Anonimato del mittente Riservatezza della chiave
Schema Freenet di base intercettatore locale smascherato smascherato
insieme di nodi maligni oltre ogni sospetto smascherato
Freenet + pre-routing intercettatore locale smascherato oltre ogni sospetto
insieme di nodi maligni oltre ogni sospetto smascherato


Contro un insieme di nodi maligni, l'anonimato del mittente è preservato oltre ogni sospetto poich&eacute un nodo sul percorso di richiesta non è capace di riconoscere se il nodo che lo precede ha originato la richiesta o la sta semplicemente inoltrando. [<a HREF="#Reiter">25] descrive un attacco di tipo probabilistico che potrebbe compromettere l'anonimato del mittente, effettuando un'analisi statistica della probabilità che una richiesta che arriva al nodo a sia inoltrata o gestita direttamente e della probabilità che a scelga un particolare nodo b per inoltrare la richiesta. Tale analisi non è comunque applicabile direttamente a Freenet, poich&eacute i percorsi di richiesta non sono costruiti in modo stocastico. L'inoltro della richiesta dipende dal fatto che a abbia o meno il dato richiesto nel datastore più che da fattori random. Se una richiesta viene inoltrata, le tabelle di instradamento determinano dove questa viene inviata e potrebbe essere il caso che a inoltri tutte come nessuna richiesta a b. In ogni caso, il valore di "depth" può fornire alcune indicazioni sulla distanza del nodo di origine, anche se è nascosta dalla selezione casuale della "depth" iniziale e del suo incremento condotto in modo randomico (vedi paragrafo 4). Considerazioni simili si possono applicare agli "hops-to-live". Saranno necessari ulteriori studi per chiarire queste questioni.

Non vi è protezione dei messaggi contro l'intercettazione sul percorso tra l'utente e il primo nodo. Poich&eacute il primo nodo può agire da intercettatore, si raccomanda che l'utente impieghi un nodo sulla propria macchina come punto d'entrata sulla rete Freenet. I messaggi tra nodi successivi sono crittati contro l'intercettazione, ma è comunque possibile effettuare un'analisi del traffico (ad esempio si può osservare un messaggio uscente senza un precedente messaggio entrante e concludere che quel messaggio è stato generato localmente).

La riservatezza delle chiavi ed una più forte protezione dell'anonimato del mittente possono essere ottenute introducendo un "pre-routing" dei messaggi del tipo di quello utilizzato in mix. In questo schema, i messaggi Freenet di base vengono crittati con una sequenza di chiavi pubbliche che determinano il percorso che il messaggio seguirà (bypassando il normale meccanismo di instradamento). I nodi lungo il percorso non possono determinare n&eacute il mittente del messaggio n&eacute il suo contenuto (inclusa la chiave di richiesta), come nel caso di mix. Quando il messaggio raggiunge il punto terminale della fase di pre-routing, esso viene inserito nella rete Freenet e si comporta come se fosse stato originato localmente.

La protezione per la sorgente dei dati è assicurata dalla riscrittura occasionale del campo sorgente nelle risposte. Il fatto che un nodo sia indicato come sorgente per una data chiave non implica necessariamente che esso abbia effettivamente fornito i dati, o che sia anche stato contattato nel corso della richiesta. Non è possibile decidere se il nodo a valle abbia fornito il file o abbia semplicemente inoltrato una richiesta generata da qualcun altro. Infatti, il solo richiedere con successo un file fa in modo che questo venga memorizzato nel nodo a valle se non c'era di gi&agrave, cosicch&eacute un successivo esame di quel nodo non rivela niente sullo stato precedente, e fornisce una base legale per affermare che un certo dato non era presente prima che venisse richiesto all'atto dell'investigazione. La richiesta di un dato con un "hops-to-live" di 1 non rivela direttamente se il nodo avesse precedentemente memorizzato il dato, poich&eacute continuano con probabilità finita ad inoltrare messaggi con hops-to-live pari ad 1. La conclusione con successo di un consistente numero di richieste di file correlati può fornire tuttavia una base per sospettare che tali file si trovassero memorizzati localmente in precedenza.

La modifica di un file da parte di un nodo maligno che si trovi sulla catena di richiesta costituisce una grave; minaccia, e non solo per l'integrità del file in s&eacute. Poich&eacute le tabelle di instradamenteo sono basate sulle risposte alle richieste, un nodo potrebbe tentare di indirizzare il traffico verso se stesso facendo finta di possedere file che non ha e rispondendo semplicemente con dati fittizi. Per dati memorizzati sotto chiavi content-hash o signed-subspace, questo non è attuabile poich&eacute dati non autentici possono essere rilevati, a meno che un nodo non trovi una coincidenza di hash od abbia successo nel contraffare una firma crittografica. I dati memorizzati sotto chiavi keyword-signed sono comunque vulnerabili ad attacchi a dizionario, poich&eacute possono essere firmati da chiunque conosca la stringa descrittiva originale.

Infine, si può prevedere un certo numero di attacchi di tipo denial-of-service. La minaccia più grave è che un utente cerchi di saturare la capacità di memorizzazione della rete con l'inserimento di grandi quantità di dati non significativi. Un'interessante possibilità di contrastare questi attacchi è l'uso di schemi come l'Hash Cash [<a HREF="#Hash">20]. Fondamentalmente, questo schema richiede che colui che inserisce un dato debba effettuare un'elaborazione complessa come "tassa" per l'inserimento, in modo da rallentare l'attacco. Un'altra alternativa è quella di suddividere il datastore in due parti, una per i nuovi inserimenti ed una per i file "stabili", che hanno cioè già ricevuto un certo numero di richieste. I nuovi inserimenti possono solo rimpiazzare altri file "nuovi". In questo modo, l'inserimento massiccio di dati non significativi può solo paralizzare temporaneamente le operazioni di inserimento, ma non causare la rimozione di file importanti. Risulta infatti difficile "legittimare" artificialmente i dati mediante ripetute richieste, poich&eacute tutte le richieste verranno soddisfatte dal primo nodo contenente i file e non procederanno oltre. D'altra parte, non è possibile interrogare direttamente i nodi a valle poiché non se ne conosce l'identit&agrave. In ogni caso, l'adozione di questo schema può compromettere la sopravvivenza di dati legittimi per un tempo lungo abbastanza da renderli stabili.

Si può tentare di rimpiazzare file esistenti inserendo versioni diverse di essi sotto le stesse chiavi. Questo tipo di attacco non è possibile per chiave content-hash o signed-subspace, poich&eacute richiede una coincidenza di hash o la falsificazione di una firma crittografica. Un attacco di questo tipo contro una chiave keyword-signed, d'altra parte, può portare alla coesistenza delle due versioni nella rete. Le modalità con cui i nodi trattano le collisioni (vedi descrizione dettagliata nel paragrafo 3.3) sono tali da rendere questi attacchi più difficili. Il successo di un attacco a rimpiazzo può essere misurato con il rapporto tra il numero di versioni originali del file e il numero di versioni corrotte presenti nel sistema. In ogni caso, maggiore è il numero di copie corrotte che si tenta di diffondere (impostando un alto hops-to-live nell'inserimento), maggiore è la probabilità che si realizzi una collisione, il che causa l'incremento del numero di copie originali.

Conclusioni

La rete Freenet fornisce un affidabile mezzo di memorizzazione e recupero anonimo di informazioni. Mediante l'uso di nodi cooperanti diffusi su molti computer insieme ad un efficiente algoritmo adattativo di instradamento, essa mantiene anonima e disponibile l'informazione mantenendo un'alta scalabilit&agrave. La fase di test sta avendo fino ad ora un discreto successo, con decine di migliaia di copie del software scaricate e molti file in circolazione. A causa della natura anonima del sistema, è impossibile decidere con esattezza quanti utenti vi siano o quali siano le prestazioni dei meccanismi di inserimento e richiesta, ma le impressioni sono state finora positive. Stiamo lavorando sulla realizzazione di un sistema di simulazione e visualizzazione che permetterà di effettuare prove più rigorose sul protocollo e sul meccanismo di instradamento. È necessaria nna simulazione più è realistica che tenga conto degli effetti di nodi che entrano ed escono dalla rete, della variazione della capacità e della larghezza di banda dei nodi, e di dimensioni maggiori della rete. Sarebbe inoltre desiderabile realizzare una struttura a chiave pubblica per l'autenticazione dei nodi in modo da creare un meccanismo di ricerca.

Ringraziamenti

Questo materiale è basato parzialmente su lavori patrocinati da una National Science Foundation Graduate Research Fellowship.

Bibliografia

1.
S. Adler, "The Slashdot effect: an analysis of three Internet publications," Linux Gazette issue 38, March 1999.

2.
Akamai, http://www.akamai.com/ (2000).

3.
R. Albert, H. Jeong, and A. Barabási, "Error and attack tolerance of complex networks," Nature 406, 378-382 (2000).

4.
American National Standards Institute, American National Standard X9.30.2-1997: Public Key Cryptography for the Financial Services Industry - Part 2: The Secure Hash Algorithm (SHA-1) (1997).

5.
R.J. Anderson, "The Eternity service," in Proceedings of the 1st International Conference on the Theory and Applications of Cryptology (PRAGOCRYPT '96), Prague, Czech Republic (1996).

6.
Anonymizer, http://www.anonymizer.com/ (2000).

7.
O. Berthold, H. Federrath, and S. Köpsell, "Web MIXes: a system for anonymous and unobservable Internet access," in Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, USA. Springer: New York (2001).

8.
D.L. Chaum, "Untraceable electronic mail, return addresses, and digital pseudonyms," Communications of the ACM 24(2), 84-88 (1981).

9.
Y. Chen, J. Edler, A. Goldberg, A. Gottlieb, S. Sobti, and P. Yianilos, "A prototype implementation of archival intermemory," in Proceedings of the Fourth ACM Conference on Digital Libraries (DL '99), Berkeley, CA, USA. ACM Press: New York (1999).

10.
B. Chor, O. Goldreich, E. Kushilevitz, and M. Sudan, "Private information retrieval," Journal of the ACM 45(6), 965-982 (1998).

11.
Church of Spiritual Technology (Scientology) v. Dataweb et al., Cause No. 96/1048, District Court of the Hague, The Netherlands (1999).

12.
I. Clarke, "A distributed decentralised information storage and retrieval system," unpublished report, Division of Informatics, University of Edinburgh (1999). Available at http://www.freenetproject.org/ (2000).

13.
L. Cottrell, "Frequently asked questions about Mixmaster remailers," http://www.obscura.com/~loki/remailer/mixmaster-faq.html (2000).

14.
R. Dingledine, M.J. Freedman, and D. Molnar, "The Free Haven project: distributed anonymous storage service," in Proceedings of the Workshop on Design Issues in Anonymity and Unobservability, Berkeley, CA, USA. Springer: New York (2001).

15.
Distributed.net, http://www.distributed.net/ (2000).

16.
D.J. Ellard, J.M. Megquier, and L. Park, "The INDIA protocol," http://www.eecs.harvard.edu/~ellard/India-WWW/ (2000).

17.
Gnutella, http://gnutella.wego.com/ (2000).

18.
I. Goldberg and D. Wagner, "TAZ servers and the rewebber network: enabling anonymous publishing on the world wide web," First Monday 3(4) (1998).

19.
D. Goldschlag, M. Reed, and P. Syverson, "Onion routing for anonymous and private Internet connections," Communications of the ACM 42(2), 39-41 (1999).

20.
Hash Cash, http://www.cypherspace.org/~adam/hashcash/ (2000).

21.
T. Hong, "Performance," in Peer-to-Peer, ed. by A. Oram. O'Reilly: Sebastopol, CA, USA (2001).

22.
B.A. Huberman and L.A. Adamic, "Growth dynamics of the world-wide web," Nature 401, 131 (1999).

23.
S. Milgram, "The small world problem," Psychology Today 1(1), 60-67 (1967).

24.
Napster, http://www.napster.com/ (2000).

25.
M.K. Reiter and A.D. Rubin, "Anonymous web transactions with Crowds," Communications of the ACM 42(2), 32-38 (1999).

26.
The Rewebber, http://www.rewebber.de/ (2000).

27.
M. Richtel and S. Robinson, "Several web sites are attacked on day after assault shut Yahoo," The New York Times, February 9, 2000.

28.
J. Rosen, "The eroded self," The New York Times, April 30, 2000.

29.
A.S. Tanenbaum, Modern Operating Systems. Prentice-Hall: Upper Saddle River, NJ, USA (1992).

30.
M. Waldman, A.D. Rubin, and L.F. Cranor, "Publius: a robust, tamper-evident, censorship-resistant, web publishing system," in Proceedings of the Ninth USENIX Security Symposium, Denver, CO, USA (2000).

31.
D. Watts and S. Strogatz, "Collective dynamics of `small-world' networks," Nature 393, 440-442 (1998).

32.
Zero-Knowledge Systems, http://www.zks.net/ (2000).


Note
...4<a NAME="foot15" HREF="#tex2html1">[*]
Il lavoro di Theodore W. Hong è supportato da alcuni grants da parte di the Marshall Aid Commemoration Commission and the National Science Foundation.

... sending<a NAME="foot128" HREF="#tex2html7">[*]
Ricorda che il nodo a monte può o meno essere il richiedente originale.


About this document ...

Freenet: A Distributed Anonymous Information Storage and Retrieval System

This document was generated using the LaTeX2HTML translator Version 99.2beta6 (1.42)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 0 -nofootnode -nonavigation -local_icons -dir icsi theoppr.tex

The translation was initiated by Theodore Hong on 2001-01-16



Theodore Hong