25 April 1997: Add Lucky Green's comments.
3 March 1997 (Thanks to LG for pointer)

Date: Sun, 02 Mar 1997 18:20:49 -0800
To: cryptography@c2.net, coderpunks@toad.com, weidai@eskimo.com
From: Lucky Green <shamrock@netcom.com>
Subject: PipeNet implemented?

At the FC'97 rump session, Paul Syverson from NRL presented a paper titled "Onion Routing". The description of the system sounds very much like Wei Dai's PipeNet. However, the development team seems to be unaware of PipeNet and the discussions about it that we had in the past.

NLR has currently five machines implementing the protocol. Connection setup time is claimed to be 500 ms. They are looking for volunteers to run "Onion Routers". It appears the US military wants to access websites without giving away the fact that they are accessing the sites and is looking to us to provide the cover traffic. What a fortunate situation.

They said that the source would soon be on the web page, but so far it has not appeared.


Source: http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/

Privacy and Anonymity on the Internet



The use of a switched communications network should not require revealing who is talking to whom. Onion Routing is a flexible communications infrastructure that is resistant to both eavesdropping and traffic analysis. Onion routing accomplishes this goal by separating identification from routing. Connections are always anonymous, although communication need not be. Communication may be made anonymous by removing identifying information from the data stream. Onion routing can be used by a variety of unmodified Internet applications by means of proxies.

Traffic analysis can be used to infer who is talking to whom over a public network. For example, in a packet switched network, packets have a header used for routing, and a payload that carries the data. The header, which much be visible to the network (and to observers of the network), reveals the source and destination of the packet. Even if the header were obscured in some way, the packet could still be tracked as it moves through the network. Encrypting the payload is similarly ineffective, because the goal of traffic analysis is to identify who is talking to whom and not (to identify directly) the content of that conversation.

The efficiencies of the public Internet are strong motivation for companies to use it instead of private intranets. However, these companies may want to protect their interests. For example, a researcher using the World Wide Web (Web) may expect his particular focus to remain private, and the existence of inter-company collaboration may be confidential. Individuals may wish to protect their privacy too. The identities of the participants in an e-mail conversation should be known only to the communicating parties. A person shopping on the Web may not want his visits tracked. Certainly, someone spending anonymous e-cash expects that the source of the e-cash be untraceable.

Onion routing has been prototyped on Sun Solaris 2.4. The prototype includes proxies for private Web browsing, remote login, e-mail, and file transfer protocols, and also anonymizing versions of those proxies that remove identifying information from the data stream. This page describes the Onion Routing system at several levels of abstraction, including a detailed specification for reimplementors.

Our motivation here is not specifically to provide anonymous communication, but, to seperate identification from routing. Applications and users may identify themselves to each other. But the use of a public network should not automatically reveal to others the identities of communicating parties.


Letters sent through the Post Office are usually in an envelope marked with the sender's and recipient's addresses. We trust that the Post Office does not peek inside the envelope, because we consider its contents private. We also trust that the Post Office does not monitor who sends mail to whom, because that information is also considered private.

These two types of sensitive information, the contents of an envelope and its address, apply equally well to electronic communication over the Internet. Just like mail, electronic messages travel in electronic envelopes, and protecting the privacy of these messages requires both safeguarding the contents of those envelopes and hiding the addresses on the envelopes. Although communicating parties usually identify themselves to one another, there is no reason that the use of a public network like the Internet ought to reveal to others who is talking to whom and what they are talking about. The first concern is traffic analysis, the latter is eavesdropping.

By making both eavesdropping and traffic analysis hard, the privacy of communication is protected. But what about anonymity? Can two parties communicate, if one or both do not want to be identified to the other? If the electronic envelope keeps its contents private, and the address on the envelope is also hidden, then any identifying information can only be inside the envelope! So for anonymous communication, we remove identifying information from the contents of an envelope. This may be called anonymizing a private envelope.

These goals may appear to be insolvable: Can the contents of an envelope really be kept private? How can a letter reach its destination if its address is hidden? Can two parties communicate without revealing their identities to one another? Can all this be done without trusting third parties (the Post Office, for example) not to remember addresses or to open envelopes?

Onion Routing uses well known networking and cryptographic techniques to protect both the privacy and anonymity of Internet communication against both eavesdropping and traffic analysis. Onion Routing is easily used in a wide variety of Internet applications (WWW browsing and electronic mail, for example) to communicate both privately and and anonymously.


If we protect a communications channel against both eavesdropping and traffic analysis, and remove identifying information from the data stream, then we have anonymous and private communication.

Onion Routing provides socket connections that are strongly resistant to both eavesdropping and traffic analysis. The privacy of these socket connections is moved beneath the application layer and made application independent. Unmodified Internet applications may use these anonymous socket connections by means of proxies. If the proxies anonymize the data stream, anonymity may be layered on top of anonymous socket connections. Onion Routing has been implemented on Sun Solaris 2.4 along with proxies for HTTP (WWW) and RLOGIN. Proxies for e-mail (SMTP) and FTP are forthcoming.

Onion Routing works in the following way: An application, instead of making a (socket) connection directly to a destination machine, makes a socket connection to an Onion Routing Proxy. That Onion Routing Proxy builds an anonymous connection through several other Onion Routers to the destination. Each Onion Router can only identify adjacent Onion Routers along the route. Before sending data over an anonymous connection, the first onion router adds a layer of encryption for each onion router in the route. As data moves through the anonymous connection, each onion router removes one layer of encryption, so it finally arrives as plaintext. This layering occurs in the reverse order for data moving back to the initiator. Data passed along the anonymous connection appears different at each Onion Router, so data cannot be tracked en route and compromised Onion Routers cannot cooperate. When the connection is broken, all information about the connection is cleared at each Onion Router.

Onion Routing differs from other anonymity services in two ways: Communication is real-time and bidirectional; and the anonymous connections are application independent. Applications may choose whether to identify their users over an anonymous connection. However, the use of a switched public network should not automatically reveal who is talking to whom. This is the traffic analysis that Onion Routing complicates.



Onion Routing briefing slides. PostScript, PDF.

How to use the Onion Routing Prototype:

One can use our Onion Routing prototype in several ways:

Last modified: Fri Aug 23 09:54:10 EDT 1996 - onions@usonian.itd.nrl.navy.mil

[End NRL document]

To: cypherpunks@cyberpass.net
Date: Fri, 25 Apr 1997 01:24:29 -0700
From: Lucky Green <shamrock@netcom.com>
Subject: Re: A new system for anonymity on the web

At 12:59 PM 4/20/97 -0700, Steve Schear wrote:

>What do you think of the "onion routing" approach from the group at Naval
>Postgraduate? How would compare it to this newest proposal?

Neither one of them is any good in its present form. The folks at the FC'97 rump session got to watch Jim and myself poke truck sized holes into the NRL design within seconds of them ending their presentation. :-)

Here was a US military research lab presenting a system they thought would give them a way to surf the Net anonymously by using the public for cover traffic. [Let me just spell out here that I believe that the people from NRL and Cypherpunks are on the same side on this issue. Their concern is COMSEC, not SIGINT.]

Anyway, we knew how to crack their system without even having to think about it, since folks on Cypherpunks, especially Wei Dai, had discovered various venues of attack on such systems long ago. Cypherpunks are teaching the military about traffic analysis. :-)

The one good thing about NRL is that they seem to be willing to learn. [The other being that they get paid to write our code for us.] Though I get the distinct feeling that they don't like the required solution. There is simply no way to harden the system against attack without using a constant or at least slowly varying (I would guess we are talking about periods of several hours here, certainly not minutes, but I haven't done the math, nor do I have the time to do so) bandwidth data stream between the end user and the first Onion Router. This will invariably require special software on the end user's machine. I think the best design would be a client side proxy. [That much Crowds got right.]

As to Crowds, they got to be kidding. How many end users are willing to become, even without their direct knowledge, the last hop to <enter evil URL here>? I believe that relatively few users would want their IP address to be the one showing up in the server log of <enter seized machine's name here> because their jondo happened to be the exit point chosen.

-- Lucky Green <mailto:shamrock@netcom.com> PGP encrypted mail preferred

"I do believe that where there is a choice only between cowardice and violence, I would advise violence." Mahatma Gandhi