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.
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/
Source:
http://www.itd.nrl.navy.mil/ITD/5540/projects/onion-routing/
Privacy and Anonymity on the Internet
Contents:
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.
-
David M. Goldschlag, Michael G. Reed, and Paul F.
Syverson,
"Privacy
on the Internet," submitted for publication. [See
http://cryptome.org/jya/privnet.htm]
-
Paul F. Syverson, David M. Goldschlag, Michael G. Reed, "Anonymous Connections
and Onion Routing," to appear in the Proceedings of the Symposium on Security
and Privacy, Oakland, CA, May 1997. Draft:
PostScript
-
Michael G. Reed, Paul F. Syverson, David M. Goldschlag, "Proxies for Anonymous
Routing," Proceedings of the 12th Annual Computer Security Applications
Conference, San Diego, CA, Dec., 1996.
PostScript.
-
David M. Goldschlag, Michael G. Reed, and Paul F. Syverson, "Hiding Routing
Information," Workshop on Information Hiding, Cambridge, UK, May, 1996.
PostScript,
PDF
[HTML].
Onion Routing briefing slides.
PostScript,
PDF.
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:
>Hal,
>
>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