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
PGP signature
