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
Si descrive qui 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.
E' 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.
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 d'interessamento
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 e 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 al tempo stesso per i produttori e 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 instradamento delle informazioni
- Decentramento di tutte le funzioni della rete
Il sistema è progettato per rispondere in forma adattiva a schemi d'uso,
spostando, riproducendo e cancellando i file con modalità trasparenti,
secondo le necessità, per offrire un servizio efficiente senza dover ricorrere
a ricerche broadcast o ad indici centralizzati delle collocazioni dei dati.
Non si intende garantire la memorizzazione permanente dei file, anche se
si auspica di riunire un numero sufficiente 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 gratuito su Sourceforge,
e una versione preliminare si può scaricare dal sito http://www.freenetproject.org/.
Il nucleo del sistema è il lavoro iniziale svolto dal primo autore
presso l'Università di Edimburgo[12].
In quest'area si possono identificare diverse branchie di attività correlate 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 utenti dell'informazione nel contesto 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 utenti dal logging del servizio stesso. Le tecniche
di recupero di informazioni private[10] danno garanzie molto più valide
agli utenti 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 questa 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 a un unico server come sorgente ultima delle informazioni.
Publius[30] aumenta la disponibilità distribuendo files come
porzioni ridondanti tra n webservers, 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.
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 ai loro magazzini di informazioni.
La conservazione 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 magazzino di informazioni 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 magazzino di informazioni non è una cache, poichè l'insieme dei magazzini di informazioni 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 abbandondare 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 magazzini di informazioni. E' per questo che tutti i file conservati sono criptati. Le procedure di crittazione usate non mirano a proteggere il file--questo sarebbe impossibile siccome 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 keys 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.
We performed simulations on a model of this system to give some
indications about its performance. Here we summarize the most
important results; for full details, see [21].
To test the adaptivity of the network routing, we created a test
network of 1000 nodes. Each node had a datastore size of 50 items and
a routing table size of 250 addresses. The datastores were
initialized to be empty, and the routing tables were initialized to
connect the network in a regular ring-lattice topology in which each
node had routing entries for its two nearest neighbors on either side.
The keys associated with these routing entries were set to be hashes
of the destination nodes' addresses. Using hashes has the useful
property that the resulting keys are both random and consistent (that
is, all references to a given node will use the same key).
Inserts of random keys were sent to random nodes in the network,
interspersed randomly with requests for randomly-chosen keys known to
have been previously inserted, using a hops-to-live of 20 for both.
Every 100 timesteps, a snapshot of the network was taken and its
performance measured using a set of probe requests. Each probe consisted
of 300 random requests for previously-inserted keys, using a hops-to-live
of 500. We recorded the resulting distribution of request
pathlengths, the number of hops actually taken before finding
the data. If the request did not find the data, the pathlength was
taken to be 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.
 |
We can see that the initially high pathlengths decrease rapidly over
time. In the beginning, few requests succeed at all, but as the network
converges, the median request pathlength drops to just six.
Next, we examined the scalability of a growing network. Starting from
a small network of 20 nodes initialized in the same manner as the previous
section, we added new nodes over time and measured the change in the request
pathlength.
Inserts and requests were simulated randomly as before. Every five
timesteps, a new node was created and added to the network by
simulating a node announcement message with hops-to-live of 10 sent
from it to a randomly-chosen existing node. The key assigned by this
announcement was taken to be the hash of the new node's address. Note
that this procedure does not necessarily imply a linear rate of
network growth, but rather a linear relationship between the request
rate and the growth rate. Since it seems likely that both rates will
be proportional to network size (yielding an exponential growth rate
in real, as opposed to simulated, time), we believe that this model is
justifiable.
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.
 |
We can see that the pathlength scales approximately logarithmically,
with a change of slope near 40,000 nodes. We posit that the slope
change is a result of routing tables becoming filled and could be
improved by adding a small number of nodes with larger routing tables.
Section 5.4 discusses this issue in more depth.
Where our routing tables were limited to 250 entries by the memory
requirements of the simulation, real Freenet nodes should easily be
able to hold thousands of entries. Nonetheless, even this limited
network appears capable of scaling to one million nodes with a median
pathlength of just 30. Note also that the network was grown continuously,
without any steady-state convergence period.
Finally, we considered the fault-tolerance of the network. Starting
with a network grown to 1000 nodes by the previous method, we
progressively removed randomly-chosen nodes from the network to simulate
node failures. Figure 4 shows the resulting
evolution of the request pathlength, averaged over ten trials.
Figure 4:
Change in request pathlength under network failure.
|
The network is surprisingly robust against quite large failures. The median
pathlength remains below 20 even when up to 30% of nodes fail.
Small-world model
The scalability and fault-tolerance characteristics of Freenet can be
explained in terms of a small-world network
model[<a
HREF="#Milgram">23,<a
HREF="#Watts">31,<a
HREF="#Huberman">22,<a
HREF="#Albert">3]. In a small-world network,
the majority of nodes have only relatively few, local, connections to other
nodes, while a small number of nodes have large, wide-ranging sets of
connections. Small-world networks permit efficient short paths
between arbitrary points because of the shortcuts provided by the
well-connected nodes, as evidenced by examination of Milgram's letter-passing
experiment[<a
HREF="#Milgram">23] and the Erdös number game cited by Watts
and Strogatz[<a
HREF="#Watts">31].
Is Freenet a small world? A key factor in the identification of a
small-world network is the existence of a scale-free power-law
distribution of links within the network, as the tail of such
distributions provides the highly-connected nodes needed to create
short paths. Figure 5 shows the average
distribution of links (i.e. routing table entries) in the 1000-node
Freenet networks used in the previous section.
Figure 5:
Distribution of link number among Freenet nodes.
|
We see that the distribution closely approximates a power law, except
for the anomalous point representing nodes with filled 250-entry
routing tables. When we used differently-sized routing tables, this
cutoff point moved but the power-law character of the distribution
remained the same.
In addition to providing short paths, the power-law distribution also
gives small-world networks a high degree of fault-tolerance. Random
failures are most likely to knock out nodes from the majority that
possess only a small number of connections. The loss of
poorly-connected nodes will not greatly affect routing in the network.
It is only when the number of random failures becomes high enough to
knock out a significant number of well-connected nodes that routing
performance will be noticeably affected.
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é 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é 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é 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é 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é 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é 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é il mittente del messaggio né 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à,
cosicché 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é 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é. Poiché 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é 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é 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é 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à. 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é 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.
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à.
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.
Questo materiale è basato parzialmente su lavori patrocinati da una
National Science Foundation Graduate Research Fellowship.
-
- 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
|