Freenet “…an adaptive peer-to-peer network application that permits the publication, replication, and retrieval of data while protecting the anonymity of both authors and readers.” Clarke, et.al.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Freenet
“…an adaptive peer-to-peer network application that permits the publication, replication, and retrieval of data while protecting the anonymity of both authors and readers.” Clarke, et.al.
Goals & Properties
• Anonymity for producers and consumers
• Deniability for storers
• Resistance to denial of service attacks
• Efficient storage and routing
• Decentralization
• Whole file is the unit of storage • No guarantee of permanent storage• Operates at application layer• Files named by location-independent keys• Transparent lazy replication
Goa
lsP
rope
rtie
s
Assigning a Key
• keyword-signed key : key is derived from a short descriptive string chosen by the user when the file is inserted into the system
• signed-subspace key : key is derived from the public key generated by the user; creates a personal namespace
• content-hash key : key is derived from hashing the file’s contents
Note: content-hash key and signed-subspace key can be used with an indirection mechanism to handle updatable files.
Keyword-signed key
key generationstring
private key
public key hash
file key
file
signature
encrypt
stored file
Note: retrieval requires only “string”
Problems resulting from “flat” name space:• Collisions (different users selecting same string for different files)• Key-squatting (junk files in popularly named positions)
Signed-subspace key
string
public key hash
file key
encrypt
stored file
private key
file
signature
hash
hash
xor
Notes: •retrieval requires (string, public key)•directory simulation through a file containing descriptive strings for other files
Content-hash key
random key
file key
encrypt
stored file
file
hash
Note: retrieval requires (file key, random key)
Updateable Files
Notes:• A combination of content-hash keys and signed-subspace keys• To update:
1. Insert new file using CHK method using new (file key, random key)2. Insert new indirect file using original (public key, string)
• Key collisions on indirect file causes older version to be discarded• Old version of file still available using its (file key, random key) index• Technique can also be used to split large files into parts
file
(1) insert using CHK
(file key, random key)
indirect file
(2) insert using SSK
(3) publish (public key, string)
Message Structure
•Incremented at each hop•Used to set hops-to-live in response•Initialized to small random value•When =1, not automatically incremented with probability p
transaction ID hops-to-live depth payload
•Set by sender to limit propogation•Decremented on each hop•When = 1, forwarded again with probability p
•64 bit randomly generated•Used to prevent routing cycles request/reply
Retrieval (key, hops-to-live)
local node
localstore
(1) request
(2) check local store
(3) send request using routing table
(5) cache
(4) file & source
(6) Update route table
(7) deliver file
Notes:
• Request contains (key, hops-to-live)• Any node on reply path can change source to
be itself or any other node• File cached at all nodes along return path
1. Improved subsequent access2. Redundancy improve fault tolerance
key1 node1
key2 node2
… …
Notes:• Each node maintains routing table• Route request to node which has the closest lexicographic matching key• Use depth-first-search with backtracing• Table entries added as new files acquired by the node
routing table
Routing
Insertion
local node
localstore
(1) insert
(2) check local store
(3) send insert using routing table
(5a) if file, cache
(4) file or OK
(5a) if file, update route table
file key
(5b) If OK, send file
Notes:• Inserted file stored at all nodes along search path• Any node on path can change the source to itself or any other node• Inserts announce the existence of the node• Attempts to insert junk files are rejected and the real file is further propagated
Scalability
Fault Tolerance
Free Haven
“…the Free Haven Project aims to design, implement, and deploy a
functioning distributed anonymous storage service.” Dingledine et.al.
Forms of Anonymity
• Anonymity of agents (authors, publishers, readers, and servers) – no link between the agent and a given document
• Document anonymity – servers do not know what documents they store
• Query anonymity – servers do not know the identity of documents which satisfies a users request
Structure
• Documents (file)– Each document is divided into shares– Each document is assigned an expiration date
• Servers– Community of servers – servnet– Each server has a persistent identification – pseudonym– Each server exposes a public key and a (set of) remailer reply
blocks– Each server has a database of the public keys and the remailer
reply blocks of all other servers– Servers form contracts to store shares for a specified interval of
time– Fulfilling a contract increases that server’s reputation
Insertion
<share><PKdoc> ce41f889d7569704e89edbdddf243662d8c784</PKdoc><sharenum> 1 </sharenum><totalshares> 100 </totalshares><sufficientshares> 60 </sufficientshares><expiration> 2000-06-11-22:25:24</expiration><data> … </data><signature> …digital signature of above… </signature></share>
• A file F is broken into shares f1, …, fn where k (<n) shares are needed to reconstruct the file• A key pair (PKdoc, SKdoc) is generated for F• Each share is signed• All shares of a given file are indexed by Hash(PKdoc)
Possible share representation:
Retrieval
• Reader– Generates (PKclient, SKclient) key pair for the transaction– Generates a one-time remailer reply block (rrb)– Broadcast request (H(PKdoc), PKclient, rrb) to all servers
• Server– Checks for availability of any shares with index of
H(PKdoc)– Encrypts each found share with PKclient
– Sends each encrypted share using rrb
Remailer Reply Blocks
Goal: a sender is provided by a receiver (nym) with the means to transmit a message to that receiver such that the sender has no knowledge of the actual receiver
rem@isp usr@a rem@b server
Constructing a reply block
Anon-To: usr@aEncrypt-Key: key1
Encrypt with public key of rem@b Anon-To: rem@b
Encrypt-Key: key2
replyblock-1
Anon-To: rem@ispEncrypt-Key: key3
replyblock-2
Encrypt with public key of rem@isp
Encryptions in transit
message
cyphertext-A
sign; encrypt with nym public key
encrypt with key3
cyphertext-B
cyphertext-A
encrypt with key2
cyphertext-C
cyphertext-B
encrypt with key1
Flow of data
replyblock-2
cyphertext-A
server usr@arem@isp rem@b
cyphertext-Creplyblock-1
cyphertext-B
Related Documents
