Hi all, (Note, I'm crossposting to devl and tech lists - please reply to tech...)
I've been thinking about the issues surrounding file sharing and anonymous communication in general. One difficult issue with Freenet is that merely running the protocol on the Internet may open people to attack in some jurisdictions. Additionally, file sharing is currently a controversial legal topic (e.g. Napster trial). I would like to propose a solution to this issue - a layer between Freenet and TCP/IP. This layer would be encrypted, anonymous and reusable. Such an infrastructure would have general applicability and would have "substantial non-infringing uses". If such a layer is widely adopted, it would shield controversial algorithms from direct attack. I'm attaching a text version of the proposal. It's also available at http://www.hyper.to/~devrandom/RNet.html . I have additional ideas regarding a distributed/secure DNS system, etc.. ** R-Net ===== Motivation ---------- The purpose of R-Net is to provide a secure, and anonymous network infrastructure. Such a network will enable higher-level protocols, such as anonymous messaging, E-Mail, WWW, filesharing and others. Both the client and the server can choose to be anonymous. Goals ----- Client and server anonymity Resistance to passive and active attacks by resourceful adversaries (multiple wiretaps, disruption and insertion). Efficiency Acknowledgements ---------------- Based on PipeNet http://www.eskimo.com/~weidai/pipenet.txt The Model ---------- Consider a network of processors which send messages to each other asynchronously. We assume that each node is identified by its public key, and that links between nodes are secure against evesdropping. The adversary may control a fixed subset of the nodes. All messages between any two honest nodes are confidential and always arrive (unmodified) in the order sent (this can be achieved with a standard transport level security protocol), but the adversary may delay any message by an arbitrary time interval. The adversary can also disconnect network links. Design Considerations --------------------- In order to provide anonymity we must hide the routing of packets. This can be done through DC-Mixes or through "Onion routing". We choose the latter for this design. Each packet will travel through multiple hops. The path is only locally visible - i.e. each node knows the predecessor and successor, but no other nodes along any path. We must take measures to prevent traffic analysis. No upstream path node should be able to communicate anything to a downstream node. We must therefore quantize the packet length, the packet arrival time and route creation and deletion times. This will lead to some bandwidth inefficiency. We must also not have any subliminal channels in the routing protocol (e.g. through the data itself, through the absence/presence of data, through repeated data, through any meta-data or protocol fields). The Protocol ------------ The protocol is based on the idea of virtual link encryption. After an anonymous connection is established, the originating node sends a constant stream of (constant size) packets to a second node at a fixed rate. The second node shuffles the packets it receives during a time unit and forwards them in random order to others. A connection is a path in the network. The first node in the path is the sender, and the last node is the receiver. Together they are called communicating peers. The intermediate nodes are called switches. Anonymity in this scheme is asymmetric - the entity that set up the route is anonymous, but not the peer. Bi-directional anonymity can be achieved by setting up a total of four routes, one per direction per peer. Rendezvous would be achieved through a third party. Each switch in a path therefore has a key, an associated hop id, and two associated link ids. Call the id of the link that it shares with the previous node (the one closer to the sender) "incoming", and call the other link id "outgoing". For each link id, the switch expects exactly one packet tagged with that id in each time unit. Call the data in a packet Dorig. The sender Nn performs the following functions: format the output stream into a series of packets of fixed size Dorig Construct Dn-1 = Dorig | Checksum(Dorig) If the sender constructed the path, it decrypts Dn with the keys RKi where i varies from 1 to n-1. Transmit Dn to the first switch Nn-1. Attach the appropriate link id A switch performs the following functions: Expects Di from the predecessor node on time If data is not available, generates a random Di If the first 64 bits of the data are the same as any previous packet on the link, drop the data and generates a random Di Encrypts the data: Di-1 = ERKi(Di) Translates the incoming link id to an outgoing link id based on an internal table Forwards the data to the successor The receiver N0 performs the following functions: Accepts D0 from N1 If the receiver constructed the path, it decrypts D0 with the keys RKi where i varies from 1 to n-1. The result is Dn By definition, Dn contains Dorig and a checksum. If the checksum does not match, the packet is dropped. To establish a route, the receiver N0 (or alternately the sender Nn) performs the following steps: Select a node (N1) at random and establish a key (RK1) and link id (S1) with N1. Select another node (N2) at random. Request that N1 establish a link id (S2) with N2. Establish a key (RK2) with N2 through N1. Request that N1 use RK1 to decrypt all messages tagged with S1, tag the decrypted message with S2 and forward them to N2. Also request that N1 use RK1 to encrypt all messages tagged with S2, tag the encrypted messages with S1 and forward them to N0. Repeat previous steps several more times. (Name the i-th node, key, and id Ni, Ki, and Si respectively.) Repeat steps a final time, but with the receiver node (Nn) instead of a random node. Protocol Rationale ------------------ The reason we forbid the repetition of the first 64 bits of a packet is to efficiently prevent traffic analysis where the adversary duplicates packets. If we force packets to be all different, the encryption steps will ensure that no subliminal information will be transmitted through the route. 64 bits are enough to maintain a small packet drop probability. We transmit random data in the case of no incoming data. This prevents any adversary corrupting or blocking traffic upstream in order to communicate through the route. Retransmission in the case of dropped packets is not possible. This would enable traffic analysis by someone who controls one of the peers. That is unless the peer is trusted. Network Bootstrapping --------------------- The layout of the network should be done through a mechanism that allows bootstrapping. i.e. it should not depend on one rendezvous point. This could be done with a set of nodes that implement a bootstrap service, and a second set of nodes (maybe all nodes?) that keep track of routing topology. The routing topology should be efficient. Constant encrypted links should be maintained between routing peers. Anonymizing routes should try to follow these links, rather than be completely random. Loss in randomness can be compensated through longer chains. Directory services should be provided in order to give clients starting points. These can be provided anonymously (except for routing services). Other Ideas ----------- Payment for services and congestion control could be done through a HashCash system. For example, the following services would require a HashCash payment: Route establishment (end-to-switch) Service use (client-to-server) Directory advertisement (server-to-directory) Directory use (client-to-directory) Route use cannot be paid for during the use, since that would open up a subliminal channel. Recommended Numbers ------------------- Packet sizes will be quantized to 1KB, 4KB, 16KB (etc.). Packet rates will be quantized to 0.125/sec, 1/sec, 4/s, 16/s, 64/s. Two routes of same rate can be aggregated for in-between power of two rates, e.g. 2KB/s (does this buy anything, over just providing those rates?). -- Dev Random Fingerprint: 3ABC FCEF 1BCE 4528 E4FD 15EB 173A 76D2 6959 DAF1 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20010510/ca2ef93f/attachment.pgp>
