This website comprises the 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 site roughly as it existed circa 2005. As a historical site it may contain dead external links and other signs of age.

Onion Routing

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.

Tor: Generation 2 Onion Routing

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.

Historical page reflecting as of 2005, not regularly maintained. Address questions to Paul Syverson.