Author: hobx
Date: 2006-03-09 21:45:15 +0000 (Thu, 09 Mar 2006)
New Revision: 8205
Modified:
trunk/docs/fnet.tex
Log:
more bad writing
Modified: trunk/docs/fnet.tex
===================================================================
--- trunk/docs/fnet.tex 2006-03-09 19:26:02 UTC (rev 8204)
+++ trunk/docs/fnet.tex 2006-03-09 21:45:15 UTC (rev 8205)
@@ -1,5 +1,5 @@
\documentclass[11pt,a4paper]{article}
-%\documentclass[twoside,leqno,twocolumn]{article}
+%\documentclass[leqno,twocolumn]{article}
\usepackage[latin1]{inputenc}
\usepackage{amstext}
@@ -200,9 +200,9 @@
In order to maintain data integrity, keys are related to documents
they denote by cryptographic means. In particular Freenet uses keys
-that either a cryptographic hash of the document itself, or a
-cryptographic hash of a name and a public asymmetric crypto key (PK)
-with which the document is digitally signed.
+that either a cryptographic hash of the document itself, or the
+bitwise XOR of a hash of a name and the fingerprint of a public
+asymmetric cryptography key (PK) which the data is signed.
While proxying and caching a document, each node can thus verify the
integrity of the document. In first case, the node need only calculate
@@ -210,35 +210,72 @@
for. In the second case, the PK and name string are provided as
metadata with the document. When the node receives the document, it
checks that the name and PK hash to the key that it routed for, and
-then checks that PK verifies the signature on the data.
+then checks that PK verifies the signature on the data.
-The first type of key, called a Content-Hash Key (CHK), is used for
+The first type of key, called a Content Hash Key (CHK), is used for
large static pieces of data. Since the key is generated from the data,
it can neither be generated beforehand nor predicted by somebody who
does not have the data. However, such keys are still useful, for
example, when one document wishes to provide a link to a copy of an
explicit, static, document.
-The second type of key, know a Signature Verifying Key (SVK), allows
+The second type of key, known as a Signed Subspace Key (SSK), allows
several documents to be published by the holder of a single asymmetric
-private key/public key pair. For anybody who knows the PK, the holder
-of the key-pair has a private namespace in which he can publish signed
-documents. This is used to implement updating schemes - either by
-including a version in the name, or having the name include a date of
-publication.
+private key/public key-pair. As the name implies, the holder of the
+key-pair has a private subspace in which he can publish signed
+documents, by varrying the name part. This is used to implement
+updating schemes - either by including a version in the name, or
+having the name include a date of publication.
-In both cases, the key cannot be derived from a readable address. Thus
+In both cases, the entire key cannot be derived from a readable
+address (in the CHK case, the entire key is an unreadable binary
+string, and in the SSK case at least the subspace wide part is). Thus
finding documents in Freenet requires finding at least the publishers
PK in some way. No method for direct keyword searching is provided,
though some methods are possible\footnotemark.
\footnotetext{One method that has been used is to create the public
- key/private key pair for an SVK using a string as a seed to a known
+ key/private key pair for an SSK using a string as a seed to a known
PRNG. Then anybody who knows or guesses the string can derive the
public key necessary for querying for the data in the network. The
insecurity implied by this method is obvious however: they can also
- derive the private key needed to insert other data under the same name.}
+ derive the private key needed to insert other data under the same
+ name.}
+\subsection{Data formats and encryption}
+
+An important aspect of Freenet, that has been carried over from the
+previous versions to the current, is a complete system for encrypting,
+splitting, handling data. This occurs at a higher level than the
+Freenet nodes, in what has been designated the client (though in the
+spirit of peer-to-peer, the node and client are often the same
+program), and is thus unaffected by the change in how we treat the
+network. The Freenet nodes which route for, store, and fetch data only
+ever see atomic, encrypted, documents, which are processed by the
+client into plaintext reconstructed versions.
+
+Encryption of the data is typically done using symmetric encryption,
+the key being part of the address (in the case of the CHK) or the
+bitwise XOR of a subspace wide key and and a hash of the name part
+(using a different hash function than we use when deriving the routing
+key).
+
+The client also handles splitting and padding of data. As a basic
+measure to help a little againts profiling and traffic analysis,
+documents in Freenet must be an exponent of two bytes in size. Clients
+ensure this by padding, and also by splitting larger documents into
+many smaller parts. The latter process is also a performance
+enhancement: because the parts are inserted under different keys, they
+spread throughout the network which allows for effective multi-source
+downloading (in the style of newer peer-to-peer programs such as
+bittorrent) when downloading.
+
+As part of the splitting there is also an additional layer of
+redundancy, since the clients can use erasure codes to make sure that
+not all the parts are necessary to recreate the document. Freenet
+currently makes use of INSERT TYPE OF CODES WITH REFERENCE HERE.
+
+
\section{Routing in the Network}
Under the trusted connection model, we have to assume that the graph of
@@ -303,10 +340,11 @@
becomes one of trying affect the randomized assignment of identities
such that this becomes an efficient way of routing. The method we have
chosen for doing this is described in detail in [ref]. In a nutshell,
-nodes start with randomly selected identities, but switch with
-each other so that nodes that are ``close'' in the network topology
-also have nearby identities (it is only when this property holds that
-greedy routing makes sense in anything but the final step).
+nodes start with randomly selected identities seen as numbers between
+0 and 1, but switch with each other so that nodes that are ``close''
+in the network topology also have nearby identities (it is only when
+this property holds that greedy routing makes sense in anything but
+the final step).
Ideally, one would hope to be able to assign the identities so that
every step in a route for $K$ brings us to a node whose identity is
@@ -317,15 +355,68 @@
value of $m = 10$ is used, which is motivated by attempting to balance
a thorough search while limiting resource usage.
-\section{Redundancy and Fault Tolerance}
+\section{Joining and Leaving the Network}
+Technically, the system for joining and leaving the network is very
+simple. Nodes choose an identity at random, and then connect to those
+peers with whom they have a prestablished trusted relationship. To
+protect against man in the middle attacks, the connections are
+initiated by the exchange certificates between user - the certificates
+include both contact information (in practice, the nodes current IP
+address and port number) and cryptographic identifiers for the nodes.
+When a user imports a certificate his node will adds the certificate's
+host as a trusted peer, and attempt to contact it. The other node will
+only respond if it has the certificate of the node attempting to
+contact it. On failure to connect, nodes try again, letting the time
+between subsequent attempts increase exponentially.
+Once a new node has established connections to a set of trusted peers,
+it can start taking part in the routing. It starts taking part in the
+switching procedure described above so as to get an identity which
+suits it's position in the network and those of it's neighbors. Nodes
+may initially switch at a higher rate, so that they can be come useful
+to the routing as soon as possible.
-\section{Joining and Leaving the Network}
+In practice, it is of course unrealistic to expect nodes to join the
+network fully formed, with a complete set of trusted peers. One of the
+most important and difficult aspects of the project, from a usability
+perspective, is to make it sufficiently easy and profitable for users
+to create connections that the overlay graph really does reflect the
+underlyign social network. If, for instance, users only ever connect
+to one person when joining the network, the graph will become a tree,
+and the routing algorithm will fail completely. In the current, early,
+versions of the software, we are depending only on the promise of
+increased performance to encourage people to authenticate and connect
+to as many trusted peers as possible, but in the future other ways of
+encouraging this may be necessary (for example allowing the software
+to be used as an instant messaging client and/or fille sharing client
+with those one has authenticated).
-\bibliographystyle{unsrt
-}
+\section{Implementation}
+
+\section{Conclusion}
+
+We have described a new version of Freenet based on constructing an
+overlay using only trusted connections to build a distributed
+hashtable for use as a censorship resistant information publishing
+system. Much work still lies ahead in constructing this system,
+especially in testing it with a large user base, and seeing if peoples
+trusted connections in practice sufficiently match the small-world of
+theory to make communication in the network practical.
+
+In the course of developing the software, we have many question yet to
+answer about the viability of the system in the real world. The
+difficulty of performing denial of service attacks by attempting to
+affect the routing in various ways needs to be studied, and similarly
+attacks by flooding and spamming in order to decrease the avilability
+of legitimate data. However, we see our design as a proof of concept
+of an entirely new form of peer-to-peer overlay, which ensures privacy
+for all participants, while offering a robust alternative for building
+free communication networks even where they are not desired by all.
+
+
+\bibliographystyle{unsrt}
\bibliography{../tex/ossa}
\end{document}
