[or-cvs] clean up sec1, part of sec2
Roger Dingledine
arma at seul.org
Sat Nov 1 03:40:27 UTC 2003
Update of /home/or/cvsroot/doc
In directory moria.mit.edu:/home2/arma/work/onion/cvs/doc
Modified Files:
tor-design.bib tor-design.tex
Log Message:
clean up sec1, part of sec2
Index: tor-design.bib
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.bib,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -d -r1.13 -r1.14
--- tor-design.bib 1 Nov 2003 03:06:23 -0000 1.13
+++ tor-design.bib 1 Nov 2003 03:40:20 -0000 1.14
@@ -1,3 +1,31 @@
+
+ at inproceedings{tarzan:ccs02,
+ title = {Tarzan: A Peer-to-Peer Anonymizing Network Layer},
+ author = {Michael J. Freedman and Robert Morris},
+ booktitle = {Proceedings of the 9th {ACM} {C}onference on {C}omputer and {C}ommunications
+ {S}ecurity ({CCS 2002})},
+ year = {2002},
+ month = {November},
+ address = {Washington, DC},
+}
+
+ at inproceedings{cebolla,
+ title = {{Cebolla: Pragmatic IP Anonymity}},
+ author = {Zach Brown},
+ booktitle = {Proceedings of the 2002 Ottawa Linux Symposium},
+ year = {2002},
+ month = {June},
+}
+
+ at misc{eax,
+ author = "M. Bellare and P. Rogaway and D. Wagner",
+ title = "A conventional authenticated-encryption mode",
+ text = "M. Bellare, P. Rogaway, and D. Wagner. A conventional authenticated-encryption
+ mode. Manuscript, April 2003. www.cs.ucdavis.edu/\~{}rogaway",
+ month = {April},
+ year = {2003},
+}
+
@misc{darkside,
title = {{The Dark Side of the Web: An Open Proxy's View}},
author = {Vivek S. Pai and Limin Wang and KyoungSoo Park and Ruoming Pang and Larry Peterson},
@@ -30,7 +58,6 @@
$<$http://www.pmg.lcs.mit.edu/$\tilde{\hspace{5pt}}$castro/application/recovery.pdf$>$},
}
-% wasn't jean camp an editor for FC03 too?
@inproceedings{econymics,
title = {On the Economics of Anonymity},
author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson},
@@ -39,6 +66,24 @@
editor = {Rebecca N. Wright},
publisher = {Springer-Verlag, LNCS 2742},
note = {\url{http://freehaven.net/doc/fc03/econymics.pdf}},
+}
+
+ at inproceedings{defensive-dropping,
+ title = {Stopping Timing Attacks in Low-Latency Mix-Based Systems},
+ author = {Matthew Wright and Brian N. Levine and Michael K. Reiter and Chenxi Wang},
+ booktitle = {Financial Cryptography, FC 2004},
+ year = {2004},
+ editor = {Ari Juels},
+ publisher = {Springer-Verlag, LNCS (forthcoming)},
+}
+
+ at inproceedings{morphmix:fc04,
+ title = {Practical Anonymity for the Masses with MorphMix},
+ author = {Marc Rennhard and Bernhard Plattner},
+ booktitle = {Financial Cryptography, FC 2004},
+ year = {2004},
+ editor = {Ari Juels},
+ publisher = {Springer-Verlag, LNCS (forthcoming)},
}
@inproceedings{eternity,
Index: tor-design.tex
===================================================================
RCS file: /home/or/cvsroot/doc/tor-design.tex,v
retrieving revision 1.44
retrieving revision 1.45
diff -u -d -r1.44 -r1.45
--- tor-design.tex 1 Nov 2003 03:06:23 -0000 1.44
+++ tor-design.tex 1 Nov 2003 03:40:20 -0000 1.45
@@ -49,14 +49,15 @@
\thispagestyle{empty}
\begin{abstract}
-We present Tor, a connection-based low-latency anonymous communication
+We present Tor, a circuit-based low-latency anonymous communication
system. Tor is the successor to Onion Routing
and addresses many limitations in the original Onion Routing design.
Tor works in a real-world Internet environment,
% it's user-space too
requires little synchronization or coordination between nodes, and
-protects against known anonymity-breaking attacks as well
-as or better than other systems with similar design parameters.
+provides a reasonable tradeoff between anonymity and usability/efficiency
+%protects against known anonymity-breaking attacks as well
+%as or better than other systems with similar design parameters.
% and we present a big list of open problems at the end
% and we present a new practical design for rendezvous points
\end{abstract}
@@ -80,18 +81,19 @@
at each node (like the layers of an onion) and relayed downstream. The
original Onion Routing project published several design and analysis
papers
-\cite{or-jsac98,or-discex00,or-ih96,or-pet00}. While there was
-a wide area Onion Routing network for a several weeks,
-% how long is briefly? a day, a month? -RD
+\cite{or-ih96,or-jsac98,or-discex00,or-pet00}. While
+a wide area Onion Routing network was deployed for several weeks,
the only long-running and publicly accessible
implementation was a fragile proof-of-concept that ran on a single
-machine (which nonetheless processed several tens of thousands of connections
-daily from thousands of global users).
+machine.
+% (which nonetheless processed several tens of thousands of connections
+%daily from thousands of global users).
+%%Do we really want to say this? It softens our motivation for the paper. -RD
Many critical design and deployment issues were never resolved,
and the design has not been updated in several years.
Here we describe Tor, a protocol for asynchronous, loosely
federated onion routers that provides the following improvements over
-the old Onion Routing design, and over other low-latency anonymity systems:
+the old Onion Routing design:
\begin{tightlist}
@@ -127,55 +129,42 @@
request.
This hurt performance by requiring multiple public key operations for
every request, and also presented
-a threat to anonymity (see Section~\ref{maintaining-anonymity}).
-\footnote{The first Onion Routing design \cite{or-ih96} protected against
-this threat to some
-extent by requiring users to hide network access behind an onion
-router/firewall that was also forwarding traffic from other nodes.
-However, it is desirable for users to
-benefit from Onion Routing even when they can't run their own
-onion routers.
-%Such users, especially if they engage in certain unusual
-%communication behaviors, may be identifiable \cite{wright03}.
-%To
-%complicate the possibility of such attacks Tor multiplexes many
-%stream down each circuit, but still rotates the circuit
-%periodically to avoid too much linkability from requests on a single
-%circuit.
-%
-% [This digression probably belongs in maintaining-anonymity. -NM
-}
-The current Tor design multiplexes multiple TCP streams along each virtual
-circuit, in order to improve efficiency and anonymity.
+a threat to anonymity from building so many different circuits; see
+Section~\ref{sec:maintaining-anonymity}.
+Tor multiplexes multiple TCP streams along each virtual
+circuit, to improve efficiency and anonymity.
\item \textbf{No mixing, padding, or traffic shaping:} The original
-Onion Routing design called for mixing of data from each circuit,
-plus full link padding both between onion routers and between onion
+Onion Routing design called for batching and reordering the cells arriving
+from each circuit,
+plus full link padding between onion routers and between onion
proxies (that is, users) and onion routers \cite{or-jsac98}. The
-later analysis paper \cite{or-pet00} suggested \emph{traffic shaping}
-to provide similar protection but use less bandwidth, but did not go
-into detail. However, recent research \cite{econymics} and deployment
+later analysis paper \cite{or-pet00} theorized \emph{traffic shaping}
+that provides similar protection but use less bandwidth, but did not
+provide details. However, recent research \cite{econymics} and deployment
experience \cite{freedom21-security} suggest that this level of resource
use is not practical or economical; and even full link padding is still
vulnerable \cite{defensive-dropping}. Thus, until we have a proven and
-convenient design for traffic shaping or low-latency mixing that will help
-anonymity against a realistic adversary, we leave these strategies out.
+convenient design for traffic shaping or low-latency mixing that
+will improve anonymity against a realistic adversary, we leave these
+strategies out.
\item \textbf{Leaky-pipe circuit topology:} Through in-band
signalling within the
circuit, Tor initiators can direct traffic to nodes partway down the
- circuit. This not only allows for long-range padding to frustrate traffic
- shape and volume attacks at the initiator \cite{defensive-dropping},
- but because circuits are used by more than one application, it also
+ circuit. This allows for long-range padding to frustrate traffic
+ shape and volume attacks at the initiator \cite{defensive-dropping}.
+ Because circuits are used by more than one application, it also
allows traffic to exit the circuit from the middle---thus
- frustrating traffic shape and volume attacks based on observing exit
- points.
+ frustrating traffic shape and volume attacks based on observing the
+ end of the circuit.
\item \textbf{Congestion control:} Earlier anonymity designs do not
address traffic bottlenecks. Unfortunately, typical approaches to load
balancing and flow control in overlay networks involve inter-node control
-communication and global views of traffic. Tor's decentralized ack-based
-congestion control maintains reasonable anonymity while allowing nodes
+communication and global views of traffic. Tor's decentralized congestion
+control uses end-to-end acks to maintain reasonable anonymity while
+allowing nodes
at the edges of the network to detect congestion or flooding attacks
and send less data until the congestion subsides.
@@ -184,20 +173,22 @@
approach which can be unreliable and
open to partitioning attacks or outright deception. Tor takes a simplified
view towards distributing link-state information. Certain more trusted
-onion routers also serve as directory servers; they provide signed
-\emph{directories} describing all routers they know about, and which
+onion routers also act as directory servers: they provide signed
+\emph{directories} which describe the routers they know about and mark
+those that
are currently up. Users periodically download these directories via HTTP.
-\item \textbf{End-to-end integrity checking:} Without integrity checking
-on traffic going through the network, any onion router on the path
-can change the contents of cells as they pass by---for example, to redirect a
+\item \textbf{End-to-end integrity checking:} The original Onion Routing
+design did no integrity checking on data. Any onion router on the circuit
+could change the contents of cells as they pass by---for example, to
+redirect a
connection on the fly so it connects to a different webserver, or to
tag encrypted traffic and look for the tagged traffic at the network
edges \cite{minion-design}. Tor hampers these attacks by checking data
integrity before it leaves the network.
-\item \textbf{Robustness to failed nodes:} A failed node in a traditional
-mix network means lost messages, but thanks to Tor's step-by-step
+\item \textbf{Robustness to failed nodes:} A failed node in the old design
+meant that circuit-building failed, but thanks to Tor's step-by-step
circuit building, users can notice failed
nodes while building circuits and route around them. Additionally,
liveness information from directories allows users to avoid
@@ -226,49 +217,45 @@
each operator is comfortable with allowing different types of traffic
to exit the Tor network from his node.
-\item \textbf{Implementable in user-space:} Because it only attempts to
-anonymize TCP streams, Tor differs from other anonymity systems like
-Freedom \cite{freedom} in that it does not require patches to an operating
-system's network stack in order to operate. Although this approach is less
+\item \textbf{Implementable in user-space:} Unlike other anonymity systems
+like Freedom \cite{freedom2-arch}, Tor only attempts to anonymize TCP
+streams. Thus it does not require patches to an operating system's network
+stack (or built-in support) to operate. Although this approach is less
flexible, it has proven valuable to Tor's portability and deployability.
-\item \textbf{Rendezvous points and location-protected servers:} Tor
-provides an integrated mechanism for responder anonymity via
+\item \textbf{Rendezvous points and location-protected servers:}
+Tor provides an integrated mechanism for responder anonymity via
location-protected servers. Previous Onion Routing designs included
-long-lived ``reply onions'' which could be used to build virtual
-circuits to a hidden server, but this approach is
-brittle because a reply onion becomes useless if any node in the
-path goes down or rotates its keys, and it's also
-%vulnerable to flooding attacks,
-% no it isn't. no more than our rendezvous point approach at least -RD
-incompatible with forward security. In Tor's
-current design, clients use {\it introduction points} to negotiate {\it
-rendezvous points} to connect with hidden servers; and reply onions
-are no longer required.
+long-lived ``reply onions'' which could be used to build virtual circuits
+to a hidden server, but a reply onion becomes useless if any node in
+the path goes down or rotates its keys, and it also does not provide
+forward security. In Tor's current design, clients negotiate {\it
+rendezvous points} to connect with hidden servers; reply onions are no
+longer required.
\end{tightlist}
-[XXX carefully mention implementation, emphasizing that experience
-deploying isn't there yet, and not all features are implemented.
-Mention that it runs, is kinda alpha, kinda deployed, runs on win32.]
+We have implemented most of the above features. Our source code is
+available under a free license, and is not encumbered by patents. We have
+recently begun deploying a widespread alpha network to see how well the
+design works in practice, to get more experience with usability and users,
+and to provide a research platform for experimenting with new ideas.
-We review previous work in Section~\ref{sec:background}, describe
+We review previous work in Section~\ref{sec:related-work}, describe
our goals and assumptions in Section~\ref{sec:assumptions},
and then address the above list of improvements in
-Sections~\ref{sec:design}-\ref{sec:maintaining-anonymity}. We then
-summarize
+Sections~\ref{sec:design}-\ref{sec:rendezvous}. We
+summarize in Section \ref{sec:analysis}
how our design stands up to known attacks, and conclude with a list of
open problems.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-\Section{Background and threat model}
-\label{sec:background}
-
-\SubSection{Related work}
+\Section{Related work}
\label{sec:related-work}
+
Modern anonymity designs date to Chaum's Mix-Net\cite{chaum-mix} design of
-1981. Chaum proposed hiding sender-recipient connections by wrapping
-messages in several layers of public key cryptography, and relaying them
+1981. Chaum proposed hiding sender-recipient linkability by wrapping
+messages in layers of public key cryptography, and relaying them
through a path composed of ``Mixes.'' These mixes in turn decrypt, delay,
and re-order messages, before relaying them along the sender-selected
path towards their destinations.
@@ -278,7 +265,7 @@
the cost of introducing comparatively large and variable latencies,
for example, Babel\cite{babel}, Mixmaster\cite{mixmaster-spec}, and
Mixminion\cite{minion-design}. Because of this
-trade-off, such \emph{high-latency} networks are well-suited for anonymous
+trade-off, these \emph{high-latency} networks are well-suited for anonymous
email, but introduce too much lag for interactive tasks such as web browsing,
internet chat, or SSH connections.
@@ -286,9 +273,9 @@
to anonymize interactive network traffic. Because these protocols typically
involve a large number of packets that must be delivered quickly, it is
difficult for them to prevent an attacker who can eavesdrop both ends of the
-interactive communication from points from correlating the timing and volume
+communication from correlating the timing and volume
of traffic entering the anonymity network with traffic leaving it. These
-protocols are also vulnerable against certain active attacks in which an
+protocols are also vulnerable against active attacks in which an
adversary introduces timing patterns into traffic entering the network, and
looks
for correlated patterns among exiting traffic.
@@ -308,41 +295,45 @@
about who is talking to whom.
The simplest low-latency designs are single-hop proxies such as the
-Anonymizer \cite{anonymizer}, wherein a single trusted server removes
-identifying users' data before relaying it. These designs are easy to
-analyze, but require end-users to trust the anonymizing proxy. Furthermore,
-concentrating the traffic to a single point makes traffic analysis easier: an
-adversary need only eavesdrop on the proxy in order to become a global
-observer against the entire anonymity network.
+Anonymizer \cite{anonymizer}, wherein a single trusted server strips the
+data's origin before relaying it. These designs are easy to
+analyze, but require end-users to trust the anonymizing proxy.
+Concentrating the traffic to a single point increases the anonymity set
+(the set of people a given user is hiding among), but it can make traffic
+analysis easier: an adversary need only eavesdrop on the proxy to observe
+the entire system.
-More complex are distributed-trust, channel-based anonymizing systems. In
+More complex are distributed-trust, circuit-based anonymizing systems. In
these designs, a user establishes one or more medium-term bidirectional
-end-to-end tunnels to exit servers, and uses those tunnels to deliver a
-number of low-latency packets to and from one or more destinations per
-tunnel. Establishing tunnels is comparatively expensive and typically
+end-to-end tunnels to exit servers, and uses those tunnels to deliver
+low-latency packets to and from one or more destinations per
+tunnel. %XXX reword
+Establishing tunnels is expensive and typically
requires public-key cryptography, whereas relaying packets along a tunnel is
comparatively inexpensive. Because a tunnel crosses several servers, no
-single server can learn the user's communication partners.
+single server can link a user to her communication partners.
-In some distributed-trust systems, such as the Java Anon Proxy (also known as
-JAP or WebMIXes), users
-build their tunnels along a fixed shared route or
-``cascade.'' Like a single-hop proxy, a single cascade increases anonymity
-sets by concentrating concurrent traffic into a single communication pipe.
-Concentrating traffic, however, can become a liability: as with a single-hop
-proxy, an attacker only needs to observe a limited number of servers (in this
-case, both ends of the cascade) in order
-to bridge all the system's traffic.
+In some distributed-trust systems, such as the Java Anon Proxy (also known
+as JAP or Web MIXes), users build their tunnels along a fixed shared route
+or \emph{cascade}. As with a single-hop proxy, this approach aggregates
+users into larger anonymity sets, but again an attacker only needs to
+observe both ends of the cascade to bridge all the system's traffic.
The Java Anon Proxy's design seeks to prevent this by padding
between end users and the head of the cascade \cite{web-mix}. However, the
current implementation does no padding and thus remains vulnerable
to both active and passive bridging.
+%XXX fix, yes it does, sort of.
-Systems such as earlier versions of Freedom and the original Onion Routing
+%XXX do a paragraph on p2p vs client-server
+\cite{tarzan:ccs02}
+\cite{morphmix:fc04}
+
+Systems such as Freedom and the original Onion Routing
build the anonymous channel all at once, using a layered ``onion'' of
public-key encrypted messages, each layer of which provides a set of session
keys and the address of the next server in the channel. Tor as described
-herein, later designs of Freedom, and AnonNet \cite{anonnet} build the
+herein, Tarzan, Morphmix, Cebolla \cite{cebolla}, and AnonNet
+\cite{anonnet} build the
channel in stages, extending it one hop at a time. This approach
makes perfect forward secrecy feasible.
@@ -364,15 +355,14 @@
forced to launch jondos using many different identities and on many
different networks to succeed'' \cite{crowds-tissec}.
-Another low-latency design that was proposed independently and at
-about the same time as the original Onion Routing was PipeNet
-\cite{pipenet}. It provided anonymity protections that were stronger
-than Onion Routing's, but at the cost of allowing a single user to
-shut down the network simply by not sending. It was also never
-implemented or formally published. Low-latency anonymous communication
-has also been designed for other types of systems, including
-ISDN \cite{isdn-mixes}, and mobile applications such as telephones and
-active badging systems \cite{federrath-ih96,reed-protocols97}.
+PipeNet \cite{back01, pipenet}, another low-latency design proposed at
+about the same time as the original Onion Routing design, provided
+stronger anonymity at the cost of allowing a single user to shut
+down the network simply by not sending. Low-latency anonymous
+communication has also been designed for other environments, including
+ISDN \cite{isdn-mixes}
+% and mobile applications such as telephones and
+%active badging systems \cite{federrath-ih96,reed-protocols97}.
Some systems, such as Crowds \cite{crowds-tissec}, do not rely on changing the
appearance of packets to hide the path; rather they try to prevent an
@@ -856,8 +846,8 @@
e.g. starting a new stream. If the stream ID is unrecognized, the OR
passes the relay cell downstream. This \emph{leaky pipe} circuit topology
allows Alice's streams to exit at different ORs on a single circuit.
-Alice may do this to tolerate
-different exit policies, or to keep the ORs from knowing that two streams
+Alice may choose different exit points because of their exit policies,
+or to keep the ORs from knowing that two streams
originate at the same person.
To tear down a circuit, Alice sends a destroy control cell. Each OR
@@ -1000,10 +990,10 @@
Further, inspired by Rennhard et al's design in \cite{anonnet}, a
circuit's edges heuristically distinguish interactive streams from bulk
streams by comparing the frequency with which they supply cells. We can
-provide good latency for these streams by giving them preferential
+provide good latency for interactive streams by giving them preferential
service, while still getting good overall throughput to the bulk
streams. Such preferential treatment presents a possible end-to-end
-attack, but an adversary who can observe the stream can observe both
+attack, but an adversary who can observe both
ends of the stream can already learn this information through timing
attacks.
@@ -1179,7 +1169,7 @@
node configuration is more secure for clients --- the adversary cannot
see plaintext traffic leaving the network (e.g. to a webserver), so he
is less sure of Alice's destination. More generally, nodes can require
-a variety of forms of traffic authentication \cite{onion-discex00}.
+a variety of forms of traffic authentication \cite{or-discex00}.
Most onnion routers will function as \emph{limited exits} that permit
connections to the world at large, but restrict access to certain abuse-prone
addresses and services.
@@ -1530,6 +1520,22 @@
\Section{Maintaining anonymity in Tor}
\label{sec:maintaining-anonymity}
+
+\footnote{The first Onion Routing design \cite{or-ih96} protected against
+this threat to some
+extent by requiring users to hide network access behind an onion
+router/firewall that was also forwarding traffic from other nodes.
+However, it is desirable for users to
+benefit from Onion Routing even when they can't run their own
+onion routers.
+%Such users, especially if they engage in certain unusual
+%communication behaviors, may be identifiable \cite{wright03}.
+%To
+%complicate the possibility of such attacks Tor multiplexes many
+%stream down each circuit, but still rotates the circuit
+%periodically to avoid too much linkability from requests on a single
+%circuit.
+}
I probably should have noted that this means loops will be on at least
five hop routes, which should be rare given the distribution. I'm
More information about the tor-commits
mailing list