This website comprises the onion-router.net site formerly hosted at
the Center for High
Assurance Computer Systems of
the U.S. Naval Research
Laboratory. It primarily covers the work done at NRL during the
first decade of onion routing and reflects the onion-router.net site
roughly as it existed circa 2005. As a historical site it may contain
dead external links and other signs of age.

The Onion Routing program is made up of projects researching,
designing, building, and analyzing anonymous communications
systems. The focus is on practical systems for low-latency Internet-based
connections that resist traffic analysis, eavesdropping, and other
attacks both by outsiders (e.g. Internet routers) and insiders (Onion
Routing servers themselves). Onion Routing prevents the transport
medium from knowing who is communicating with whom -- the network
knows only that communication is taking place. In addition, the
content of the communication is hidden from eavesdroppers up to the
point where the traffic leaves the OR network.

The latest Onion Routing system is freely available and runs on most
common operating systems. There is a Tor network of several
hundred nodes, processing traffic from hundreds of thousands of unknown users.
(The protection afforded by the system makes it difficult to determine
the number of users or application connections.) Exact current and
historical number of Tor nodes and global traffic volume processed are
graphically depicted here. The code
and documentation is available under a free license. Check out the Tor site for more details and
instructions for running Tor.

The protection of Onion Routing is independent of whether the
identity of the initiator of a connection (the sender) is hidden from
the responder of the connection, or vice versa. The sender and
receiver may wish to identify and even authenticate to each other, but
do not wish others to know that they are communicating. The sender may
wish to be hidden from the responder. There are many ways that a web
server can deduce the identity of a client who visits it; several test sites can be
used to demonstrate this. A filtering proxy can be used to reduce the
threat of identifying information from a client reaching a
server. Onion Routing currently makes use of the Privoxy filter for this purpose.

Hidden Services

Web services and other services are subject to Distributed Denial
of Service and even potential physical attack. But if the logical and
physical location of a service is hidden, then it can resist such
attacks, even from those with authorized access to the
service. Providing hidden services and rendezvous points have been
part of Onion Routing since the beginning. See the papers "Hiding Routing Information",
and "Protocols using Anonymous
Connections: Mobile Applications", as well as these slides.

The Tor design includes an improved approach to rendezvous points
and hidden services. (See
"Tor: The Second-Generation Onion Router" or these slides for a description of
how they work.) Hidden services have been deployed for the first time
using Tor network. The hidden
wiki includes a list of some hidden services and related
information. (A running Tor client and a proxy like Privoxy is
necessary to access the hidden wiki.) Analysis of the security of
hidden servers, including both design improvements to more robustly
hide services and the first published intersection attack actually
conducted on a deployed anonymity network, is described in "Locating Hidden
Servers". Design suggestions to improve QoS and DoS-resistance of
Hidden Services are described in "Valet Services: Improving
Hidden Servers with a Personal Touch".

A note about the use of `generation'.

Throughout these pages are references to different generations of
Onion Routing. However, terminology has varied somewhat
throughout Onion Routing's history. This
note explains and unifies the different uses.

An initial design for Onion Routing was published at the first Information
Hiding Workshop and deployed in mid 1996. In 1996, work had
already begun on a second generation
design and was referred to as such. (Some also called it `Onion
Routing: The Next Generation' in homage to a certain television series
of that era.) The first publication reflecting any of that next
generation design was in a paper at ACSAC in Dec. 1996,
where running the proxy at a client not otherwise running a
node is mentioned in passing. Much of it is specified and discussed
in the Oakland 97 design
paper, which was further refined and expanded in the JSAC 98 paper. There was also
a detailed specification. In
1998, there were multiple independently deployed networks of around a
dozen nodes each running on multiple platforms (Solaris, HP/UX, Linux,
Windows NT, BSD), and embodying most of the "next generation" design,
but none was ever publicly accessible. In mid 2002, design began on a
new system that eventually became Tor, which is thus at least a third
generation of Onion Routing. Nonetheless, in many discussions since
about 2002, everything from second millennium, preTor Onion Routing
tends to get lumped together as `the first generation design', while
Tor tends to be called `second generation'. In an attempt to maximize
coherence between these as well as to follow good mathematical
practice, we will consider the initial 1996 design to be generation 0;
all design elements after that and before Tor are generation 1; and
Tor, at least as conceived roughly 2002--2005, is generation
2. Readers should fudge on the cardinal/ordinal terminology in
whatever way is useful.