I've been thinking about the big picture of how to meet Freenet's goals, and have a possibly new idea about a mixnet.built using the Freenet routing algorithm. Since it isn't Freenet, let's call it FreeMixNet.
It uses the following features of Freenet routing: (1) Resistance to censorship of fixed keys. A key can be published, become notorious, and still be accessible anonymously. The authorities can request and receive the key but cannot know the physical identity of the node which provided it. (2) Trust based on proof of providing access to keys. Each node on the insert routing chain verifies the claim of the previous node that it has access to the key before proceeding with routing, and each node on the request routing chain verifies the claim of the next node that it has obtained access before returning access to the preceding node. (3) Routing of queries (inserts and requests) strictly according to the key. (4) No shortcut return of results. Once the key is found, it is returned along the path the request traversed (less any dead ends). There might be some other properties of Freenet routing which will need to be used but which are not mentioned above However, FreeMixNet is not Freenet. A routing key is not the hash of a file. Instead, it is the hash of a DSA/RSA/other public key. Queries are addressed to the public key, which is hashed to get the routing key. The "holder" of a key knows the corresponding private key and can answer challenges proving that he knows the private key. Certain keys are "notorious." No FreeMixNet node will ever be caught routing a notorious key. This is accomplished by refusing any such request which comes over a non-anonymous connection. Requests which arrive over anonymous connections are only routed over other anonymous connections. A mole node which seeks to gather evidence to convict a particular physical node of anonymously routing notorious keys will have great difficulty, because it must discover the actual endpoint of an anonymous connection. To do this, it must compromise all of the intermediate nodes along the connection. Inserting a key consists of announcing "I have an open connection to the holder of the inserted key." The announcer gives his identity either by IP and port (a non-anonymous insert), or as another key (the "announcing" key, an anonymous insert). Each node which receives an insert request must challenge the announcer to prove it has the announced connection by answering a query which can only be answered by the holder of the inserted key. To do this, the node needs to establish a connection to the announcer, if it doesn't already have one. If the announcer specified his identity by key, then the node must request that key and establish an anonymous connection to it. Otherwise, the node makes a non-anonymous connection to the specified IP and port. This verification process is performed by each node along the routing chain until the storage node (the node where the network will tend to look for the key) is reached. The storage node also verifies the connection, and then records the key and the connection in its datastore. There may be any number of connections for a given key recorded. A successful request for a key eventually results in an anonymous encrypted open connection to the holder of the key, through which arbitrary communication can take place. The first step is for a node to issue a request. Requests can be anonymous or non-anonymous. Non-anonymous requests are never for notorious keys. They are issued directly by a node to one of the nodes in its non-anonymous routing table. The requesting node may or may not be the originator of the request, and always has plausible deniability that it is the originator. Anonymous requests are issued over an anonymous connection. Either or both endpoint nodes might be moles, but neither knows the physical identity of the other. Endpoint nodes of an anonymous connection know only the key of the other endpoint. Mole nodes can and will notice when a non-notorious key makes a request for a notorious key, and they might add the guilty key to the notorious list. The guilty node will simply generate a new key pair and establish anonymous connections under the new identity. The list of notorious keys will soon grow very large. Non-mole nodes will of course attempt to identify the mole nodes, but this is difficult, and is perhaps not even important. When a response is returned, each node along the routing chain has to verify that it can connect to the holder of the requested key. The response may specify any number of near endpoints, and each node must test these until one succeeds. Of course, the routing node will first test the endpoints it already has connections to. After obtaining this connection, the requester would usually send a message over the connection asking the remote end to issue a request for another key. If that request is successful, the requester could usefully insert the second key from his location. When the network first starts up, nodes begin by inserting their own keys, announcing "I (a node at IP:port) have an open connection to the inserted key (which might be their own key, but they never would admit as much)." Soon thereafter, they will be inserting keys for other connections they have established. Once a sufficient number of anonymous connections are established, it will be safe to begin announcing and requesting notorious keys. Through the use of anonymous connections, FreeMixNet nodes can keep their physical IP's secret from most of the other nodes. If any particular node has only a few neighbors, and none of them are moles, then the node can keep secret even the fact that it is running FreeMixNet. Comments? -- Edward J. Huff <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
