1 / 22

Freenet

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

hazina
Download Presentation

Freenet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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.

  2. Goals & Properties • Anonymity for producers and consumers • Deniability for storers • Resistance to denial of service attacks • Efficient storage and routing • Decentralization Goals • 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 Properties

  3. 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.

  4. public key hash string key generation private key file key stored file file encrypt signature Keyword-signed key • 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)

  5. public key hash xor hash file key string hash private key stored file file encrypt signature Signed-subspace key • Notes: • retrieval requires (string, public key) • directory simulation through a file containing descriptive strings for other files

  6. hash file key stored file encrypt file random key Content-hash key Note: retrieval requires (file key, random key)

  7. indirect file (file key, random key) Updateable Files (1) insert using CHK (2) insert using SSK file (3) publish (public key, string) • Notes: • A combination of content-hash keys and signed-subspace keys • To update: • Insert new file using CHK method using new (file key, random key) • 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

  8. transaction ID hops-to-live depth payload • 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 • Set by sender to limit propogation • Decremented on each hop • When = 1, forwarded again with probability p Message Structure • 64 bit randomly generated • Used to prevent routing cycles request/reply

  9. (1) request (7) deliver file local node (3) send request using routing table (6) Update route table (2) check local store (4) file & source (5) cache local store Retrieval (key, hops-to-live) • 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 • Improved subsequent access • Redundancy improve fault tolerance

  10. Routing • 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

  11. file key (1) insert local node (3) send insert using routing table (5a) if file, update route table (2) check local store (4) file or OK (5b) If OK, send file (5a) if file, cache local store Insertion • 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

  12. Scalability

  13. Fault Tolerance

  14. Free Haven “…the Free Haven Project aims to design, implement, and deploy a functioning distributed anonymous storage service.” Dingledine et.al.

  15. 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

  16. 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) remailerreply 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

  17. Insertion • 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: <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>

  18. 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

  19. rem@isp usr@a rem@b server 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

  20. Anon-To: rem@b Encrypt-Key: key2 Encrypt with public key of rem@b Encrypt with public key of rem@isp replyblock-1 replyblock-2 Anon-To: rem@isp Encrypt-Key: key3 Constructing a reply block Anon-To: usr@a Encrypt-Key: key1

  21. cyphertext-A cyphertext-B message cyphertext-A cyphertext-B cyphertext-C sign; encrypt with nym public key encrypt with key3 encrypt with key2 encrypt with key1 Encryptions in transit

  22. server rem@isp rem@b usr@a cyphertext-C replyblock-2 replyblock-1 cyphertext-A cyphertext-B Flow of data

More Related