[tor-commits] [tech-reports/master] Add unchanged challenges report sources.

[karsten at torproject.org]

commit c55937a3782b166e85f97dac308f258009794de8
Author: Karsten Loesing <karsten.loesing at gmx.net>
Date:   Thu Aug 30 12:12:53 2012 +0200

    Add unchanged challenges report sources.
    
    svn co https://svn.torproject.org/svn/projects/design-paper/
---
 2005/challenges/.gitignore       |    3 +
 2005/challenges/challenges.tex   | 1505 ++++++++++++++++++++++++++++++++++++++
 2005/challenges/graphnodes.pdf   |  Bin 0 -> 62261 bytes
 2005/challenges/graphtraffic.pdf |  Bin 0 -> 62459 bytes
 2005/challenges/llncs.cls        | 1016 +++++++++++++++++++++++++
 2005/challenges/tor-design.bib   | 1493 +++++++++++++++++++++++++++++++++++++
 6 files changed, 4017 insertions(+), 0 deletions(-)

diff --git a/2005/challenges/.gitignore b/2005/challenges/.gitignore
new file mode 100644
index 0000000..c8900d9
--- /dev/null
+++ b/2005/challenges/.gitignore
@@ -0,0 +1,3 @@
+challenges.pdf
+challenges-2005-02.pdf
+
diff --git a/2005/challenges/challenges.tex b/2005/challenges/challenges.tex
new file mode 100644
index 0000000..6949693
--- /dev/null
+++ b/2005/challenges/challenges.tex
@@ -0,0 +1,1505 @@
+\documentclass{llncs}
+
+\usepackage{url}
+\usepackage{amsmath}
+\usepackage{epsfig}
+
+\setlength{\textwidth}{5.9in}
+\setlength{\textheight}{8.4in}
+\setlength{\topmargin}{.5cm}
+\setlength{\oddsidemargin}{1cm}
+\setlength{\evensidemargin}{1cm}
+
+\newenvironment{tightlist}{\begin{list}{$\bullet$}{
+  \setlength{\itemsep}{0mm}
+    \setlength{\parsep}{0mm}
+    %  \setlength{\labelsep}{0mm}
+    %  \setlength{\labelwidth}{0mm}
+    %  \setlength{\topsep}{0mm}
+    }}{\end{list}}
+
+\begin{document}
+
+\title{Challenges in deploying low-latency anonymity (DRAFT)}
+
+\author{Roger Dingledine\inst{1} \and
+Nick Mathewson\inst{1} \and
+Paul Syverson\inst{2}}
+\institute{The Free Haven Project \email{<\{arma,nickm\}@freehaven.net>} \and
+Naval Research Laboratory \email{<syverson at itd.nrl.navy.mil>}}
+
+\maketitle
+\pagestyle{plain}
+
+\begin{abstract}
+  There are many unexpected or unexpectedly difficult obstacles to
+  deploying anonymous communications.  Drawing on our experiences deploying
+  Tor (the second-generation onion routing network), we describe social
+  challenges and technical issues that must be faced
+  in building, deploying, and sustaining a scalable, distributed, low-latency
+  anonymity network.
+\end{abstract}
+
+\section{Introduction}
+% Your network is not practical unless it is sustainable and distributed.
+Anonymous communication is full of surprises.  This paper discusses some
+unexpected challenges arising from our experiences deploying Tor, a
+low-latency general-purpose anonymous communication system.  We will discuss
+some of the difficulties we have experienced and how we have met them (or how
+we plan to meet them, if we know).  We also discuss some less
+troublesome open problems that we must nevertheless eventually address.
+%We will describe both those future challenges that we intend to explore and
+%those that we have decided not to explore and why.
+
+Tor is an overlay network for anonymizing TCP streams over the
+Internet~\cite{tor-design}.  It addresses limitations in earlier Onion
+Routing designs~\cite{or-ih96,or-jsac98,or-discex00,or-pet00} by adding
+perfect forward secrecy, congestion control, directory servers, data
+integrity, configurable exit policies, and location-hidden services using
+rendezvous points.  Tor works on the real-world Internet, requires no special
+privileges or kernel modifications, requires little synchronization or
+coordination between nodes, and provides a reasonable trade-off between
+anonymity, usability, and efficiency.
+
+We deployed the public Tor network in October 2003; since then it has
+grown to over a hundred volunteer-operated nodes
+and as much as 80 megabits of
+average traffic per second.  Tor's research strategy has focused on deploying
+a network to as many users as possible; thus, we have resisted designs that
+would compromise deployability by imposing high resource demands on node
+operators, and designs that would compromise usability by imposing
+unacceptable restrictions on which applications we support.  Although this
+strategy has
+drawbacks (including a weakened threat model, as discussed below), it has
+made it possible for Tor to serve many thousands of users and attract
+funding from diverse sources whose goals range from security on a
+national scale down to individual liberties.
+
+In~\cite{tor-design} we gave an overall view of Tor's
+design and goals.  Here we describe some policy, social, and technical
+issues that we face as we continue deployment.
+Rather than providing complete solutions to every problem, we
+instead lay out the challenges and constraints that we have observed while
+deploying Tor.  In doing so, we aim to provide a research agenda
+of general interest to projects attempting to build
+and deploy practical, usable anonymity networks in the wild.
+
+%While the Tor design paper~\cite{tor-design} gives an overall view its
+%design and goals,
+%this paper describes the policy and technical issues that Tor faces as
+%we continue deployment. Rather than trying to provide complete solutions
+%to every problem here, we lay out the assumptions and constraints
+%that we have observed through deploying Tor in the wild. In doing so, we
+%aim to create a research agenda for others to
+%help in addressing these issues.
+% Section~\ref{sec:what-is-tor} gives an
+%overview of the Tor
+%design and ours goals. Sections~\ref{sec:crossroads-policy}
+%and~\ref{sec:crossroads-design} go on to describe the practical challenges,
+%both policy and technical respectively,
+%that stand in the way of moving
+%from a practical useful network to a practical useful anonymous network.
+
+%\section{What Is Tor}
+\section{Background}
+Here we give a basic overview of the Tor design and its properties, and
+compare Tor to other low-latency anonymity designs.
+
+\subsection{Tor, threat models, and distributed trust}
+\label{sec:what-is-tor}
+
+%Here we give a basic overview of the Tor design and its properties. For
+%details on the design, assumptions, and security arguments, we refer
+%the reader to the Tor design paper~\cite{tor-design}.
+
+Tor provides \emph{forward privacy}, so that users can connect to
+Internet sites without revealing their logical or physical locations
+to those sites or to observers.  It also provides \emph{location-hidden
+services}, so that servers can support authorized users without
+giving an effective vector for physical or online attackers.
+Tor provides these protections even when a portion of its
+infrastructure is compromised.
+
+To connect to a remote server via Tor, the client software learns a signed
+list of Tor nodes from one of several central \emph{directory servers}, and
+incrementally creates a private pathway or \emph{circuit} of encrypted
+connections through authenticated Tor nodes on the network, negotiating a
+separate set of encryption keys for each hop along the circuit.  The circuit
+is extended one node at a time, and each node along the way knows only the
+immediately previous and following nodes in the circuit, so no individual Tor
+node knows the complete path that each fixed-sized data packet (or
+\emph{cell}) will take.
+%Because each node sees no more than one hop in the
+%circuit,
+Thus, neither an eavesdropper nor a compromised node can
+see both the connection's source and destination.  Later requests use a new
+circuit, to complicate long-term linkability between different actions by
+a single user.
+
+Tor also helps servers hide their locations while
+providing services such as web publishing or instant
+messaging.  Using ``rendezvous points'', other Tor users can
+connect to these authenticated hidden services, neither one learning the
+other's network identity.
+
+Tor attempts to anonymize the transport layer, not the application layer.
+This approach is useful for applications such as SSH
+where authenticated communication is desired. However, when anonymity from
+those with whom we communicate is desired,
+application protocols that include personally identifying information need
+additional application-level scrubbing proxies, such as
+Privoxy~\cite{privoxy} for HTTP\@.  Furthermore, Tor does not relay arbitrary
+IP packets; it only anonymizes TCP streams and DNS requests
+%, and only supports
+%connections via SOCKS
+(but see Section~\ref{subsec:tcp-vs-ip}).
+
+Most node operators do not want to allow arbitrary TCP traffic. % to leave
+%their server.
+To address this, Tor provides \emph{exit policies} so
+each exit node can block the IP addresses and ports it is unwilling to allow.
+Tor nodes advertise their exit policies to the directory servers, so that
+clients can tell which nodes will support their connections.
+
+As of January 2005, the Tor network has grown to around a hundred nodes
+on four continents, with a total capacity exceeding 1Gbit/s. Appendix A
+shows a graph of the number of working nodes over time, as well as a
+graph of the number of bytes being handled by the network over time.
+The network is now sufficiently diverse for further development
+and testing; but of course we always encourage new nodes
+to join.
+
+Tor research and development has been funded by ONR and DARPA
+for use in securing government
+communications, and by the Electronic Frontier Foundation for use
+in maintaining civil liberties for ordinary citizens online. The Tor
+protocol is one of the leading choices
+for the anonymizing layer in the European Union's PRIME directive to
+help maintain privacy in Europe.
+The AN.ON project in Germany
+has integrated an independent implementation of the Tor protocol into
+their popular Java Anon Proxy anonymizing client.
+% This wide variety of
+%interests helps maintain both the stability and the security of the
+%network.
+
+\medskip
+\noindent
+{\bf Threat models and design philosophy.}
+The ideal Tor network would be practical, useful and anonymous. When
+trade-offs arise between these properties, Tor's research strategy has been
+to remain useful enough to attract many users,
+and practical enough to support them.  Only subject to these
+constraints do we try to maximize
+anonymity.\footnote{This is not the only possible
+direction in anonymity research: designs exist that provide more anonymity
+than Tor at the expense of significantly increased resource requirements, or
+decreased flexibility in application support (typically because of increased
+latency).  Such research does not typically abandon aspirations toward
+deployability or utility, but instead tries to maximize deployability and
+utility subject to a certain degree of structural anonymity (structural because
+usability and practicality affect usage which affects the actual anonymity
+provided by the network \cite{econymics,back01}).}
+%{We believe that these
+%approaches can be promising and useful, but that by focusing on deploying a
+%usable system in the wild, Tor helps us experiment with the actual parameters
+%of what makes a system ``practical'' for volunteer operators and ``useful''
+%for home users, and helps illuminate undernoticed issues which any deployed
+%volunteer anonymity network will need to address.}
+Because of our strategy, Tor has a weaker threat model than many designs in
+the literature.  In particular, because we
+support interactive communications without impractically expensive padding,
+we fall prey to a variety
+of intra-network~\cite{back01,attack-tor-oak05,flow-correlation04} and
+end-to-end~\cite{danezis:pet2004,SS03} anonymity-breaking attacks.
+
+Tor does not attempt to defend against a global observer.  In general, an
+attacker who can measure both ends of a connection through the Tor network
+% I say 'measure' rather than 'observe', to encompass murdoch-danezis
+% style attacks. -RD
+can correlate the timing and volume of data on that connection as it enters
+and leaves the network, and so link communication partners.
+Known solutions to this attack would seem to require introducing a
+prohibitive degree of traffic padding between the user and the network, or
+introducing an unacceptable degree of latency (but see Section
+\ref{subsec:mid-latency}).  Also, it is not clear that these methods would
+work at all against a minimally active adversary who could introduce timing
+patterns or additional traffic.  Thus, Tor only attempts to defend against
+external observers who cannot observe both sides of a user's connections.
+
+
+Against internal attackers who sign up Tor nodes, the situation is more
+complicated.  In the simplest case, if an adversary has compromised $c$ of
+$n$ nodes on the Tor network, then the adversary will be able to compromise
+a random circuit with probability $\frac{c^2}{n^2}$ (since the circuit
+initiator chooses hops randomly).  But there are
+complicating factors:
+(1)~If the user continues to build random circuits over time, an adversary
+  is pretty certain to see a statistical sample of the user's traffic, and
+  thereby can build an increasingly accurate profile of her behavior.  (See
+  Section~\ref{subsec:helper-nodes} for possible solutions.)
+(2)~An adversary who controls a popular service outside the Tor network
+  can be certain to observe all connections to that service; he
+  can therefore trace connections to that service with probability
+  $\frac{c}{n}$.
+(3)~Users do not in fact choose nodes with uniform probability; they
+  favor nodes with high bandwidth or uptime, and exit nodes that
+  permit connections to their favorite services.
+(See Section~\ref{subsec:routing-zones} for discussion of larger
+adversaries and our dispersal goals.)
+
+% I'm trying to make this paragraph work without reference to the
+% analysis/confirmation distinction, which we haven't actually introduced
+% yet, and which we realize isn't very stable anyway.  Also, I don't want to
+% deprecate these attacks if we can't demonstrate that they don't work, since
+% in case they *do* turn out to work well against Tor, we'll look pretty
+% foolish. -NM
+More powerful attacks may exist. In \cite{hintz-pet02} it was
+shown that an attacker who can catalog data volumes of popular
+responder destinations (say, websites with consistent data volumes) may not
+need to
+observe both ends of a stream to learn source-destination links for those
+responders.
+Similarly, latencies of going through various routes can be
+cataloged~\cite{back01} to connect endpoints.
+% Also, \cite{kesdogan:pet2002} takes the
+% attack another level further, to narrow down where you could be
+% based on an intersection attack on subpages in a website. -RD
+It has not yet been shown whether these attacks will succeed or fail
+in the presence of the variability and volume quantization introduced by the
+Tor network, but it seems likely that these factors will at best delay
+rather than halt the attacks in the cases where they succeed.
+Along similar lines, the same paper suggests a ``clogging
+attack'' in which the throughput on a circuit is observed to slow
+down when an adversary clogs the right nodes with his own traffic.
+To determine the nodes in a circuit this attack requires the ability
+to continuously monitor the traffic exiting the network on a circuit
+that is up long enough to probe all network nodes in binary fashion.
+% Though somewhat related, clogging and interference are really different
+% attacks with different assumptions about adversary distribution and
+% capabilities as well as different techniques. -pfs
+Murdoch and Danezis~\cite{attack-tor-oak05} show a practical
+interference attack against portions of
+the fifty node Tor network as deployed in mid 2004.
+An outside attacker can actively trace a circuit through the Tor network
+by observing changes in the latency of his
+own traffic sent through various Tor nodes. This can be done
+simultaneously at multiple nodes; however, like clogging,
+this attack only reveals
+the Tor nodes in the circuit, not initiator and responder addresses,
+so it is still necessary to discover the endpoints to complete an
+effective attack. Increasing the size and diversity of the Tor network may
+help counter these attacks.
+
+%discuss $\frac{c^2}{n^2}$, except how in practice the chance of owning
+%the last hop is not $c/n$ since that doesn't take the destination (website)
+%into account. so in cases where the adversary does not also control the
+%final destination we're in good shape, but if he *does* then we'd be better
+%off with a system that lets each hop choose a path.
+%
+%Isn't it more accurate to say ``If the adversary _always_ controls the final
+% dest, we would be just as well off with such as system.'' ?  If not, why
+% not? -nm
+% Sure. In fact, better off, since they seem to scale more easily. -rd
+
+%Murdoch and Danezis describe an attack
+%\cite{attack-tor-oak05} that lets an attacker determine the nodes used
+%in a circuit; yet s/he cannot identify the initiator or responder,
+%e.g., client or web server, through this attack. So the endpoints
+%remain secure, which is the goal. It is conceivable that an
+%adversary could attack or set up observation of all connections
+%to an arbitrary Tor node in only a few minutes.  If such an adversary
+%were to exist, s/he could use this probing to remotely identify a node
+%for further attack.  Of more likely immediate practical concern
+%an adversary with active access to the responder traffic
+%wants to keep a circuit alive long enough to attack an identified
+%node. Thus it is important to prevent the responding end of the circuit
+%from keeping it open indefinitely. 
+%Also, someone could identify nodes in this way and if in their
+%jurisdiction, immediately get a subpoena (if they even need one)
+%telling the node operator(s) that she must retain all the active
+%circuit data she now has.
+%Further, the enclave model, which had previously looked to be the most
+%generally secure, seems particularly threatened by this attack, since
+%it identifies endpoints when they're also nodes in the Tor network:
+%see Section~\ref{subsec:helper-nodes} for discussion of some ways to
+%address this issue.
+
+\medskip
+\noindent
+{\bf Distributed trust.}
+In practice Tor's threat model is based on
+dispersal and diversity.
+Our defense lies in having a diverse enough set of nodes
+to prevent most real-world
+adversaries from being in the right places to attack users,
+by distributing each transaction
+over several nodes in the network.  This ``distributed trust'' approach
+means the Tor network can be safely operated and used by a wide variety
+of mutually distrustful users, providing sustainability and security.
+%than some previous attempts at anonymizing networks.
+
+No organization can achieve this security on its own.  If a single
+corporation or government agency were to build a private network to
+protect its operations, any connections entering or leaving that network
+would be obviously linkable to the controlling organization.  The members
+and operations of that agency would be easier, not harder, to distinguish.
+
+Instead, to protect our networks from traffic analysis, we must
+collaboratively blend the traffic from many organizations and private
+citizens, so that an eavesdropper can't tell which users are which,
+and who is looking for what information.  %By bringing more users onto
+%the network, all users become more secure~\cite{econymics}.
+%[XXX I feel uncomfortable saying this last sentence now. -RD]
+%[So, I took it out. I think we can do without it. -PFS]
+The Tor network has a broad range of users, including ordinary citizens
+concerned about their privacy, corporations
+who don't want to reveal information to their competitors, and law
+enforcement and government intelligence agencies who need
+to do operations on the Internet without being noticed.
+Naturally, organizations will not want to depend on others for their
+security.  If most participating providers are reliable, Tor tolerates
+some hostile infiltration of the network.  For maximum protection,
+the Tor design includes an enclave approach that lets data be encrypted
+(and authenticated) end-to-end, so high-sensitivity users can be sure it
+hasn't been read or modified.  This even works for Internet services that
+don't have built-in encryption and authentication, such as unencrypted
+HTTP or chat, and it requires no modification of those services.
+
+\subsection{Related work}
+Tor differs from other deployed systems for traffic analysis resistance
+in its security and flexibility.  Mix networks such as
+Mixmaster~\cite{mixmaster-spec} or its successor Mixminion~\cite{minion-design}
+gain the highest degrees of anonymity at the expense of introducing highly
+variable delays, making them unsuitable for applications such as web
+browsing.  Commercial single-hop
+proxies~\cite{anonymizer} can provide good performance, but
+a single compromise can expose all users' traffic, and a single-point
+eavesdropper can perform traffic analysis on the entire network.
+%Also, their proprietary implementations place any infrastructure that
+%depends on these single-hop solutions at the mercy of their providers'
+%financial health as well as network security.
+The Java
+Anon Proxy~\cite{web-mix} provides similar functionality to Tor but
+handles only web browsing rather than all TCP\@.
+%Some peer-to-peer file-sharing overlay networks such as
+%Freenet~\cite{freenet} and Mute~\cite{mute}
+The Freedom 
+network from Zero-Knowledge Systems~\cite{freedom21-security}
+was even more flexible than Tor in
+transporting arbitrary IP packets, and also supported
+pseudonymity in addition to anonymity; but it had
+a different approach to sustainability (collecting money from users
+and paying ISPs to run Tor nodes), and was eventually shut down due to financial
+load.  Finally, %potentially more scalable
+% [I had added 'potentially' because the scalability of these designs
+% is not established, and I am uncomfortable making the
+% bolder unmodified assertion. Roger took 'potentially' out.
+% Here's an attempt at more neutral wording -pfs]
+peer-to-peer designs that are intended to be more scalable,
+for example Tarzan~\cite{tarzan:ccs02} and
+MorphMix~\cite{morphmix:fc04}, have been proposed in the literature but
+have not been fielded. These systems differ somewhat
+in threat model and presumably practical resistance to threats.
+Note that MorphMix differs from Tor only in
+node discovery and circuit setup; so Tor's architecture is flexible
+enough to contain a MorphMix experiment.
+We direct the interested reader
+to~\cite{tor-design} for a more in-depth review of related work.
+
+%XXXX six-four. crowds. i2p.
+
+%XXXX
+%have a serious discussion of morphmix's assumptions, since they would
+%seem to be the direct competition. in fact tor is a flexible architecture
+%that would encompass morphmix, and they're nearly identical except for
+%path selection and node discovery. and the trust system morphmix has
+%seems overkill (and/or insecure) based on the threat model we've picked.
+% this para should probably move to the scalability / directory system. -RD
+% Nope. Cut for space, except for small comment added above -PFS
+
+\section{Social challenges}
+
+Many of the issues the Tor project needs to address extend beyond
+system design and technology development. In particular, the
+Tor project's \emph{image} with respect to its users and the rest of
+the Internet impacts the security it can provide.
+With this image issue in mind, this section discusses the Tor user base and
+Tor's interaction with other services on the Internet.
+
+\subsection{Communicating security}
+
+Usability for anonymity systems
+contributes to their security, because usability
+affects the possible anonymity set~\cite{econymics,back01}.
+Conversely, an unusable system attracts few users and thus can't provide
+much anonymity.
+
+This phenomenon has a second-order effect: knowing this, users should
+choose which anonymity system to use based in part on how usable
+and secure
+\emph{others} will find it, in order to get the protection of a larger
+anonymity set. Thus we might supplement the adage ``usability is a security
+parameter''~\cite{back01} with a new one: ``perceived usability is a
+security parameter.'' From here we can better understand the effects
+of publicity on security: the more convincing your
+advertising, the more likely people will believe you have users, and thus
+the more users you will attract. Perversely, over-hyped systems (if they
+are not too broken) may be a better choice than modestly promoted ones,
+if the hype attracts more users~\cite{usability-network-effect}.
+
+So it follows that we should come up with ways to accurately communicate
+the available security levels to the user, so she can make informed
+decisions. JAP aims to do this by including a
+comforting `anonymity meter' dial in the software's graphical interface,
+giving the user an impression of the level of protection for her current
+traffic.
+
+However, there's a catch. For users to share the same anonymity set,
+they need to act like each other. An attacker who can distinguish
+a given user's traffic from the rest of the traffic will not be
+distracted by anonymity set size. For high-latency systems like
+Mixminion, where the threat model is based on mixing messages with each
+other, there's an arms race between end-to-end statistical attacks and
+counter-strategies~\cite{statistical-disclosure,minion-design,e2e-traffic,trickle02}.
+But for low-latency systems like Tor, end-to-end \emph{traffic
+correlation} attacks~\cite{danezis:pet2004,defensive-dropping,SS03}
+allow an attacker who can observe both ends of a communication
+to correlate packet timing and volume, quickly linking
+the initiator to her destination.
+
+Like Tor, the current JAP implementation does not pad connections
+apart from using small fixed-size cells for transport. In fact,
+JAP's cascade-based network topology may be more vulnerable to these
+attacks, because its network has fewer edges. JAP was born out of
+the ISDN mix design~\cite{isdn-mixes}, where padding made sense because
+every user had a fixed bandwidth allocation and altering the timing
+pattern of packets could be immediately detected. But in its current context
+as an Internet web anonymizer, adding sufficient padding to JAP
+would probably be prohibitively expensive and ineffective against a
+minimally active attacker.\footnote{Even if JAP could
+fund higher-capacity nodes indefinitely, our experience
+suggests that many users would not accept the increased per-user
+bandwidth requirements, leading to an overall much smaller user base. But
+see Section~\ref{subsec:mid-latency}.} Therefore, since under this threat
+model the number of concurrent users does not seem to have much impact
+on the anonymity provided, we suggest that JAP's anonymity meter is not
+accurately communicating security levels to its users.
+
+On the other hand, while the number of active concurrent users may not
+matter as much as we'd like, it still helps to have some other users
+on the network. We investigate this issue next.
+
+\subsection{Reputability and perceived social value}
+Another factor impacting the network's security is its reputability:
+the perception of its social value based on its current user base. If Alice is
+the only user who has ever downloaded the software, it might be socially
+accepted, but she's not getting much anonymity. Add a thousand
+activists, and she's anonymous, but everyone thinks she's an activist too.
+Add a thousand
+diverse citizens (cancer survivors, privacy enthusiasts, and so on)
+and now she's harder to profile.
+
+Furthermore, the network's reputability affects its operator base: more people
+are willing to run a service if they believe it will be used by human rights
+workers than if they believe it will be used exclusively for disreputable
+ends.  This effect becomes stronger if node operators themselves think they
+will be associated with their users' disreputable ends.
+
+So the more cancer survivors on Tor, the better for the human rights
+activists. The more malicious hackers, the worse for the normal users. Thus,
+reputability is an anonymity issue for two reasons. First, it impacts
+the sustainability of the network: a network that's always about to be
+shut down has difficulty attracting and keeping adequate nodes.
+Second, a disreputable network is more vulnerable to legal and
+political attacks, since it will attract fewer supporters.
+
+While people therefore have an incentive for the network to be used for
+``more reputable'' activities than their own, there are still trade-offs
+involved when it comes to anonymity. To follow the above example, a
+network used entirely by cancer survivors might welcome file sharers
+onto the network, though of course they'd prefer a wider
+variety of users.
+
+Reputability becomes even more tricky in the case of privacy networks,
+since the good uses of the network (such as publishing by journalists in
+dangerous countries) are typically kept private, whereas network abuses
+or other problems tend to be more widely publicized.
+
+The impact of public perception on security is especially important
+during the bootstrapping phase of the network, where the first few
+widely publicized uses of the network can dictate the types of users it
+attracts next.
+As an example, some U.S.~Department of Energy
+penetration testing engineers are tasked with compromising DoE computers
+from the outside. They only have a limited number of ISPs from which to
+launch their attacks, and they found that the defenders were recognizing
+attacks because they came from the same IP space. These engineers wanted
+to use Tor to hide their tracks. First, from a technical standpoint,
+Tor does not support the variety of IP packets one would like to use in
+such attacks (see Section~\ref{subsec:tcp-vs-ip}). But aside from this,
+we also decided that it would probably be poor precedent to encourage
+such use---even legal use that improves national security---and managed
+to dissuade them.
+
+%% "outside of academia, jap has just lost, permanently".  (That is,
+%% even though the crime detection issues are resolved and are unlikely
+%% to go down the same way again, public perception has not been kind.)
+
+\subsection{Sustainability and incentives}
+One of the unsolved problems in low-latency anonymity designs is
+how to keep the nodes running.  ZKS's Freedom network
+depended on paying third parties to run its servers; the JAP project's
+bandwidth depends on grants to pay for its bandwidth and
+administrative expenses.  In Tor, bandwidth and administrative costs are
+distributed across the volunteers who run Tor nodes, so we at least have
+reason to think that the Tor network could survive without continued research
+funding.\footnote{It also helps that Tor is implemented with free and open
+  source software that can be maintained by anybody with the ability and
+  inclination.}  But why are these volunteers running nodes, and what can we
+do to encourage more volunteers to do so?
+
+We have not formally surveyed Tor node operators to learn why they are
+running nodes, but
+from the information they have provided, it seems that many of them run Tor
+nodes for reasons of personal interest in privacy issues.  It is possible
+that others are running Tor nodes to protect their own
+anonymity, but of course they are
+hardly likely to tell us specifics if they are.
+%Significantly, Tor's threat model changes the anonymity incentives for running
+%a node.  In a high-latency mix network, users can receive additional
+%anonymity by running their own node, since doing so obscures when they are
+%injecting messages into the network.  But, anybody observing all I/O to a Tor
+%node can tell when the node is generating traffic that corresponds to
+%none of its incoming traffic.
+%
+%I didn't buy the above for reason's subtle enough that I just cut it -PFS
+Tor exit node operators do attain a degree of
+``deniability'' for traffic that originates at that exit node.  For
+  example, it is likely in practice that HTTP requests from a Tor node's IP
+  will be assumed to be from the Tor network.
+  More significantly, people and organizations who use Tor for
+  anonymity depend on the
+  continued existence of the Tor network to do so; running a node helps to
+  keep the network operational.
+%\item Local Tor entry and exit nodes allow users on a network to run in an
+%  `enclave' configuration.  [XXXX need to resolve this. They would do this
+%   for E2E encryption + auth?]
+
+
+%We must try to make the costs of running a Tor node easily minimized.
+Since Tor is run by volunteers, the most crucial software usability issue is
+usability by operators: when an operator leaves, the network becomes less
+usable by everybody.  To keep operators pleased, we must try to keep Tor's
+resource and administrative demands as low as possible.
+
+Because of ISP billing structures, many Tor operators have underused capacity
+that they are willing to donate to the network, at no additional monetary
+cost to them.  Features to limit bandwidth have been essential to adoption.
+Also useful has been a ``hibernation'' feature that allows a Tor node that
+wants to provide high bandwidth, but no more than a certain amount in a
+giving billing cycle, to become dormant once its bandwidth is exhausted, and
+to reawaken at a random offset into the next billing cycle.  This feature has
+interesting policy implications, however; see
+the next section below.
+Exit policies help to limit administrative costs by limiting the frequency of
+abuse complaints (see Section~\ref{subsec:tor-and-blacklists}). We discuss
+technical incentive mechanisms in Section~\ref{subsec:incentives-by-design}.
+
+%[XXXX say more.  Why else would you run a node? What else can we do/do we
+%  already do to make running a node more attractive?]
+%[We can enforce incentives; see Section 6.1. We can rate-limit clients.
+%  We can put "top bandwidth nodes lists" up a la seti at home.]
+
+\subsection{Bandwidth and file-sharing}
+\label{subsec:bandwidth-and-file-sharing}
+%One potentially problematical area with deploying Tor has been our response
+%to file-sharing applications.
+Once users have configured their applications to work with Tor, the largest
+remaining usability issue is performance.  Users begin to suffer
+when websites ``feel slow.''
+Clients currently try to build their connections through nodes that they
+guess will have enough bandwidth.  But even if capacity is allocated
+optimally, it seems unlikely that the current network architecture will have
+enough capacity to provide every user with as much bandwidth as she would
+receive if she weren't using Tor, unless far more nodes join the network.
+
+%Limited capacity does not destroy the network, however.  Instead, usage tends
+%towards an equilibrium: when performance suffers, users who value performance
+%over anonymity tend to leave the system, thus freeing capacity until the
+%remaining users on the network are exactly those willing to use that capacity
+%there is.
+
+Much of Tor's recent bandwidth difficulties have come from file-sharing
+applications.  These applications provide two challenges to
+any anonymizing network: their intensive bandwidth requirement, and the
+degree to which they are associated (correctly or not) with copyright
+infringement.
+
+High-bandwidth protocols can make the network unresponsive,
+but tend to be somewhat self-correcting as lack of bandwidth drives away
+users who need it.  Issues of copyright violation,
+however, are more interesting.  Typical exit node operators want to help
+people achieve private and anonymous speech, not to help people (say) host
+Vin Diesel movies for download; and typical ISPs would rather not
+deal with customers who draw menacing letters
+from the MPAA\@.  While it is quite likely that the operators are doing nothing
+illegal, many ISPs have policies of dropping users who get repeated legal
+threats regardless of the merits of those threats, and many operators would
+prefer to avoid receiving even meritless legal threats.
+So when letters arrive, operators are likely to face
+pressure to block file-sharing applications entirely, in order to avoid the
+hassle.
+
+But blocking file-sharing is not easy: popular
+protocols have evolved to run on non-standard ports to
+get around other port-based bans.  Thus, exit node operators who want to
+block file-sharing would have to find some way to integrate Tor with a
+protocol-aware exit filter.  This could be a technically expensive
+undertaking, and one with poor prospects: it is unlikely that Tor exit nodes
+would succeed where so many institutional firewalls have failed.  Another
+possibility for sensitive operators is to run a restrictive node that
+only permits exit connections to a restricted range of ports that are
+not frequently associated with file sharing.  There are increasingly few such
+ports.
+
+Other possible approaches might include rate-limiting connections, especially
+long-lived connections or connections to file-sharing ports, so that
+high-bandwidth connections do not flood the network.  We might also want to
+give priority to cells on low-bandwidth connections to keep them interactive,
+but this could have negative anonymity implications.
+
+For the moment, it seems that Tor's bandwidth issues have rendered it
+unattractive for bulk file-sharing traffic; this may continue to be so in the
+future.  Nevertheless, Tor will likely remain attractive for limited use in
+file-sharing protocols that have separate control and data channels.
+
+%[We should say more -- but what?  That we'll see a similar
+%  equilibriating effect as with bandwidth, where sensitive ops switch to
+%  middleman, and we become less useful for file-sharing, so the file-sharing
+%  people back off, so we get more ops since there's less file-sharing, so the
+%  file-sharers come back, etc.]
+
+%XXXX
+%in practice, plausible deniability is hypothetical and doesn't seem very
+%convincing. if ISPs find the activity antisocial, they don't care *why*
+%your computer is doing that behavior.
+
+\subsection{Tor and blacklists}
+\label{subsec:tor-and-blacklists}
+
+It was long expected that, alongside legitimate users, Tor would also
+attract troublemakers who exploit Tor to abuse services on the
+Internet with vandalism, rude mail, and so on.
+Our initial answer to this situation was to use ``exit policies''
+to allow individual Tor nodes to block access to specific IP/port ranges.
+This approach aims to make operators more willing to run Tor by allowing
+them to prevent their nodes from being used for abusing particular
+services.  For example, all Tor nodes currently block SMTP (port 25),
+to avoid being used for spam.
+
+Exit policies are useful, but they are insufficient: if not all nodes
+block a given service, that service may try to block Tor instead.
+While being blockable is important to being good netizens, we would like
+to encourage services to allow anonymous access. Services should not
+need to decide between blocking legitimate anonymous use and allowing
+unlimited abuse.
+
+This is potentially a bigger problem than it may appear.
+On the one hand, services should be allowed to refuse connections from
+sources of possible abuse.
+But when a Tor node administrator decides whether he prefers to be able
+to post to Wikipedia from his IP address, or to allow people to read
+Wikipedia anonymously through his Tor node, he is making the decision
+for others as well. (For a while, Wikipedia
+blocked all posting from all Tor nodes based on IP addresses.) If
+the Tor node shares an address with a campus or corporate NAT,
+then the decision can prevent the entire population from posting.
+This is a loss for both Tor
+and Wikipedia: we don't want to compete for (or divvy up) the
+NAT-protected entities of the world.
+
+Worse, many IP blacklists are coarse-grained: they ignore Tor's exit
+policies, partly because it's easier to implement and partly
+so they can punish
+all Tor nodes. One IP blacklist even bans
+every class C network that contains a Tor node, and recommends banning SMTP
+from these networks even though Tor does not allow SMTP at all.  This
+strategic decision aims to discourage the
+operation of anything resembling an open proxy by encouraging its neighbors
+to shut it down to get unblocked themselves. This pressure even
+affects Tor nodes running in middleman mode (disallowing all exits) when
+those nodes are blacklisted too.
+
+Problems of abuse occur mainly with services such as IRC networks and
+Wikipedia, which rely on IP blocking to ban abusive users.  While at first
+blush this practice might seem to depend on the anachronistic assumption that
+each IP is an identifier for a single user, it is actually more reasonable in
+practice: it assumes that non-proxy IPs are a costly resource, and that an
+abuser can not change IPs at will.  By blocking IPs which are used by Tor
+nodes, open proxies, and service abusers, these systems hope to make
+ongoing abuse difficult.  Although the system is imperfect, it works
+tolerably well for them in practice.
+
+Of course, we would prefer that legitimate anonymous users be able to
+access abuse-prone services.  One conceivable approach would require
+would-be IRC users, for instance, to register accounts if they want to
+access the IRC network from Tor.  In practice this would not
+significantly impede abuse if creating new accounts were easily automatable;
+this is why services use IP blocking.  To deter abuse, pseudonymous
+identities need to require a significant switching cost in resources or human
+time.  Some popular webmail applications
+impose cost with Reverse Turing Tests, but this step may not deter all
+abusers.  Freedom used blind signatures to limit
+the number of pseudonyms for each paying account, but Tor has neither the
+ability nor the desire to collect payment.
+
+We stress that as far as we can tell, most Tor uses are not
+abusive. Most services have not complained, and others are actively
+working to find ways besides banning to cope with the abuse. For example,
+the Freenode IRC network had a problem with a coordinated group of
+abusers joining channels and subtly taking over the conversation; but
+when they labelled all users coming from Tor IPs as ``anonymous users,''
+removing the ability of the abusers to blend in, the abuse stopped.
+
+%The use of squishy IP-based ``authentication'' and ``authorization''
+%has not broken down even to the level that SSNs used for these
+%purposes have in commercial and public record contexts. Externalities
+%and misplaced incentives cause a continued focus on fighting identity
+%theft by protecting SSNs rather than developing better authentication
+%and incentive schemes \cite{price-privacy}. Similarly we can expect a
+%continued use of identification by IP number as long as there is no
+%workable alternative.
+
+%[XXX Mention correct DNS-RBL implementation. -NM]
+
+\section{Design choices}
+
+In addition to social issues, Tor also faces some design trade-offs that must
+be investigated as the network develops.
+
+\subsection{Transporting the stream vs transporting the packets}
+\label{subsec:stream-vs-packet}
+\label{subsec:tcp-vs-ip}
+
+Tor transports streams; it does not tunnel packets.
+It has often been suggested that like the old Freedom
+network~\cite{freedom21-security}, Tor should
+``obviously'' anonymize IP traffic
+at the IP layer. Before this could be done, many issues need to be resolved:
+
+\begin{enumerate}
+\setlength{\itemsep}{0mm}
+\setlength{\parsep}{0mm}
+\item \emph{IP packets reveal OS characteristics.}  We would still need to do
+IP-level packet normalization, to stop things like TCP fingerprinting
+attacks. %There likely exist libraries that can help with this.
+This is unlikely to be a trivial task, given the diversity and complexity of
+TCP stacks.
+\item \emph{Application-level streams still need scrubbing.} We still need
+Tor to be easy to integrate with user-level application-specific proxies
+such as Privoxy. So it's not just a matter of capturing packets and
+anonymizing them at the IP layer.
+\item \emph{Certain protocols will still leak information.} For example, we
+must rewrite DNS requests so they are delivered to an unlinkable DNS server
+rather than the DNS server at a user's ISP; thus, we must understand the
+protocols we are transporting.
+\item \emph{The crypto is unspecified.} First we need a block-level encryption
+approach that can provide security despite
+packet loss and out-of-order delivery. Freedom allegedly had one, but it was
+never publicly specified.
+Also, TLS over UDP is not yet implemented or
+specified, though some early work has begun~\cite{dtls}.
+\item \emph{We'll still need to tune network parameters.} Since the above
+encryption system will likely need sequence numbers (and maybe more) to do
+replay detection, handle duplicate frames, and so on, we will be reimplementing
+a subset of TCP anyway---a notoriously tricky path.
+\item \emph{Exit policies for arbitrary IP packets mean building a secure
+IDS\@.}  Our node operators tell us that exit policies are one of
+the main reasons they're willing to run Tor.
+Adding an Intrusion Detection System to handle exit policies would
+increase the security complexity of Tor, and would likely not work anyway,
+as evidenced by the entire field of IDS and counter-IDS papers. Many
+potential abuse issues are resolved by the fact that Tor only transports
+valid TCP streams (as opposed to arbitrary IP including malformed packets
+and IP floods), so exit policies become even \emph{more} important as
+we become able to transport IP packets. We also need to compactly
+describe exit policies so clients can predict
+which nodes will allow which packets to exit.
+\item \emph{The Tor-internal name spaces would need to be redesigned.} We
+support hidden service {\tt{.onion}} addresses (and other special addresses,
+like {\tt{.exit}} which lets the user request a particular exit node),
+by intercepting the addresses when they are passed to the Tor client.
+Doing so at the IP level would require a more complex interface between
+Tor and the local DNS resolver.
+\end{enumerate}
+
+This list is discouragingly long, but being able to transport more
+protocols obviously has some advantages. It would be good to learn which
+items are actual roadblocks and which are easier to resolve than we think.
+
+To be fair, Tor's stream-based approach has run into
+stumbling blocks as well. While Tor supports the SOCKS protocol,
+which provides a standardized interface for generic TCP proxies, many
+applications do not support SOCKS\@. For them we already need to
+replace the networking system calls with SOCKS-aware
+versions, or run a SOCKS tunnel locally, neither of which is
+easy for the average user. %---even with good instructions.
+Even when applications can use SOCKS, they often make DNS requests
+themselves before handing an IP address to Tor, which advertises
+where the user is about to connect.
+We are still working on more usable solutions.
+
+%So to actually provide good anonymity, we need to make sure that
+%users have a practical way to use Tor anonymously.  Possibilities include
+%writing wrappers for applications to anonymize them automatically; improving
+%the applications' support for SOCKS; writing libraries to help application
+%writers use Tor properly; and implementing a local DNS proxy to reroute DNS
+%requests to Tor so that applications can simply point their DNS resolvers at
+%localhost and continue to use SOCKS for data only.
+
+\subsection{Mid-latency}
+\label{subsec:mid-latency}
+
+Some users need to resist traffic correlation attacks.  Higher-latency
+mix-networks introduce variability into message
+arrival times: as timing variance increases, timing correlation attacks
+require increasingly more data~\cite{e2e-traffic}. Can we improve Tor's
+resistance without losing too much usability?
+
+We need to learn whether we can trade a small increase in latency
+for a large anonymity increase, or if we'd end up trading a lot of
+latency for only a minimal security gain. A trade-off might be worthwhile
+even if we
+could only protect certain use cases, such as infrequent short-duration
+transactions. % To answer this question
+We might adapt the techniques of~\cite{e2e-traffic} to a lower-latency mix
+network, where the messages are batches of cells in temporally clustered
+connections. These large fixed-size batches can also help resist volume
+signature attacks~\cite{hintz-pet02}. We could also experiment with traffic
+shaping to get a good balance of throughput and security.
+%Other padding regimens might supplement the
+%mid-latency option; however, we should continue the caution with which
+%we have always approached padding lest the overhead cost us too much
+%performance or too many volunteers.
+
+We must keep usability in mind too. How much can latency increase
+before we drive users away? We've already been forced to increase
+latency slightly, as our growing network incorporates more DSL and
+cable-modem nodes and more nodes in distant continents. Perhaps we can
+harness this increased latency to improve anonymity rather than just
+reduce usability. Further, if we let clients label certain circuits as
+mid-latency as they are constructed, we could handle both types of traffic
+on the same network, giving users a choice between speed and security---and
+giving researchers a chance to experiment with parameters to improve the
+quality of those choices.
+
+\subsection{Enclaves and helper nodes}
+\label{subsec:helper-nodes}
+
+It has long been thought that users can improve their anonymity by
+running their own node~\cite{tor-design,or-ih96,or-pet00}, and using
+it in an \emph{enclave} configuration, where all their circuits begin
+at the node under their control. Running Tor clients or servers at
+the enclave perimeter is useful when policy or other requirements
+prevent individual machines within the enclave from running Tor
+clients~\cite{or-jsac98,or-discex00}.
+
+Of course, Tor's default path length of
+three is insufficient for these enclaves, since the entry and/or exit
+% [edit war: without the ``and/'' the natural reading here
+% is aut rather than vel. And the use of the plural verb does not work -pfs]
+themselves are sensitive. Tor thus increments path length by one
+for each sensitive endpoint in the circuit.
+Enclaves also help to protect against end-to-end attacks, since it's
+possible that traffic coming from the node has simply been relayed from
+elsewhere. However, if the node has recognizable behavior patterns,
+an attacker who runs nodes in the network can triangulate over time to
+gain confidence that it is in fact originating the traffic. Wright et
+al.~\cite{wright03} introduce the notion of a \emph{helper node}---a
+single fixed entry node for each user---to combat this \emph{predecessor
+attack}.
+
+However, the attack in~\cite{attack-tor-oak05} shows that simply adding
+to the path length, or using a helper node, may not protect an enclave
+node. A hostile web server can send constant interference traffic to
+all nodes in the network, and learn which nodes are involved in the
+circuit (though at least in the current attack, he can't learn their
+order). Using randomized path lengths may help some, since the attacker
+will never be certain he has identified all nodes in the path unless
+he probes the entire network, but as
+long as the network remains small this attack will still be feasible.
+
+Helper nodes also aim to help Tor clients, because choosing entry and exit
+points
+randomly and changing them frequently allows an attacker who controls
+even a few nodes to eventually link some of their destinations. The goal
+is to take the risk once and for all about choosing a bad entry node,
+rather than taking a new risk for each new circuit. (Choosing fixed
+exit nodes is less useful, since even an honest exit node still doesn't
+protect against a hostile website.) But obstacles remain before
+we can implement helper nodes.
+For one, the literature does not describe how to choose helpers from a list
+of nodes that changes over time.  If Alice is forced to choose a new entry
+helper every $d$ days and $c$ of the $n$ nodes are bad, she can expect
+to choose a compromised node around
+every $dc/n$ days. Statistically over time this approach only helps
+if she is better at choosing honest helper nodes than at choosing
+honest nodes.  Worse, an attacker with the ability to DoS nodes could
+force users to switch helper nodes more frequently, or remove
+other candidate helpers.
+
+%Do general DoS attacks have anonymity implications? See e.g. Adam
+%Back's IH paper, but I think there's more to be pointed out here. -RD
+% Not sure what you want to say here. -NM
+
+%Game theory for helper nodes: if Alice offers a hidden service on a
+%server (enclave model), and nobody ever uses helper nodes, then against
+%George+Steven's attack she's totally nailed. If only Alice uses a helper
+%node, then she's still identified as the source of the data. If everybody
+%uses a helper node (including Alice), then the attack identifies the
+%helper node and also Alice, and knows which one is which. If everybody
+%uses a helper node (but not Alice), then the attacker figures the real
+%source was a client that is using Alice as a helper node. [How's my
+%logic here?] -RD
+%
+% Not sure about the logic.  For the attack to work with helper nodes, the
+%attacker needs to guess that Alice is running the hidden service, right?
+%Otherwise, how can he know to measure her traffic specifically? -NM
+%
+% In the Murdoch-Danezis attack, the adversary measures all servers. -RD
+
+%point to routing-zones section re: helper nodes to defend against
+%big stuff.
+
+\subsection{Location-hidden services}
+\label{subsec:hidden-services}
+
+% This section is first up against the wall when the revolution comes.
+
+Tor's \emph{rendezvous points}
+let users provide TCP services to other Tor users without revealing
+the service's location. Since this feature is relatively recent, we describe
+here
+a couple of our early observations from its deployment.
+
+First, our implementation of hidden services seems less hidden than we'd
+like, since they build a different rendezvous circuit for each user,
+and an external adversary can induce them to
+produce traffic. This insecurity means that they may not be suitable as
+a building block for Free Haven~\cite{freehaven-berk} or other anonymous
+publishing systems that aim to provide long-term security, though helper
+nodes, as discussed above, would seem to help.
+
+\emph{Hot-swap} hidden services, where more than one location can
+provide the service and loss of any one location does not imply a
+change in service, would help foil intersection and observation attacks
+where an adversary monitors availability of a hidden service and also
+monitors whether certain users or servers are online. The design
+challenges in providing such services without otherwise compromising
+the hidden service's anonymity remain an open problem;
+however, see~\cite{move-ndss05}.
+
+In practice, hidden services are used for more than just providing private
+access to a web server or IRC server. People are using hidden services
+as a poor man's VPN and firewall-buster. Many people want to be able
+to connect to the computers in their private network via secure shell,
+and rather than playing with dyndns and trying to pierce holes in their
+firewall, they run a hidden service on the inside and then rendezvous
+with that hidden service externally.
+
+News sites like Bloggers Without Borders (www.b19s.org) are advertising
+a hidden-service address on their front page. Doing this can provide
+increased robustness if they use the dual-IP approach we describe
+in~\cite{tor-design},
+but in practice they do it to increase visibility
+of the Tor project and their support for privacy, and to offer
+a way for their users, using unmodified software, to get end-to-end
+encryption and authentication to their website.
+
+\subsection{Location diversity and ISP-class adversaries}
+\label{subsec:routing-zones}
+
+Anonymity networks have long relied on diversity of node location for
+protection against attacks---typically an adversary who can observe a
+larger fraction of the network can launch a more effective attack. One
+way to achieve dispersal involves growing the network so a given adversary
+sees less. Alternately, we can arrange the topology so traffic can enter
+or exit at many places (for example, by using a free-route network
+like Tor rather than a cascade network like JAP). Lastly, we can use
+distributed trust to spread each transaction over multiple jurisdictions.
+But how do we decide whether two nodes are in related locations?
+
+Feamster and Dingledine defined a \emph{location diversity} metric
+in~\cite{feamster:wpes2004}, and began investigating a variant of location
+diversity based on the fact that the Internet is divided into thousands of
+independently operated networks called {\em autonomous systems} (ASes).
+The key insight from their paper is that while we typically think of a
+connection as going directly from the Tor client to the first Tor node,
+actually it traverses many different ASes on each hop. An adversary at
+any of these ASes can monitor or influence traffic. Specifically, given
+plausible initiators and recipients, and given random path selection,
+some ASes in the simulation were able to observe 10\% to 30\% of the
+transactions (that is, learn both the origin and the destination) on
+the deployed Tor network (33 nodes as of June 2004).
+
+The paper concludes that for best protection against the AS-level
+adversary, nodes should be in ASes that have the most links to other ASes:
+Tier-1 ISPs such as AT\&T and Abovenet. Further, a given transaction
+is safest when it starts or ends in a Tier-1 ISP\@. Therefore, assuming
+initiator and responder are both in the U.S., it actually \emph{hurts}
+our location diversity to use far-flung nodes in
+continents like Asia or South America.
+% it's not just entering or exiting from them. using them as the middle
+% hop reduces your effective path length, which you presumably don't
+% want because you chose that path length for a reason.
+%
+% Not sure I buy that argument. Two end nodes in the right ASs to
+% discourage linking are still not known to each other. If some
+% adversary in a single AS can bridge the middle node, it shouldn't
+% therefore be able to identify initiator or responder; although it could
+% contribute to further attacks given more assumptions.
+% Nonetheless, no change to the actual text for now.
+
+Many open questions remain. First, it will be an immense engineering
+challenge to get an entire BGP routing table to each Tor client, or to
+summarize it sufficiently. Without a local copy, clients won't be
+able to safely predict what ASes will be traversed on the various paths
+through the Tor network to the final destination. Tarzan~\cite{tarzan:ccs02}
+and MorphMix~\cite{morphmix:fc04} suggest that we compare IP prefixes to
+determine location diversity; but the above paper showed that in practice
+many of the Mixmaster nodes that share a single AS have entirely different
+IP prefixes. When the network has scaled to thousands of nodes, does IP
+prefix comparison become a more useful approximation? % Alternatively, can
+%relevant parts of the routing tables be summarized centrally and delivered to
+%clients in a less verbose format?
+%% i already said "or to summarize is sufficiently" above. is that not
+%% enough? -RD
+%
+Second, we can take advantage of caching certain content at the
+exit nodes, to limit the number of requests that need to leave the
+network at all. What about taking advantage of caches like Akamai or
+Google~\cite{shsm03}? (Note that they're also well-positioned as global
+adversaries.)
+%
+Third, if we follow the recommendations in~\cite{feamster:wpes2004}
+ and tailor path selection
+to avoid choosing endpoints in similar locations, how much are we hurting
+anonymity against larger real-world adversaries who can take advantage
+of knowing our algorithm?
+%
+Fourth, can we use this knowledge to figure out which gaps in our network
+most affect our robustness to this class of attack, and go recruit
+new nodes with those ASes in mind?
+
+%Tor's security relies in large part on the dispersal properties of its
+%network. We need to be more aware of the anonymity properties of various
+%approaches so we can make better design decisions in the future.
+
+\subsection{The Anti-censorship problem}
+\label{subsec:china}
+
+Citizens in a variety of countries, such as most recently China and
+Iran, are blocked from accessing various sites outside
+their country. These users try to find any tools available to allow
+them to get around these firewalls. Some anonymity networks, such as
+Six-Four~\cite{six-four}, are designed specifically with this goal in
+mind; others like the Anonymizer~\cite{anonymizer} are paid by sponsors
+such as Voice of America to encourage Internet
+freedom. Even though Tor wasn't
+designed with ubiquitous access to the network in mind, thousands of
+users across the world are now using it for exactly this purpose.
+% Academic and NGO organizations, peacefire, \cite{berkman}, etc
+
+Anti-censorship networks hoping to bridge country-level blocks face
+a variety of challenges. One of these is that they need to find enough
+exit nodes---servers on the `free' side that are willing to relay
+traffic from users to their final destinations. Anonymizing
+networks like Tor are well-suited to this task since we have
+already gathered a set of exit nodes that are willing to tolerate some
+political heat.
+
+The other main challenge is to distribute a list of reachable relays
+to the users inside the country, and give them software to use those relays,
+without letting the censors also enumerate this list and block each
+relay. Anonymizer solves this by buying lots of seemingly-unrelated IP
+addresses (or having them donated), abandoning old addresses as they are
+`used up,' and telling a few users about the new ones. Distributed
+anonymizing networks again have an advantage here, in that we already
+have tens of thousands of separate IP addresses whose users might
+volunteer to provide this service since they've already installed and use
+the software for their own privacy~\cite{koepsell:wpes2004}. Because
+the Tor protocol separates routing from network discovery \cite{tor-design},
+volunteers could configure their Tor clients
+to generate node descriptors and send them to a special directory
+server that gives them out to dissidents who need to get around blocks.
+
+Of course, this still doesn't prevent the adversary
+from enumerating and preemptively blocking the volunteer relays.
+Perhaps a tiered-trust system could be built where a few individuals are
+given relays' locations. They could then recommend other individuals
+by telling them
+those addresses, thus providing a built-in incentive to avoid letting the
+adversary intercept them. Max-flow trust algorithms~\cite{advogato}
+might help to bound the number of IP addresses leaked to the adversary. Groups
+like the W3C are looking into using Tor as a component in an overall system to
+help address censorship; we wish them success.
+
+%\cite{infranet}
+
+\section{Scaling}
+\label{sec:scaling}
+
+Tor is running today with hundreds of nodes and tens of thousands of
+users, but it will certainly not scale to millions.
+Scaling Tor involves four main challenges. First, to get a
+large set of nodes, we must address incentives for
+users to carry traffic for others. Next is safe node discovery, both
+while bootstrapping (Tor clients must robustly find an initial
+node list) and later (Tor clients must learn about a fair sample
+of honest nodes and not let the adversary control circuits).
+We must also detect and handle node speed and reliability as the network
+becomes increasingly heterogeneous: since the speed and reliability
+of a circuit is limited by its worst link, we must learn to track and
+predict performance. Finally, we must stop assuming that all points on
+the network can connect to all other points.
+
+\subsection{Incentives by Design}
+\label{subsec:incentives-by-design}
+
+There are three behaviors we need to encourage for each Tor node: relaying
+traffic; providing good throughput and reliability while doing it;
+and allowing traffic to exit the network from that node.
+
+We encourage these behaviors through \emph{indirect} incentives: that
+is, by designing the system and educating users in such a way that users
+with certain goals will choose to relay traffic.  One
+main incentive for running a Tor node is social: volunteers
+altruistically donate their bandwidth and time.  We encourage this with
+public rankings of the throughput and reliability of nodes, much like
+seti at home.  We further explain to users that they can get
+deniability for any traffic emerging from the same address as a Tor
+exit node, and they can use their own Tor node
+as an entry or exit point with confidence that it's not run by an adversary.
+Further, users may run a node simply because they need such a network
+to be persistently available and usable, and the value of supporting this
+exceeds any countervening costs.
+Finally, we can encourage operators by improving the usability and feature
+set of the software:
+rate limiting support and easy packaging decrease the hassle of
+maintaining a node, and our configurable exit policies allow each
+operator to advertise a policy describing the hosts and ports to which
+he feels comfortable connecting.
+
+To date these incentives appear to have been adequate. As the system scales
+or as new issues emerge, however, we may also need to provide
+ \emph{direct} incentives:
+providing payment or other resources in return for high-quality service.
+Paying actual money is problematic: decentralized e-cash systems are
+not yet practical, and a centralized collection system not only reduces
+robustness, but also has failed in the past (the history of commercial
+anonymizing networks is littered with failed attempts).  A more promising
+option is to use a tit-for-tat incentive scheme, where nodes provide better
+service to nodes that have provided good service for them.
+
+Unfortunately, such an approach introduces new anonymity problems.
+There are many surprising ways for nodes to game the incentive and
+reputation system to undermine anonymity---such systems are typically
+designed to encourage fairness in storage or bandwidth usage, not
+fairness of provided anonymity. An adversary can attract more traffic
+by performing well or can target individual users by selectively
+performing, to undermine their anonymity. Typically a user who
+chooses evenly from all nodes is most resistant to an adversary
+targeting him, but that approach hampers the efficient use
+of heterogeneous nodes.
+
+%When a node (call him Steve) performs well for Alice, does Steve gain
+%reputation with the entire system, or just with Alice? If the entire
+%system, how does Alice tell everybody about her experience in a way that
+%prevents her from lying about it yet still protects her identity? If
+%Steve's behavior only affects Alice's behavior, does this allow Steve to
+%selectively perform only for Alice, and then break her anonymity later
+%when somebody (presumably Alice) routes through his node?
+
+A possible solution is a simplified approach to the tit-for-tat
+incentive scheme based on two rules: (1) each node should measure the
+service it receives from adjacent nodes, and provide service relative
+to the received service, but (2) when a node is making decisions that
+affect its own security (such as building a circuit for its own
+application connections), it should choose evenly from a sufficiently
+large set of nodes that meet some minimum service
+threshold~\cite{casc-rep}.  This approach allows us to discourage
+bad service
+without opening Alice up as much to attacks.  All of this requires
+further study.
+
+\subsection{Trust and discovery}
+\label{subsec:trust-and-discovery}
+
+The published Tor design is deliberately simplistic in how
+new nodes are authorized and how clients are informed about Tor
+nodes and their status.
+All nodes periodically upload a signed description
+of their locations, keys, and capabilities to each of several well-known {\it
+  directory servers}.  These directory servers construct a signed summary
+of all known Tor nodes (a ``directory''), and a signed statement of which
+nodes they
+believe to be operational then (a ``network status'').  Clients
+periodically download a directory to learn the latest nodes and
+keys, and more frequently download a network status to learn which nodes are
+likely to be running.  Tor nodes also operate as directory caches, to
+lighten the bandwidth on the directory servers.
+
+To prevent Sybil attacks (wherein an adversary signs up many
+purportedly independent nodes to increase her network view),
+this design
+requires the directory server operators to manually
+approve new nodes.  Unapproved nodes are included in the directory,
+but clients
+do not use them at the start or end of their circuits.  In practice,
+directory administrators perform little actual verification, and tend to
+approve any Tor node whose operator can compose a coherent email.
+This procedure
+may prevent trivial automated Sybil attacks, but will do little
+against a clever and determined attacker.
+
+There are a number of flaws in this system that need to be addressed as we
+move forward. First,
+each directory server represents an independent point of failure: any
+compromised directory server could start recommending only compromised
+nodes.
+Second, as more nodes join the network, %the more unreasonable it
+%becomes to expect clients to know about them all.
+directories
+become infeasibly large, and downloading the list of nodes becomes
+burdensome.
+Third, the validation scheme may do as much harm as it does good.  It 
+does not prevent clever attackers from mounting Sybil attacks,
+and it may deter node operators from joining the network---if
+they expect the validation process to be difficult, or they do not share
+any languages in common with the directory server operators.
+
+We could try to move the system in several directions, depending on our
+choice of threat model and requirements.  If we did not need to increase
+network capacity to support more users, we could simply
+ adopt even stricter validation requirements, and reduce the number of
+nodes in the network to a trusted minimum.  
+But, we can only do that if we can simultaneously make node capacity
+scale much more than we anticipate to be feasible soon, and if we can find
+entities willing to run such nodes, an equally daunting prospect.
+
+In order to address the first two issues, it seems wise to move to a system
+including a number of semi-trusted directory servers, no one of which can
+compromise a user on its own.  Ultimately, of course, we cannot escape the
+problem of a first introducer: since most users will run Tor in whatever
+configuration the software ships with, the Tor distribution itself will
+remain a single point of failure so long as it includes the seed
+keys for directory servers, a list of directory servers, or any other means
+to learn which nodes are on the network.  But omitting this information
+from the Tor distribution would only delegate the trust problem to each
+individual user. %, most of whom are presumably less informed about how to make
+%trust decisions than the Tor developers.
+A well publicized, widely available, authoritatively and independently
+endorsed and signed list of initial directory servers and their keys
+is a possible solution. But, setting that up properly is itself a large 
+bootstrapping task.
+
+%Network discovery, sybil, node admission, scaling. It seems that the code
+%will ship with something and that's our trust root. We could try to get
+%people to build a web of trust, but no. Where we go from here depends
+%on what threats we have in mind. Really decentralized if your threat is
+%RIAA; less so if threat is to application data or individuals or...
+
+\subsection{Measuring performance and capacity}
+\label{subsec:performance}
+
+One of the paradoxes with engineering an anonymity network is that we'd like
+to learn as much as we can about how traffic flows so we can improve the
+network, but we want to prevent others from learning how traffic flows in
+order to trace users' connections through the network.  Furthermore, many
+mechanisms that help Tor run efficiently
+require measurements about the network.
+
+Currently, nodes try to deduce their own available bandwidth (based on how
+much traffic they have been able to transfer recently) and include this
+information in the descriptors they upload to the directory. Clients
+choose servers weighted by their bandwidth, neglecting really slow
+servers and capping the influence of really fast ones.
+%
+This is, of course, eminently cheatable.  A malicious node can get a
+disproportionate amount of traffic simply by claiming to have more bandwidth
+than it does.  But better mechanisms have their problems.  If bandwidth data
+is to be measured rather than self-reported, it is usually possible for
+nodes to selectively provide better service for the measuring party, or
+sabotage the measured value of other nodes.  Complex solutions for
+mix networks have been proposed, but do not address the issues
+completely~\cite{mix-acc,casc-rep}.
+
+Even with no cheating, network measurement is complex.  It is common
+for views of a node's latency and/or bandwidth to vary wildly between
+observers.  Further, it is unclear whether total bandwidth is really
+the right measure; perhaps clients should instead be considering nodes
+based on unused bandwidth or observed throughput.
+%How to measure performance without letting people selectively deny service
+%by distinguishing pings. Heck, just how to measure performance at all. In
+%practice people have funny firewalls that don't match up to their exit
+%policies and Tor doesn't deal.
+%
+%Network investigation: Is all this bandwidth publishing thing a good idea?
+%How can we collect stats better? Note weasel's smokeping, at
+%http://seppia.noreply.org/cgi-bin/smokeping.cgi?target=Tor
+%which probably gives george and steven enough info to break tor?
+%
+And even if we can collect and use this network information effectively,
+we must ensure
+that it is not more useful to attackers than to us.  While it
+seems plausible that bandwidth data alone is not enough to reveal
+sender-recipient connections under most circumstances, it could certainly
+reveal the path taken by large traffic flows under low-usage circumstances.
+
+\subsection{Non-clique topologies}
+
+Tor's comparatively weak threat model may allow easier scaling than
+other
+designs.  High-latency mix networks need to avoid partitioning attacks, where
+network splits let an attacker distinguish users in different partitions.
+Since Tor assumes the adversary cannot cheaply observe nodes at will,
+a network split may not decrease protection much.
+Thus, one option when the scale of a Tor network
+exceeds some size is simply to split it. Nodes could be allocated into
+partitions while hampering collaborating hostile nodes from taking over
+a single partition~\cite{casc-rep}.
+Clients could switch between
+networks, even on a per-circuit basis.
+%Future analysis may uncover
+%other dangers beyond those affecting mix-nets.
+
+More conservatively, we can try to scale a single Tor network. Likely
+problems with adding more servers to a single Tor network include an
+explosion in the number of sockets needed on each server as more servers
+join, and increased coordination overhead to keep each users' view of
+the network consistent. As we grow, we will also have more instances of
+servers that can't reach each other simply due to Internet topology or
+routing problems.
+
+%include restricting the number of sockets and the amount of bandwidth
+%used by each node.  The number of sockets is determined by the network's
+%connectivity and the number of users, while bandwidth capacity is determined
+%by the total bandwidth of nodes on the network.  The simplest solution to
+%bandwidth capacity is to add more nodes, since adding a Tor node of any
+%feasible bandwidth will increase the traffic capacity of the network.  So as
+%a first step to scaling, we should focus on making the network tolerate more
+%nodes, by reducing the interconnectivity of the nodes; later we can reduce
+%overhead associated with directories, discovery, and so on.
+
+We can address these points by reducing the network's connectivity.
+Danezis~\cite{danezis:pet2003} considers
+the anonymity implications of restricting routes on mix networks and
+recommends an approach based on expander graphs (where any subgraph is likely
+to have many neighbors).  It is not immediately clear that this approach will
+extend to Tor, which has a weaker threat model but higher performance
+requirements: instead of analyzing the
+probability of an attacker's viewing whole paths, we will need to examine the
+attacker's likelihood of compromising the endpoints.
+%
+Tor may not need an expander graph per se: it
+may be enough to have a single central subnet that is highly connected, like
+an Internet backbone. %  As an
+%example, assume fifty nodes of relatively high traffic capacity.  This
+%\emph{center} forms a clique.  Assume each center node can
+%handle 200 connections to other nodes (including the other ones in the
+%center). Assume every noncenter node connects to three nodes in the
+%center and anyone out of the center that they want to.  Then the
+%network easily scales to c. 2500 nodes with commensurate increase in
+%bandwidth.
+There are many open questions: how to distribute connectivity information
+(presumably nodes will learn about the central nodes
+when they download Tor), whether central nodes
+will need to function as a `backbone', and so on. As above,
+this could reduce the amount of anonymity available from a mix-net,
+but for a low-latency network where anonymity derives largely from
+the edges, it may be feasible.
+
+%In a sense, Tor already has a non-clique topology.
+%Individuals can set up and run Tor nodes without informing the
+%directory servers. This allows groups to run a
+%local Tor network of private nodes that connects to the public Tor
+%network. This network is hidden behind the Tor network, and its
+%only visible connection to Tor is at those points where it connects.
+%As far as the public network, or anyone observing it, is concerned,
+%they are running clients.
+
+\section{The Future}
+\label{sec:conclusion}
+
+Tor is the largest and most diverse low-latency anonymity network
+available, but we are still in the beginning stages of deployment. Several
+major questions remain.
+
+First, will our volunteer-based approach to sustainability work in the
+long term? As we add more features and destabilize the network, the
+developers spend a lot of time keeping the server operators happy. Even
+though Tor is free software, the network would likely stagnate and die at
+this stage if the developers stopped actively working on it. We may get
+an unexpected boon from the fact that we're a general-purpose overlay
+network: as Tor grows more popular, other groups who need an overlay
+network on the Internet are starting to adapt Tor to their needs.
+%
+Second, Tor is only one of many components that preserve privacy online.
+For applications where it is desirable to
+keep identifying information out of application traffic, someone must build
+more and better protocol-aware proxies that are usable by ordinary people.
+%
+Third, we need to gain a reputation for social good, and learn how to
+coexist with the variety of Internet services and their established
+authentication mechanisms. We can't just keep escalating the blacklist
+standoff forever.
+%
+Fourth, the current Tor
+architecture does not scale even to handle current user demand. We must
+find designs and incentives to let some clients relay traffic too, without
+sacrificing too much anonymity.
+
+These are difficult and open questions. Yet choosing not to solve them
+means leaving most users to a less secure network or no anonymizing
+network at all.
+
+\bibliographystyle{plain} \bibliography{tor-design}
+
+\clearpage
+\appendix
+
+\begin{figure}[t]
+%\unitlength=1in
+\centering
+%\begin{picture}(6.0,2.0)
+%\put(3,1){\makebox(0,0)[c]{\epsfig{figure=graphnodes,width=6in}}}
+%\end{picture}
+\mbox{\epsfig{figure=graphnodes,width=5in}}
+\caption{Number of Tor nodes over time, through January 2005. Lowest
+line is number of exit
+nodes that allow connections to port 80. Middle line is total number of
+verified (registered) Tor nodes. The line above that represents nodes
+that are running but not yet registered.}
+\label{fig:graphnodes}
+\end{figure}
+
+\begin{figure}[t]
+\centering
+\mbox{\epsfig{figure=graphtraffic,width=5in}}
+\caption{The sum of traffic reported by each node over time, through
+January 2005. The bottom
+pair show average throughput, and the top pair represent the largest 15
+minute burst in each 4 hour period.}
+\label{fig:graphtraffic}
+\end{figure}
+
+\end{document}
+
+%Making use of nodes with little bandwidth, or high latency/packet loss.
+
+%Running Tor nodes behind NATs, behind great-firewalls-of-China, etc.
+%Restricted routes. How to propagate to everybody the topology? BGP
+%style doesn't work because we don't want just *one* path. Point to
+%Geoff's stuff.
+
diff --git a/2005/challenges/graphnodes.pdf b/2005/challenges/graphnodes.pdf
new file mode 100644
index 0000000..68e98dc
Binary files /dev/null and b/2005/challenges/graphnodes.pdf differ
diff --git a/2005/challenges/graphtraffic.pdf b/2005/challenges/graphtraffic.pdf
new file mode 100644
index 0000000..e37382f
Binary files /dev/null and b/2005/challenges/graphtraffic.pdf differ
diff --git a/2005/challenges/llncs.cls b/2005/challenges/llncs.cls
new file mode 100644
index 0000000..697dd77
--- /dev/null
+++ b/2005/challenges/llncs.cls
@@ -0,0 +1,1016 @@
+% LLNCS DOCUMENT CLASS -- version 2.8
+% for LaTeX2e
+%
+\NeedsTeXFormat{LaTeX2e}[1995/12/01]
+\ProvidesClass{llncs}[2000/05/16 v2.8
+^^JLaTeX document class for Lecture Notes in Computer Science]
+% Options
+\let\if at envcntreset\iffalse
+\DeclareOption{envcountreset}{\let\if at envcntreset\iftrue}
+\DeclareOption{citeauthoryear}{\let\citeauthoryear=Y}
+\DeclareOption{oribibl}{\let\oribibl=Y}
+\let\if at custvec\iftrue
+\DeclareOption{orivec}{\let\if at custvec\iffalse}
+\let\if at envcntsame\iffalse
+\DeclareOption{envcountsame}{\let\if at envcntsame\iftrue}
+\let\if at envcntsect\iffalse
+\DeclareOption{envcountsect}{\let\if at envcntsect\iftrue}
+\let\if at runhead\iffalse
+\DeclareOption{runningheads}{\let\if at runhead\iftrue}
+
+\let\if at openbib\iffalse
+\DeclareOption{openbib}{\let\if at openbib\iftrue}
+
+\DeclareOption*{\PassOptionsToClass{\CurrentOption}{article}}
+
+\ProcessOptions
+
+\LoadClass[twoside]{article}
+\RequirePackage{multicol} % needed for the list of participants, index
+
+\setlength{\textwidth}{12.2cm}
+\setlength{\textheight}{19.3cm}
+
+% Ragged bottom for the actual page
+\def\thisbottomragged{\def\@textbottom{\vskip\z@ plus.0001fil
+\global\let\@textbottom\relax}}
+
+\renewcommand\small{%
+   \@setfontsize\small\@ixpt{11}%
+   \abovedisplayskip 8.5\p@ \@plus3\p@ \@minus4\p@
+   \abovedisplayshortskip \z@ \@plus2\p@
+   \belowdisplayshortskip 4\p@ \@plus2\p@ \@minus2\p@
+   \def\@listi{\leftmargin\leftmargini
+               \parsep 0\p@ \@plus1\p@ \@minus\p@
+               \topsep 8\p@ \@plus2\p@ \@minus4\p@
+               \itemsep0\p@}%
+   \belowdisplayskip \abovedisplayskip
+}
+
+\frenchspacing
+\widowpenalty=10000
+\clubpenalty=10000
+
+\setlength\oddsidemargin   {63\p@}
+\setlength\evensidemargin  {63\p@}
+\setlength\marginparwidth  {90\p@}
+
+\setlength\headsep   {16\p@}
+
+\setlength\footnotesep{7.7\p@}
+\setlength\textfloatsep{8mm\@plus 2\p@ \@minus 4\p@}
+\setlength\intextsep   {8mm\@plus 2\p@ \@minus 2\p@}
+
+\setcounter{secnumdepth}{2}
+
+\newcounter {chapter}
+\renewcommand\thechapter      {\@arabic\c at chapter}
+
+\newif\if at mainmatter \@mainmattertrue
+\newcommand\frontmatter{\cleardoublepage
+            \@mainmatterfalse\pagenumbering{Roman}}
+\newcommand\mainmatter{\cleardoublepage
+       \@mainmattertrue\pagenumbering{arabic}}
+\newcommand\backmatter{\if at openright\cleardoublepage\else\clearpage\fi
+      \@mainmatterfalse}
+
+\renewcommand\part{\cleardoublepage
+                 \thispagestyle{empty}%
+                 \if at twocolumn
+                     \onecolumn
+                     \@tempswatrue
+                   \else
+                     \@tempswafalse
+                 \fi
+                 \null\vfil
+                 \secdef\@part\@spart}
+
+\def\@part[#1]#2{%
+    \ifnum \c at secnumdepth >-2\relax
+      \refstepcounter{part}%
+      \addcontentsline{toc}{part}{\thepart\hspace{1em}#1}%
+    \else
+      \addcontentsline{toc}{part}{#1}%
+    \fi
+    \markboth{}{}%
+    {\centering
+     \interlinepenalty \@M
+     \normalfont
+     \ifnum \c at secnumdepth >-2\relax
+       \huge\bfseries \partname~\thepart
+       \par
+       \vskip 20\p@
+     \fi
+     \Huge \bfseries #2\par}%
+    \@endpart}
+\def\@spart#1{%
+    {\centering
+     \interlinepenalty \@M
+     \normalfont
+     \Huge \bfseries #1\par}%
+    \@endpart}
+\def\@endpart{\vfil\newpage
+              \if at twoside
+                \null
+                \thispagestyle{empty}%
+                \newpage
+              \fi
+              \if at tempswa
+                \twocolumn
+              \fi}
+
+\newcommand\chapter{\clearpage
+                    \thispagestyle{empty}%
+                    \global\@topnum\z@
+                    \@afterindentfalse
+                    \secdef\@chapter\@schapter}
+\def\@chapter[#1]#2{\ifnum \c at secnumdepth >\m at ne
+                       \if at mainmatter
+                         \refstepcounter{chapter}%
+                         \typeout{\@chapapp\space\thechapter.}%
+                         \addcontentsline{toc}{chapter}%
+                                  {\protect\numberline{\thechapter}#1}%
+                       \else
+                         \addcontentsline{toc}{chapter}{#1}%
+                       \fi
+                    \else
+                      \addcontentsline{toc}{chapter}{#1}%
+                    \fi
+                    \chaptermark{#1}%
+                    \addtocontents{lof}{\protect\addvspace{10\p@}}%
+                    \addtocontents{lot}{\protect\addvspace{10\p@}}%
+                    \if at twocolumn
+                      \@topnewpage[\@makechapterhead{#2}]%
+                    \else
+                      \@makechapterhead{#2}%
+                      \@afterheading
+                    \fi}
+\def\@makechapterhead#1{%
+% \vspace*{50\p@}%
+  {\centering
+    \ifnum \c at secnumdepth >\m at ne
+      \if at mainmatter
+        \large\bfseries \@chapapp{} \thechapter
+        \par\nobreak
+        \vskip 20\p@
+      \fi
+    \fi
+    \interlinepenalty\@M
+    \Large \bfseries #1\par\nobreak
+    \vskip 40\p@
+  }}
+\def\@schapter#1{\if at twocolumn
+                   \@topnewpage[\@makeschapterhead{#1}]%
+                 \else
+                   \@makeschapterhead{#1}%
+                   \@afterheading
+                 \fi}
+\def\@makeschapterhead#1{%
+% \vspace*{50\p@}%
+  {\centering
+    \normalfont
+    \interlinepenalty\@M
+    \Large \bfseries  #1\par\nobreak
+    \vskip 40\p@
+  }}
+
+\renewcommand\section{\@startsection{section}{1}{\z@}%
+                       {-18\p@ \@plus -4\p@ \@minus -4\p@}%
+                       {12\p@ \@plus 4\p@ \@minus 4\p@}%
+                       {\normalfont\large\bfseries\boldmath
+                        \rightskip=\z@ \@plus 8em\pretolerance=10000 }}
+\renewcommand\subsection{\@startsection{subsection}{2}{\z@}%
+                       {-18\p@ \@plus -4\p@ \@minus -4\p@}%
+                       {8\p@ \@plus 4\p@ \@minus 4\p@}%
+                       {\normalfont\normalsize\bfseries\boldmath
+                        \rightskip=\z@ \@plus 8em\pretolerance=10000 }}
+\renewcommand\subsubsection{\@startsection{subsubsection}{3}{\z@}%
+                       {-18\p@ \@plus -4\p@ \@minus -4\p@}%
+                       {-0.5em \@plus -0.22em \@minus -0.1em}%
+                       {\normalfont\normalsize\bfseries\boldmath}}
+\renewcommand\paragraph{\@startsection{paragraph}{4}{\z@}%
+                       {-12\p@ \@plus -4\p@ \@minus -4\p@}%
+                       {-0.5em \@plus -0.22em \@minus -0.1em}%
+                       {\normalfont\normalsize\itshape}}
+\renewcommand\subparagraph[1]{\typeout{LLNCS warning: You should not use
+                  \string\subparagraph\space with this class}\vskip0.5cm
+You should not use \verb|\subparagraph| with this class.\vskip0.5cm}
+
+\DeclareMathSymbol{\Gamma}{\mathalpha}{letters}{"00}
+\DeclareMathSymbol{\Delta}{\mathalpha}{letters}{"01}
+\DeclareMathSymbol{\Theta}{\mathalpha}{letters}{"02}
+\DeclareMathSymbol{\Lambda}{\mathalpha}{letters}{"03}
+\DeclareMathSymbol{\Xi}{\mathalpha}{letters}{"04}
+\DeclareMathSymbol{\Pi}{\mathalpha}{letters}{"05}
+\DeclareMathSymbol{\Sigma}{\mathalpha}{letters}{"06}
+\DeclareMathSymbol{\Upsilon}{\mathalpha}{letters}{"07}
+\DeclareMathSymbol{\Phi}{\mathalpha}{letters}{"08}
+\DeclareMathSymbol{\Psi}{\mathalpha}{letters}{"09}
+\DeclareMathSymbol{\Omega}{\mathalpha}{letters}{"0A}
+
+\let\footnotesize\small
+
+\if at custvec
+\def\vec#1{\mathchoice{\mbox{\boldmath$\displaystyle#1$}}
+{\mbox{\boldmath$\textstyle#1$}}
+{\mbox{\boldmath$\scriptstyle#1$}}
+{\mbox{\boldmath$\scriptscriptstyle#1$}}}
+\fi
+
+\def\squareforqed{\hbox{\rlap{$\sqcap$}$\sqcup$}}
+\def\qed{\ifmmode\squareforqed\else{\unskip\nobreak\hfil
+\penalty50\hskip1em\null\nobreak\hfil\squareforqed
+\parfillskip=0pt\finalhyphendemerits=0\endgraf}\fi}
+
+\def\getsto{\mathrel{\mathchoice {\vcenter{\offinterlineskip
+\halign{\hfil
+$\displaystyle##$\hfil\cr\gets\cr\to\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr\gets
+\cr\to\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr\gets
+\cr\to\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr
+\gets\cr\to\cr}}}}}
+\def\lid{\mathrel{\mathchoice {\vcenter{\offinterlineskip\halign{\hfil
+$\displaystyle##$\hfil\cr<\cr\noalign{\vskip1.2pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr<\cr
+\noalign{\vskip1.2pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr<\cr
+\noalign{\vskip1pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr
+<\cr
+\noalign{\vskip0.9pt}=\cr}}}}}
+\def\gid{\mathrel{\mathchoice {\vcenter{\offinterlineskip\halign{\hfil
+$\displaystyle##$\hfil\cr>\cr\noalign{\vskip1.2pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr>\cr
+\noalign{\vskip1.2pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr>\cr
+\noalign{\vskip1pt}=\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr
+>\cr
+\noalign{\vskip0.9pt}=\cr}}}}}
+\def\grole{\mathrel{\mathchoice {\vcenter{\offinterlineskip
+\halign{\hfil
+$\displaystyle##$\hfil\cr>\cr\noalign{\vskip-1pt}<\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\textstyle##$\hfil\cr
+>\cr\noalign{\vskip-1pt}<\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptstyle##$\hfil\cr
+>\cr\noalign{\vskip-0.8pt}<\cr}}}
+{\vcenter{\offinterlineskip\halign{\hfil$\scriptscriptstyle##$\hfil\cr
+>\cr\noalign{\vskip-0.3pt}<\cr}}}}}
+\def\bbbr{{\rm I\!R}} %reelle Zahlen
+\def\bbbm{{\rm I\!M}}
+\def\bbbn{{\rm I\!N}} %natuerliche Zahlen
+\def\bbbf{{\rm I\!F}}
+\def\bbbh{{\rm I\!H}}
+\def\bbbk{{\rm I\!K}}
+\def\bbbp{{\rm I\!P}}
+\def\bbbone{{\mathchoice {\rm 1\mskip-4mu l} {\rm 1\mskip-4mu l}
+{\rm 1\mskip-4.5mu l} {\rm 1\mskip-5mu l}}}
+\def\bbbc{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm C$}\hbox{\hbox
+to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\textstyle\rm C$}\hbox{\hbox
+to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptstyle\rm C$}\hbox{\hbox
+to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptscriptstyle\rm C$}\hbox{\hbox
+to0pt{\kern0.4\wd0\vrule height0.9\ht0\hss}\box0}}}}
+\def\bbbq{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm
+Q$}\hbox{\raise
+0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.8\ht0\hss}\box0}}
+{\setbox0=\hbox{$\textstyle\rm Q$}\hbox{\raise
+0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.8\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptstyle\rm Q$}\hbox{\raise
+0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.7\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptscriptstyle\rm Q$}\hbox{\raise
+0.15\ht0\hbox to0pt{\kern0.4\wd0\vrule height0.7\ht0\hss}\box0}}}}
+\def\bbbt{{\mathchoice {\setbox0=\hbox{$\displaystyle\rm
+T$}\hbox{\hbox to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\textstyle\rm T$}\hbox{\hbox
+to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptstyle\rm T$}\hbox{\hbox
+to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptscriptstyle\rm T$}\hbox{\hbox
+to0pt{\kern0.3\wd0\vrule height0.9\ht0\hss}\box0}}}}
+\def\bbbs{{\mathchoice
+{\setbox0=\hbox{$\displaystyle     \rm S$}\hbox{\raise0.5\ht0\hbox
+to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\hbox
+to0pt{\kern0.55\wd0\vrule height0.5\ht0\hss}\box0}}
+{\setbox0=\hbox{$\textstyle        \rm S$}\hbox{\raise0.5\ht0\hbox
+to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\hbox
+to0pt{\kern0.55\wd0\vrule height0.5\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptstyle      \rm S$}\hbox{\raise0.5\ht0\hbox
+to0pt{\kern0.35\wd0\vrule height0.45\ht0\hss}\raise0.05\ht0\hbox
+to0pt{\kern0.5\wd0\vrule height0.45\ht0\hss}\box0}}
+{\setbox0=\hbox{$\scriptscriptstyle\rm S$}\hbox{\raise0.5\ht0\hbox
+to0pt{\kern0.4\wd0\vrule height0.45\ht0\hss}\raise0.05\ht0\hbox
+to0pt{\kern0.55\wd0\vrule height0.45\ht0\hss}\box0}}}}
+\def\bbbz{{\mathchoice {\hbox{$\mathsf\textstyle Z\kern-0.4em Z$}}
+{\hbox{$\mathsf\textstyle Z\kern-0.4em Z$}}
+{\hbox{$\mathsf\scriptstyle Z\kern-0.3em Z$}}
+{\hbox{$\mathsf\scriptscriptstyle Z\kern-0.2em Z$}}}}
+
+\let\ts\,
+
+\setlength\leftmargini  {17\p@}
+\setlength\leftmargin    {\leftmargini}
+\setlength\leftmarginii  {\leftmargini}
+\setlength\leftmarginiii {\leftmargini}
+\setlength\leftmarginiv  {\leftmargini}
+\setlength  \labelsep  {.5em}
+\setlength  \labelwidth{\leftmargini}
+\addtolength\labelwidth{-\labelsep}
+
+\def\@listI{\leftmargin\leftmargini
+            \parsep 0\p@ \@plus1\p@ \@minus\p@
+            \topsep 8\p@ \@plus2\p@ \@minus4\p@
+            \itemsep0\p@}
+\let\@listi\@listI
+\@listi
+\def\@listii {\leftmargin\leftmarginii
+              \labelwidth\leftmarginii
+              \advance\labelwidth-\labelsep
+              \topsep    0\p@ \@plus2\p@ \@minus\p@}
+\def\@listiii{\leftmargin\leftmarginiii
+              \labelwidth\leftmarginiii
+              \advance\labelwidth-\labelsep
+              \topsep    0\p@ \@plus\p@\@minus\p@
+              \parsep    \z@
+              \partopsep \p@ \@plus\z@ \@minus\p@}
+
+\renewcommand\labelitemi{\normalfont\bfseries --}
+\renewcommand\labelitemii{$\m at th\bullet$}
+
+\setlength\arraycolsep{1.4\p@}
+\setlength\tabcolsep{1.4\p@}
+
+\def\tableofcontents{\chapter*{\contentsname\@mkboth{{\contentsname}}%
+                                                    {{\contentsname}}}
+ \def\authcount##1{\setcounter{auco}{##1}\setcounter{@auth}{1}}
+ \def\lastand{\ifnum\value{auco}=2\relax
+                 \unskip{} \andname\
+              \else
+                 \unskip \lastandname\
+              \fi}%
+ \def\and{\stepcounter{@auth}\relax
+          \ifnum\value{@auth}=\value{auco}%
+             \lastand
+          \else
+             \unskip,
+          \fi}%
+ \@starttoc{toc}\if at restonecol\twocolumn\fi}
+
+\def\l at part#1#2{\addpenalty{\@secpenalty}%
+   \addvspace{2em plus\p@}%  % space above part line
+   \begingroup
+     \parindent \z@
+     \rightskip \z@ plus 5em
+     \hrule\vskip5pt
+     \large               % same size as for a contribution heading
+     \bfseries\boldmath   % set line in boldface
+     \leavevmode          % TeX command to enter horizontal mode.
+     #1\par
+     \vskip5pt
+     \hrule
+     \vskip1pt
+     \nobreak             % Never break after part entry
+   \endgroup}
+
+\def\@dotsep{2}
+
+\def\hyperhrefextend{\ifx\hyper at anchor\@undefined\else
+{chapter.\thechapter}\fi}
+
+\def\addnumcontentsmark#1#2#3{%
+\addtocontents{#1}{\protect\contentsline{#2}{\protect\numberline
+                     {\thechapter}#3}{\thepage}\hyperhrefextend}}
+\def\addcontentsmark#1#2#3{%
+\addtocontents{#1}{\protect\contentsline{#2}{#3}{\thepage}\hyperhrefextend}}
+\def\addcontentsmarkwop#1#2#3{%
+\addtocontents{#1}{\protect\contentsline{#2}{#3}{0}\hyperhrefextend}}
+
+\def\@adcmk[#1]{\ifcase #1 \or
+\def\@gtempa{\addnumcontentsmark}%
+  \or    \def\@gtempa{\addcontentsmark}%
+  \or    \def\@gtempa{\addcontentsmarkwop}%
+  \fi\@gtempa{toc}{chapter}}
+\def\addtocmark{\@ifnextchar[{\@adcmk}{\@adcmk[3]}}
+
+\def\l at chapter#1#2{\addpenalty{-\@highpenalty}
+ \vskip 1.0em plus 1pt \@tempdima 1.5em \begingroup
+ \parindent \z@ \rightskip \@pnumwidth
+ \parfillskip -\@pnumwidth
+ \leavevmode \advance\leftskip\@tempdima \hskip -\leftskip
+ {\large\bfseries\boldmath#1}\ifx0#2\hfil\null
+ \else
+      \nobreak
+      \leaders\hbox{$\m at th \mkern \@dotsep mu.\mkern
+      \@dotsep mu$}\hfill
+      \nobreak\hbox to\@pnumwidth{\hss #2}%
+ \fi\par
+ \penalty\@highpenalty \endgroup}
+
+\def\l at title#1#2{\addpenalty{-\@highpenalty}
+ \addvspace{8pt plus 1pt}
+ \@tempdima \z@
+ \begingroup
+ \parindent \z@ \rightskip \@tocrmarg
+ \parfillskip -\@tocrmarg
+ \leavevmode \advance\leftskip\@tempdima \hskip -\leftskip
+ #1\nobreak
+ \leaders\hbox{$\m at th \mkern \@dotsep mu.\mkern
+ \@dotsep mu$}\hfill
+ \nobreak\hbox to\@pnumwidth{\hss #2}\par
+ \penalty\@highpenalty \endgroup}
+
+\setcounter{tocdepth}{0}
+\newdimen\tocchpnum
+\newdimen\tocsecnum
+\newdimen\tocsectotal
+\newdimen\tocsubsecnum
+\newdimen\tocsubsectotal
+\newdimen\tocsubsubsecnum
+\newdimen\tocsubsubsectotal
+\newdimen\tocparanum
+\newdimen\tocparatotal
+\newdimen\tocsubparanum
+\tocchpnum=\z@            % no chapter numbers
+\tocsecnum=15\p@          % section 88. plus 2.222pt
+\tocsubsecnum=23\p@       % subsection 88.8 plus 2.222pt
+\tocsubsubsecnum=27\p@    % subsubsection 88.8.8 plus 1.444pt
+\tocparanum=35\p@         % paragraph 88.8.8.8 plus 1.666pt
+\tocsubparanum=43\p@      % subparagraph 88.8.8.8.8 plus 1.888pt
+\def\calctocindent{%
+\tocsectotal=\tocchpnum
+\advance\tocsectotal by\tocsecnum
+\tocsubsectotal=\tocsectotal
+\advance\tocsubsectotal by\tocsubsecnum
+\tocsubsubsectotal=\tocsubsectotal
+\advance\tocsubsubsectotal by\tocsubsubsecnum
+\tocparatotal=\tocsubsubsectotal
+\advance\tocparatotal by\tocparanum}
+\calctocindent
+
+\def\l at section{\@dottedtocline{1}{\tocchpnum}{\tocsecnum}}
+\def\l at subsection{\@dottedtocline{2}{\tocsectotal}{\tocsubsecnum}}
+\def\l at subsubsection{\@dottedtocline{3}{\tocsubsectotal}{\tocsubsubsecnum}}
+\def\l at paragraph{\@dottedtocline{4}{\tocsubsubsectotal}{\tocparanum}}
+\def\l at subparagraph{\@dottedtocline{5}{\tocparatotal}{\tocsubparanum}}
+
+\def\listoffigures{\@restonecolfalse\if at twocolumn\@restonecoltrue\onecolumn
+ \fi\section*{\listfigurename\@mkboth{{\listfigurename}}{{\listfigurename}}}
+ \@starttoc{lof}\if at restonecol\twocolumn\fi}
+\def\l at figure{\@dottedtocline{1}{0em}{1.5em}}
+
+\def\listoftables{\@restonecolfalse\if at twocolumn\@restonecoltrue\onecolumn
+ \fi\section*{\listtablename\@mkboth{{\listtablename}}{{\listtablename}}}
+ \@starttoc{lot}\if at restonecol\twocolumn\fi}
+\let\l at table\l at figure
+
+\renewcommand\listoffigures{%
+    \section*{\listfigurename
+      \@mkboth{\listfigurename}{\listfigurename}}%
+    \@starttoc{lof}%
+    }
+
+\renewcommand\listoftables{%
+    \section*{\listtablename
+      \@mkboth{\listtablename}{\listtablename}}%
+    \@starttoc{lot}%
+    }
+
+\ifx\oribibl\undefined
+\ifx\citeauthoryear\undefined
+\renewenvironment{thebibliography}[1]
+     {\section*{\refname}
+      \def\@biblabel##1{##1.}
+      \small
+      \list{\@biblabel{\@arabic\c at enumiv}}%
+           {\settowidth\labelwidth{\@biblabel{#1}}%
+            \leftmargin\labelwidth
+            \advance\leftmargin\labelsep
+            \if at openbib
+              \advance\leftmargin\bibindent
+              \itemindent -\bibindent
+              \listparindent \itemindent
+              \parsep \z@
+            \fi
+            \usecounter{enumiv}%
+            \let\p at enumiv\@empty
+            \renewcommand\theenumiv{\@arabic\c at enumiv}}%
+      \if at openbib
+        \renewcommand\newblock{\par}%
+      \else
+        \renewcommand\newblock{\hskip .11em \@plus.33em \@minus.07em}%
+      \fi
+      \sloppy\clubpenalty4000\widowpenalty4000%
+      \sfcode`\.=\@m}
+     {\def\@noitemerr
+       {\@latex at warning{Empty `thebibliography' environment}}%
+      \endlist}
+\def\@lbibitem[#1]#2{\item[{[#1]}\hfill]\if at filesw
+     {\let\protect\noexpand\immediate
+     \write\@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces}
+\newcount\@tempcntc
+\def\@citex[#1]#2{\if at filesw\immediate\write\@auxout{\string\citation{#2}}\fi
+  \@tempcnta\z@\@tempcntb\m at ne\def\@citea{}\@cite{\@for\@citeb:=#2\do
+    {\@ifundefined
+       {b@\@citeb}{\@citeo\@tempcntb\m at ne\@citea\def\@citea{,}{\bfseries
+        ?}\@warning
+       {Citation `\@citeb' on page \thepage \space undefined}}%
+    {\setbox\z@\hbox{\global\@tempcntc0\csname b@\@citeb\endcsname\relax}%
+     \ifnum\@tempcntc=\z@ \@citeo\@tempcntb\m at ne
+       \@citea\def\@citea{,}\hbox{\csname b@\@citeb\endcsname}%
+     \else
+      \advance\@tempcntb\@ne
+      \ifnum\@tempcntb=\@tempcntc
+      \else\advance\@tempcntb\m at ne\@citeo
+      \@tempcnta\@tempcntc\@tempcntb\@tempcntc\fi\fi}}\@citeo}{#1}}
+\def\@citeo{\ifnum\@tempcnta>\@tempcntb\else
+               \@citea\def\@citea{,\,\hskip\z at skip}%
+               \ifnum\@tempcnta=\@tempcntb\the\@tempcnta\else
+               {\advance\@tempcnta\@ne\ifnum\@tempcnta=\@tempcntb \else
+                \def\@citea{--}\fi
+      \advance\@tempcnta\m at ne\the\@tempcnta\@citea\the\@tempcntb}\fi\fi}
+\else
+\renewenvironment{thebibliography}[1]
+     {\section*{\refname}
+      \small
+      \list{}%
+           {\settowidth\labelwidth{}%
+            \leftmargin\parindent
+            \itemindent=-\parindent
+            \labelsep=\z@
+            \if at openbib
+              \advance\leftmargin\bibindent
+              \itemindent -\bibindent
+              \listparindent \itemindent
+              \parsep \z@
+            \fi
+            \usecounter{enumiv}%
+            \let\p at enumiv\@empty
+            \renewcommand\theenumiv{}}%
+      \if at openbib
+        \renewcommand\newblock{\par}%
+      \else
+        \renewcommand\newblock{\hskip .11em \@plus.33em \@minus.07em}%
+      \fi
+      \sloppy\clubpenalty4000\widowpenalty4000%
+      \sfcode`\.=\@m}
+     {\def\@noitemerr
+       {\@latex at warning{Empty `thebibliography' environment}}%
+      \endlist}
+      \def\@cite#1{#1}%
+      \def\@lbibitem[#1]#2{\item[]\if at filesw
+        {\def\protect##1{\string ##1\space}\immediate
+      \write\@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces}
+   \fi
+\else
+\@cons\@openbib at code{\noexpand\small}
+\fi
+
+\def\idxquad{\hskip 10\p@}% space that divides entry from number
+
+\def\@idxitem{\par\hangindent 10\p@}
+
+\def\subitem{\par\setbox0=\hbox{--\enspace}% second order
+                \noindent\hangindent\wd0\box0}% index entry
+
+\def\subsubitem{\par\setbox0=\hbox{--\,--\enspace}% third
+                \noindent\hangindent\wd0\box0}% order index entry
+
+\def\indexspace{\par \vskip 10\p@ plus5\p@ minus3\p@\relax}
+
+\renewenvironment{theindex}
+               {\@mkboth{\indexname}{\indexname}%
+                \thispagestyle{empty}\parindent\z@
+                \parskip\z@ \@plus .3\p@\relax
+                \let\item\par
+                \def\,{\relax\ifmmode\mskip\thinmuskip
+                             \else\hskip0.2em\ignorespaces\fi}%
+                \normalfont\small
+                \begin{multicols}{2}[\@makeschapterhead{\indexname}]%
+                }
+                {\end{multicols}}
+
+\renewcommand\footnoterule{%
+  \kern-3\p@
+  \hrule\@width 2truecm
+  \kern2.6\p@}
+  \newdimen\fnindent
+  \fnindent1em
+\long\def\@makefntext#1{%
+    \parindent \fnindent%
+    \leftskip \fnindent%
+    \noindent
+    \llap{\hb at xt@1em{\hss\@makefnmark\ }}\ignorespaces#1}
+
+\long\def\@makecaption#1#2{%
+  \vskip\abovecaptionskip
+  \sbox\@tempboxa{{\bfseries #1.} #2}%
+  \ifdim \wd\@tempboxa >\hsize
+    {\bfseries #1.} #2\par
+  \else
+    \global \@minipagefalse
+    \hb at xt@\hsize{\hfil\box\@tempboxa\hfil}%
+  \fi
+  \vskip\belowcaptionskip}
+
+\def\fps at figure{htbp}
+\def\fnum at figure{\figurename\thinspace\thefigure}
+\def \@floatboxreset {%
+        \reset at font
+        \small
+        \@setnobreak
+        \@setminipage
+}
+\def\fps at table{htbp}
+\def\fnum at table{\tablename~\thetable}
+\renewenvironment{table}
+               {\setlength\abovecaptionskip{0\p@}%
+                \setlength\belowcaptionskip{10\p@}%
+                \@float{table}}
+               {\end at float}
+\renewenvironment{table*}
+               {\setlength\abovecaptionskip{0\p@}%
+                \setlength\belowcaptionskip{10\p@}%
+                \@dblfloat{table}}
+               {\end at dblfloat}
+
+\long\def\@caption#1[#2]#3{\par\addcontentsline{\csname
+  ext@#1\endcsname}{#1}{\protect\numberline{\csname
+  the#1\endcsname}{\ignorespaces #2}}\begingroup
+    \@parboxrestore
+    \@makecaption{\csname fnum@#1\endcsname}{\ignorespaces #3}\par
+  \endgroup}
+
+% LaTeX does not provide a command to enter the authors institute
+% addresses. The \institute command is defined here.
+
+\newcounter{@inst}
+\newcounter{@auth}
+\newcounter{auco}
+\def\andname{and}
+\def\lastandname{\unskip, and}
+\newdimen\instindent
+\newbox\authrun
+\newtoks\authorrunning
+\newtoks\tocauthor
+\newbox\titrun
+\newtoks\titlerunning
+\newtoks\toctitle
+
+\def\clearheadinfo{\gdef\@author{No Author Given}%
+                   \gdef\@title{No Title Given}%
+                   \gdef\@subtitle{}%
+                   \gdef\@institute{No Institute Given}%
+                   \gdef\@thanks{}%
+                   \global\titlerunning={}\global\authorrunning={}%
+                   \global\toctitle={}\global\tocauthor={}}
+
+\def\institute#1{\gdef\@institute{#1}}
+
+\def\institutename{\par
+ \begingroup
+ \parskip=\z@
+ \parindent=\z@
+ \setcounter{@inst}{1}%
+ \def\and{\par\stepcounter{@inst}%
+ \noindent$^{\the at inst}$\enspace\ignorespaces}%
+ \setbox0=\vbox{\def\thanks##1{}\@institute}%
+ \ifnum\c@@inst=1\relax
+ \else
+   \setcounter{footnote}{\c@@inst}%
+   \setcounter{@inst}{1}%
+   \noindent$^{\the at inst}$\enspace
+ \fi
+ \ignorespaces
+ \@institute\par
+ \endgroup}
+
+\def\@fnsymbol#1{\ensuremath{\ifcase#1\or\star\or{\star\star}\or
+   {\star\star\star}\or \dagger\or \ddagger\or
+   \mathchar "278\or \mathchar "27B\or \|\or **\or \dagger\dagger
+   \or \ddagger\ddagger \else\@ctrerr\fi}}
+
+\def\inst#1{\unskip$^{#1}$}
+\def\fnmsep{\unskip$^,$}
+\def\email#1{{\tt#1}}
+\AtBeginDocument{\@ifundefined{url}{\def\url#1{#1}}{}}
+\def\homedir{\~{ }}
+
+\def\subtitle#1{\gdef\@subtitle{#1}}
+\clearheadinfo
+
+\renewcommand\maketitle{\newpage
+  \refstepcounter{chapter}%
+  \stepcounter{section}%
+  \setcounter{section}{0}%
+  \setcounter{subsection}{0}%
+  \setcounter{figure}{0}
+  \setcounter{table}{0}
+  \setcounter{equation}{0}
+  \setcounter{footnote}{0}%
+  \begingroup
+    \parindent=\z@
+    \renewcommand\thefootnote{\@fnsymbol\c at footnote}%
+    \if at twocolumn
+      \ifnum \col at number=\@ne
+        \@maketitle
+      \else
+        \twocolumn[\@maketitle]%
+      \fi
+    \else
+      \newpage
+      \global\@topnum\z@   % Prevents figures from going at top of page.
+      \@maketitle
+    \fi
+    \thispagestyle{empty}\@thanks
+%
+    \def\\{\unskip\ \ignorespaces}\def\inst##1{\unskip{}}%
+    \def\thanks##1{\unskip{}}\def\fnmsep{\unskip}%
+    \instindent=\hsize
+    \advance\instindent by-\headlineindent
+    \if!\the\toctitle!\addcontentsline{toc}{title}{\@title}\else
+       \addcontentsline{toc}{title}{\the\toctitle}\fi
+    \if at runhead
+       \if!\the\titlerunning!\else
+         \edef\@title{\the\titlerunning}%
+       \fi
+       \global\setbox\titrun=\hbox{\small\rm\unboldmath\ignorespaces\@title}%
+       \ifdim\wd\titrun>\instindent
+          \typeout{Title too long for running head. Please supply}%
+          \typeout{a shorter form with \string\titlerunning\space prior to
+                   \string\maketitle}%
+          \global\setbox\titrun=\hbox{\small\rm
+          Title Suppressed Due to Excessive Length}%
+       \fi
+       \xdef\@title{\copy\titrun}%
+    \fi
+%
+    \if!\the\tocauthor!\relax
+      {\def\and{\noexpand\protect\noexpand\and}%
+      \protected at xdef\toc at uthor{\@author}}%
+    \else
+      \def\\{\noexpand\protect\noexpand\newline}%
+      \protected at xdef\scratch{\the\tocauthor}%
+      \protected at xdef\toc at uthor{\scratch}%
+    \fi
+    \addtocontents{toc}{{\protect\raggedright\protect\leftskip15\p@
+    \protect\rightskip\@tocrmarg
+    \protect\itshape\toc at uthor\protect\endgraf}}%
+    \if at runhead
+       \if!\the\authorrunning!
+         \value{@inst}=\value{@auth}%
+         \setcounter{@auth}{1}%
+       \else
+         \edef\@author{\the\authorrunning}%
+       \fi
+       \global\setbox\authrun=\hbox{\small\unboldmath\@author\unskip}%
+       \ifdim\wd\authrun>\instindent
+          \typeout{Names of authors too long for running head. Please supply}%
+          \typeout{a shorter form with \string\authorrunning\space prior to
+                   \string\maketitle}%
+          \global\setbox\authrun=\hbox{\small\rm
+          Authors Suppressed Due to Excessive Length}%
+       \fi
+       \xdef\@author{\copy\authrun}%
+       \markboth{\@author}{\@title}%
+     \fi
+  \endgroup
+  \setcounter{footnote}{0}%
+  \clearheadinfo}
+%
+\def\@maketitle{\newpage
+ \markboth{}{}%
+ \def\lastand{\ifnum\value{@inst}=2\relax
+                 \unskip{} \andname\
+              \else
+                 \unskip \lastandname\
+              \fi}%
+ \def\and{\stepcounter{@auth}\relax
+          \ifnum\value{@auth}=\value{@inst}%
+             \lastand
+          \else
+             \unskip,
+          \fi}%
+ \begin{center}%
+ {\Large \bfseries\boldmath
+  \pretolerance=10000
+  \@title \par}\vskip .8cm
+\if!\@subtitle!\else {\large \bfseries\boldmath
+  \vskip -.65cm
+  \pretolerance=10000
+  \@subtitle \par}\vskip .8cm\fi
+ \setbox0=\vbox{\setcounter{@auth}{1}\def\and{\stepcounter{@auth}}%
+ \def\thanks##1{}\@author}%
+ \global\value{@inst}=\value{@auth}%
+ \global\value{auco}=\value{@auth}%
+ \setcounter{@auth}{1}%
+{\lineskip .5em
+\noindent\ignorespaces
+\@author\vskip.35cm}
+ {\small\institutename}
+ \end{center}%
+ }
+
+% definition of the "\spnewtheorem" command.
+%
+% Usage:
+%
+%     \spnewtheorem{env_nam}{caption}[within]{cap_font}{body_font}
+% or  \spnewtheorem{env_nam}[numbered_like]{caption}{cap_font}{body_font}
+% or  \spnewtheorem*{env_nam}{caption}{cap_font}{body_font}
+%
+% New is "cap_font" and "body_font". It stands for
+% fontdefinition of the caption and the text itself.
+%
+% "\spnewtheorem*" gives a theorem without number.
+%
+% A defined spnewthoerem environment is used as described
+% by Lamport.
+%
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+\def\@thmcountersep{}
+\def\@thmcounterend{.}
+
+\def\spnewtheorem{\@ifstar{\@sthm}{\@Sthm}}
+
+% definition of \spnewtheorem with number
+
+\def\@spnthm#1#2{%
+  \@ifnextchar[{\@spxnthm{#1}{#2}}{\@spynthm{#1}{#2}}}
+\def\@Sthm#1{\@ifnextchar[{\@spothm{#1}}{\@spnthm{#1}}}
+
+\def\@spxnthm#1#2[#3]#4#5{\expandafter\@ifdefinable\csname #1\endcsname
+   {\@definecounter{#1}\@addtoreset{#1}{#3}%
+   \expandafter\xdef\csname the#1\endcsname{\expandafter\noexpand
+     \csname the#3\endcsname \noexpand\@thmcountersep \@thmcounter{#1}}%
+   \expandafter\xdef\csname #1name\endcsname{#2}%
+   \global\@namedef{#1}{\@spthm{#1}{\csname #1name\endcsname}{#4}{#5}}%
+                              \global\@namedef{end#1}{\@endtheorem}}}
+
+\def\@spynthm#1#2#3#4{\expandafter\@ifdefinable\csname #1\endcsname
+   {\@definecounter{#1}%
+   \expandafter\xdef\csname the#1\endcsname{\@thmcounter{#1}}%
+   \expandafter\xdef\csname #1name\endcsname{#2}%
+   \global\@namedef{#1}{\@spthm{#1}{\csname #1name\endcsname}{#3}{#4}}%
+                               \global\@namedef{end#1}{\@endtheorem}}}
+
+\def\@spothm#1[#2]#3#4#5{%
+  \@ifundefined{c@#2}{\@latexerr{No theorem environment `#2' defined}\@eha}%
+  {\expandafter\@ifdefinable\csname #1\endcsname
+  {\global\@namedef{the#1}{\@nameuse{the#2}}%
+  \expandafter\xdef\csname #1name\endcsname{#3}%
+  \global\@namedef{#1}{\@spthm{#2}{\csname #1name\endcsname}{#4}{#5}}%
+  \global\@namedef{end#1}{\@endtheorem}}}}
+
+\def\@spthm#1#2#3#4{\topsep 7\p@ \@plus2\p@ \@minus4\p@
+\refstepcounter{#1}%
+\@ifnextchar[{\@spythm{#1}{#2}{#3}{#4}}{\@spxthm{#1}{#2}{#3}{#4}}}
+
+\def\@spxthm#1#2#3#4{\@spbegintheorem{#2}{\csname the#1\endcsname}{#3}{#4}%
+                    \ignorespaces}
+
+\def\@spythm#1#2#3#4[#5]{\@spopargbegintheorem{#2}{\csname
+       the#1\endcsname}{#5}{#3}{#4}\ignorespaces}
+
+\def\@spbegintheorem#1#2#3#4{\trivlist
+                 \item[\hskip\labelsep{#3#1\ #2\@thmcounterend}]#4}
+
+\def\@spopargbegintheorem#1#2#3#4#5{\trivlist
+      \item[\hskip\labelsep{#4#1\ #2}]{#4(#3)\@thmcounterend\ }#5}
+
+% definition of \spnewtheorem* without number
+
+\def\@sthm#1#2{\@Ynthm{#1}{#2}}
+
+\def\@Ynthm#1#2#3#4{\expandafter\@ifdefinable\csname #1\endcsname
+   {\global\@namedef{#1}{\@Thm{\csname #1name\endcsname}{#3}{#4}}%
+    \expandafter\xdef\csname #1name\endcsname{#2}%
+    \global\@namedef{end#1}{\@endtheorem}}}
+
+\def\@Thm#1#2#3{\topsep 7\p@ \@plus2\p@ \@minus4\p@
+\@ifnextchar[{\@Ythm{#1}{#2}{#3}}{\@Xthm{#1}{#2}{#3}}}
+
+\def\@Xthm#1#2#3{\@Begintheorem{#1}{#2}{#3}\ignorespaces}
+
+\def\@Ythm#1#2#3[#4]{\@Opargbegintheorem{#1}
+       {#4}{#2}{#3}\ignorespaces}
+
+\def\@Begintheorem#1#2#3{#3\trivlist
+                           \item[\hskip\labelsep{#2#1\@thmcounterend}]}
+
+\def\@Opargbegintheorem#1#2#3#4{#4\trivlist
+      \item[\hskip\labelsep{#3#1}]{#3(#2)\@thmcounterend\ }}
+
+\if at envcntsect
+   \def\@thmcountersep{.}
+   \spnewtheorem{theorem}{Theorem}[section]{\bfseries}{\itshape}
+\else
+   \spnewtheorem{theorem}{Theorem}{\bfseries}{\itshape}
+   \if at envcntreset
+      \@addtoreset{theorem}{section}
+   \else
+      \@addtoreset{theorem}{chapter}
+   \fi
+\fi
+
+%definition of divers theorem environments
+\spnewtheorem*{claim}{Claim}{\itshape}{\rmfamily}
+\spnewtheorem*{proof}{Proof}{\itshape}{\rmfamily}
+\if at envcntsame % alle Umgebungen wie Theorem.
+   \def\spn at wtheorem#1#2#3#4{\@spothm{#1}[theorem]{#2}{#3}{#4}}
+\else % alle Umgebungen mit eigenem Zaehler
+   \if at envcntsect % mit section numeriert
+      \def\spn at wtheorem#1#2#3#4{\@spxnthm{#1}{#2}[section]{#3}{#4}}
+   \else % nicht mit section numeriert
+      \if at envcntreset
+         \def\spn at wtheorem#1#2#3#4{\@spynthm{#1}{#2}{#3}{#4}
+                                   \@addtoreset{#1}{section}}
+      \else
+         \def\spn at wtheorem#1#2#3#4{\@spynthm{#1}{#2}{#3}{#4}
+                                   \@addtoreset{#1}{chapter}}%
+      \fi
+   \fi
+\fi
+\spn at wtheorem{case}{Case}{\itshape}{\rmfamily}
+\spn at wtheorem{conjecture}{Conjecture}{\itshape}{\rmfamily}
+\spn at wtheorem{corollary}{Corollary}{\bfseries}{\itshape}
+\spn at wtheorem{definition}{Definition}{\bfseries}{\itshape}
+\spn at wtheorem{example}{Example}{\itshape}{\rmfamily}
+\spn at wtheorem{exercise}{Exercise}{\itshape}{\rmfamily}
+\spn at wtheorem{lemma}{Lemma}{\bfseries}{\itshape}
+\spn at wtheorem{note}{Note}{\itshape}{\rmfamily}
+\spn at wtheorem{problem}{Problem}{\itshape}{\rmfamily}
+\spn at wtheorem{property}{Property}{\itshape}{\rmfamily}
+\spn at wtheorem{proposition}{Proposition}{\bfseries}{\itshape}
+\spn at wtheorem{question}{Question}{\itshape}{\rmfamily}
+\spn at wtheorem{solution}{Solution}{\itshape}{\rmfamily}
+\spn at wtheorem{remark}{Remark}{\itshape}{\rmfamily}
+
+\def\@takefromreset#1#2{%
+    \def\@tempa{#1}%
+    \let\@tempd\@elt
+    \def\@elt##1{%
+        \def\@tempb{##1}%
+        \ifx\@tempa\@tempb\else
+            \@addtoreset{##1}{#2}%
+        \fi}%
+    \expandafter\expandafter\let\expandafter\@tempc\csname cl@#2\endcsname
+    \expandafter\def\csname cl@#2\endcsname{}%
+    \@tempc
+    \let\@elt\@tempd}
+
+\def\theopargself{\def\@spopargbegintheorem##1##2##3##4##5{\trivlist
+      \item[\hskip\labelsep{##4##1\ ##2}]{##4##3\@thmcounterend\ }##5}
+                  \def\@Opargbegintheorem##1##2##3##4{##4\trivlist
+      \item[\hskip\labelsep{##3##1}]{##3##2\@thmcounterend\ }}
+      }
+
+\renewenvironment{abstract}{%
+      \list{}{\advance\topsep by0.35cm\relax\small
+      \leftmargin=1cm
+      \labelwidth=\z@
+      \listparindent=\z@
+      \itemindent\listparindent
+      \rightmargin\leftmargin}\item[\hskip\labelsep
+                                    \bfseries\abstractname]}
+    {\endlist}
+\renewcommand{\abstractname}{Abstract.}
+\renewcommand{\contentsname}{Table of Contents}
+\renewcommand{\figurename}{Fig.}
+\renewcommand{\tablename}{Table}
+
+\newdimen\headlineindent             % dimension for space between
+\headlineindent=1.166cm              % number and text of headings.
+
+\def\ps at headings{\let\@mkboth\@gobbletwo
+   \let\@oddfoot\@empty\let\@evenfoot\@empty
+   \def\@evenhead{\normalfont\small\rlap{\thepage}\hspace{\headlineindent}%
+                  \leftmark\hfil}
+   \def\@oddhead{\normalfont\small\hfil\rightmark\hspace{\headlineindent}%
+                 \llap{\thepage}}
+   \def\chaptermark##1{}%
+   \def\sectionmark##1{}%
+   \def\subsectionmark##1{}}
+
+\def\ps at titlepage{\let\@mkboth\@gobbletwo
+   \let\@oddfoot\@empty\let\@evenfoot\@empty
+   \def\@evenhead{\normalfont\small\rlap{\thepage}\hspace{\headlineindent}%
+                  \hfil}
+   \def\@oddhead{\normalfont\small\hfil\hspace{\headlineindent}%
+                 \llap{\thepage}}
+   \def\chaptermark##1{}%
+   \def\sectionmark##1{}%
+   \def\subsectionmark##1{}}
+
+\if at runhead\ps at headings\else
+\ps at empty\fi
+
+\setlength\arraycolsep{1.4\p@}
+\setlength\tabcolsep{1.4\p@}
+
+\endinput
+
diff --git a/2005/challenges/tor-design.bib b/2005/challenges/tor-design.bib
new file mode 100644
index 0000000..981761e
--- /dev/null
+++ b/2005/challenges/tor-design.bib
@@ -0,0 +1,1493 @@
+% hs-attack
+ at inproceedings{hs-attack,
+  title = {Locating Hidden Servers},
+  author = {Lasse {\O}verlier and Paul Syverson}, 
+  booktitle = {Proceedings of the 2006 IEEE Symposium on Security and Privacy}, 
+  year = {2006}, 
+  month = {May}, 
+  publisher = {IEEE CS},
+}
+
+
+ at TechReport{bauer:tr2007,
+  author = 	 {Kevin Bauer and Damon McCoy and Dirk Grunwald and Tadayoshi Kohno and Douglas Sicker},
+  title = 	 {Low-Resource Routing Attacks Against Anonymous Systems},
+  institution =  {University of Colorado at Boulder},
+  year = 	 2007,
+  number = 	 {CU-CS-1025-07}
+}
+
+ at inproceedings{bauer:wpes2007,
+  title = {Low-Resource Routing Attacks Against Tor},
+  author = {Kevin Bauer and Damon McCoy and Dirk Grunwald and Tadayoshi Kohno and Douglas Sicker},
+  booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2007)}},
+  year = {2007},
+  month = {October},
+  address = {Washington, DC, USA},
+}
+
+% fix me
+ at misc{tannenbaum96,
+  author = "Andrew Tannenbaum",
+  title = "Computer Networks",
+  year = "1996",
+  publisher = "Prentice Hall, 3rd edition",
+}
+
+ at article{ meadows96,
+    author = "Catherine Meadows",
+    title = "The {NRL} Protocol Analyzer: An Overview",
+    journal = "Journal of Logic Programming",
+    volume = "26",
+    number = "2",
+    pages = "113--131",
+    year = "1996",
+}
+ at inproceedings{kesdogan:pet2002,
+  title = {Unobservable Surfing on the World Wide Web: Is Private Information Retrieval an
+        alternative to the MIX based Approach?},
+  author = {Dogan Kesdogan and Mark Borning and Michael Schmeink},
+  booktitle = {Privacy Enhancing Technologies (PET 2002)},
+  year = {2002},
+  month = {April},
+  editor = {Roger Dingledine and Paul Syverson},
+  publisher = {Springer-Verlag, LNCS 2482},
+}
+
+ at inproceedings{statistical-disclosure,
+  title = {Statistical Disclosure Attacks},
+  author = {George Danezis},
+  booktitle = {Security and Privacy in the Age of Uncertainty ({SEC2003})},
+  organization = {{IFIP TC11}},
+  year = {2003},
+  month = {May},
+  address = {Athens},
+  pages = {421--426},
+  publisher = {Kluwer},
+}
+
+ at inproceedings{limits-open,
+  title = {Limits of Anonymity in Open Environments},
+  author = {Dogan Kesdogan and Dakshi Agrawal and Stefan Penz},
+  booktitle = {Information Hiding Workshop (IH 2002)},
+  year = {2002},
+  month = {October},
+  editor = {Fabien Petitcolas},
+  publisher = {Springer-Verlag, LNCS 2578},
+}
+
+ at inproceedings{isdn-mixes,
+  title = {{ISDN-mixes: Untraceable communication with very small bandwidth overhead}},
+  author = {Andreas Pfitzmann and Birgit Pfitzmann and Michael Waidner},
+  booktitle = {GI/ITG Conference on Communication in Distributed Systems},
+  year = {1991},
+  month = {February},
+  pages = {451-463},
+}
+
+
+ at Article{jerichow-jsac98,
+  author = 	 {Anja Jerichow and Jan M\"{u}ller and Andreas
+                  Pfitzmann and Birgit Pfitzmann and Michael Waidner},
+  title = 	 {Real-Time Mixes: A Bandwidth-Efficient Anonymity Protocol},
+  journal = 	 {IEEE Journal on Selected Areas in Communications},
+  year = 	 1998,
+  volume =	 16,
+  number =	 4,
+  pages =	 {495--509},
+  month =	 {May}
+}
+
+ at inproceedings{tarzan:ccs02,
+  title = {Tarzan: A Peer-to-Peer Anonymizing Network Layer},
+  author = {Michael J. Freedman and Robert Morris},
+  booktitle = {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 = {Ottawa Linux Symposium},
+  year = {2002},
+  month = {June},
+}
+
+ at inproceedings{eax,
+  author = "M. Bellare and P. Rogaway and D. Wagner",
+  title = {The {EAX} Mode of Operation: A Two-Pass Authenticated-Encryption Scheme Optimized for Simplicity and Efficiency},
+  booktitle = {Fast Software Encryption 2004},
+  month = {February},
+  year = {2004},
+}
+
+ at 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},
+  note = {\newline \url{http://codeen.cs.princeton.edu/}},
+}
+%  note = {Submitted to HotNets-II. \url{http://codeen.cs.princeton.edu/}},
+
+ at Misc{anonymizer,
+  key =          {anonymizer},
+  title =        {The {Anonymizer}},
+  note =         {\url{http://anonymizer.com/}}
+}
+
+ at Misc{privoxy,
+  key =          {privoxy},
+  title =        {{Privoxy}},
+  note =         {\url{http://www.privoxy.org/}}
+}
+
+ at Misc{i2p,
+  key =          {i2p},
+  title =        {{I2P}},
+  note =         {\url{http://www.i2p.net/}}
+}
+
+ at Misc{nym,
+  author = 	 {Jason Holt},
+  title = 	 {nym: practical pseudonymity for anonymous networks},
+  note = 	 {Paper and source code at \url{http://www.lunkwill.org/src/nym/}}
+}
+
+ at InProceedings{nymble,
+  author = 	 {Peter C. Johnson and Apu Kapadia and Patrick P. Tsang and Sean W. Smith},
+  title = 	 {Nymble: Anonymous {IP}-address Blocking},
+  booktitle = {Privacy Enhancing Technologies (PET 2007)},
+  year = 	 2007,
+  publisher = {Springer-Verlag, LNCS 4776}
+}
+
+ at inproceedings{anonnet,
+  title = {{Analysis of an Anonymity Network for Web Browsing}},
+  author = {Marc Rennhard and Sandro Rafaeli and Laurent Mathy and Bernhard Plattner and
+        David Hutchison},
+  booktitle = {{IEEE 7th Intl. Workshop on Enterprise Security (WET ICE
+        2002)}},
+  year = {2002},
+  month = {June},
+  address = {Pittsburgh, USA},
+}
+%  pages = {49--54},
+
+ at inproceedings{econymics,
+  title = {On the Economics of Anonymity},
+  author = {Alessandro Acquisti and Roger Dingledine and Paul Syverson},
+  booktitle = {Financial Cryptography},
+  year = {2003},
+  editor = {Rebecca N. Wright},
+  publisher = {Springer-Verlag, LNCS 2742},
+}
+
+ at inproceedings{defensive-dropping,
+  title = {Timing Analysis in Low-Latency Mix-Based Systems},
+  author = {Brian N. Levine and Michael K. Reiter and Chenxi Wang and Matthew Wright},
+  booktitle = {Financial Cryptography},
+  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},
+  year = {2004},
+  editor = {Ari Juels},
+  publisher = {Springer-Verlag, LNCS (forthcoming)},
+}
+
+ at inproceedings{eternity,
+  title = {The Eternity Service},
+  author = {Ross Anderson},
+  booktitle = {Pragocrypt '96},
+  year = {1996},
+}
+  %note =  {\url{http://www.cl.cam.ac.uk/users/rja14/eternity/eternity.html}},
+
+
+ at inproceedings{minion-design,
+  title = {Mixminion: Design of a Type {III} Anonymous Remailer Protocol},
+  author = {George Danezis and Roger Dingledine and Nick Mathewson},
+  booktitle = {2003 IEEE Symposium on Security and Privacy},
+  year = {2003},
+  month = {May},
+  publisher = {IEEE CS},
+  pages = {2--15},
+}
+  %note = {\url{http://mixminion.net/minion-design.pdf}},
+
+ at inproceedings{ rao-pseudonymity,
+    author = "Josyula R. Rao and Pankaj Rohatgi",
+    title = "Can Pseudonymity Really Guarantee Privacy?",
+    booktitle = "Proceedings of the Ninth USENIX Security Symposium",
+    year = {2000},
+    month = Aug,
+    publisher = {USENIX},
+    pages = "85--96",
+}
+    %note = {\url{http://www.usenix.org/publications/library/proceedings/sec2000/
+%full_papers/rao/rao.pdf}},
+
+ at InProceedings{pfitzmann90how,
+    author = "Birgit Pfitzmann and Andreas Pfitzmann",
+    title = "How to Break the Direct {RSA}-Implementation of {MIXes}",
+    booktitle = {Eurocrypt 89},
+    publisher = {Springer-Verlag, LNCS 434},
+    year = {1990},
+    note = {\url{http://citeseer.nj.nec.com/pfitzmann90how.html}},
+}
+
+ at Misc{tor-spec,
+   author =      {Roger Dingledine and Nick Mathewson},
+   title =       {Tor Protocol Specifications},
+   note =        {\url{https://www.torproject.org/svn/trunk/doc/tor-spec.txt}},
+}
+
+ at Misc{incentives-txt,
+   author =      {Roger Dingledine and Nick Mathewson},
+   title =       {Tor Incentives Design Brainstorms},
+   note =        {\url{https://www.torproject.org/svn/trunk/doc/incentives.txt}},
+}
+
+ at InProceedings{BM:mixencrypt,
+  author =       {M{\"o}ller, Bodo},
+  title =        {Provably Secure Public-Key Encryption for Length-Preserving Chaumian Mixes},
+  booktitle =    {{CT-RSA} 2003},
+  publisher =    {Springer-Verlag, LNCS 2612},
+  year =         2003,
+}
+
+ at InProceedings{back01,
+  author =       {Adam Back and Ulf M\"oller and Anton Stiglic},
+  title =        {Traffic Analysis Attacks and Trade-Offs in Anonymity Providing Systems},
+  booktitle =    {Information Hiding (IH 2001)},
+  pages =        {245--257},
+  year =         2001,
+  editor =       {Ira S. Moskowitz},
+  publisher =    {Springer-Verlag, LNCS 2137},
+}
+  %note =         {\newline \url{http://www.cypherspace.org/adam/pubs/traffic.pdf}},
+
+ at InProceedings{rackoff93cryptographic,
+   author =      {Charles Rackoff and Daniel R. Simon},
+   title =       {Cryptographic Defense Against Traffic Analysis},
+   booktitle =   {{ACM} Symposium on Theory of Computing},
+   pages =       {672--681},
+   year =        {1993},
+}
+   %note =        {\url{http://research.microsoft.com/crypto/dansimon/me.htm}},
+
+ at InProceedings{freehaven-berk,
+   author =      {Roger Dingledine and Michael J. Freedman and David Molnar},
+   title =       {The Free Haven Project: Distributed Anonymous Storage Service},
+   booktitle =   {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+   year =        2000,
+   month =       {July},
+   editor =      {H. Federrath},
+   publisher =   {Springer-Verlag, LNCS 2009},
+}
+
+   @InProceedings{move-ndss05,
+  author = 	 {Angelos Stavrou and Angelos D. Keromytis and Jason Nieh and Vishal Misra and Dan Rubenstein},
+  title = 	 {MOVE: An End-to-End Solution To Network Denial of Service},
+  booktitle = 	 {{ISOC Network and Distributed System Security Symposium (NDSS05)}},
+  year =	 2005,
+  month =	 {February},
+  publisher =	 {Internet Society}
+}
+
+%note =        {\url{http://freehaven.net/papers.html}},
+
+
+
+
+ at InProceedings{raymond00,
+  author =       {J. F. Raymond},
+  title =        {{Traffic Analysis: Protocols, Attacks, Design Issues,
+                  and Open Problems}},
+  booktitle =    {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+  year =         2000,
+  month =        {July},
+  pages =        {10-29},
+  editor =       {H. Federrath},
+  publisher =    {Springer-Verlag, LNCS 2009},
+}
+
+ at InProceedings{sybil,
+  author = "John Douceur",
+  title = {{The Sybil Attack}},
+  booktitle = "Proceedings of the 1st International Peer To Peer Systems Workshop (IPTPS)",
+  month = Mar,
+  year = 2002,
+}
+
+
+ at InCollection{price-privacy,
+  author =	 {Paul Syverson and Adam Shostack},
+  editor =	 {L. Jean Camp and Stephen Lewis},
+  title = 	 {What Price Privacy? (and why identity theft is about neither identity nor theft)},
+  booktitle =	 {Economics of Information Security},
+  chapter = 	 10,
+  publisher = 	 {Kluwer},
+  year = 	 2004,
+  pages =	 {129--142}
+}
+
+
+ at InProceedings{trickle02,
+  author =       {Andrei Serjantov and Roger Dingledine and Paul Syverson},
+  title =        {From a Trickle to a Flood: Active Attacks on Several
+                  Mix Types},
+  booktitle =    {Information Hiding (IH 2002)},
+  year =         {2002},
+  editor =       {Fabien Petitcolas},
+  publisher =    {Springer-Verlag, LNCS 2578},
+}
+
+ at InProceedings{langos02,
+  author =      {Oliver Berthold and Heinrich Langos},
+  title =       {Dummy Traffic Against Long Term Intersection Attacks},
+  booktitle =    {Privacy Enhancing Technologies (PET 2002)},
+  year =         {2002},
+  editor =       {Roger Dingledine and Paul Syverson},
+  publisher =    {Springer-Verlag, LNCS 2482}
+}
+
+
+ at InProceedings{hintz-pet02,
+  author = 	 {Andrew Hintz},
+  title = 	 {Fingerprinting Websites Using Traffic Analysis},
+  booktitle = 	 {Privacy Enhancing Technologies (PET 2002)},
+  pages =	 {171--178},
+  year =	 2002,
+  editor =	 {Roger Dingledine and Paul Syverson},
+  publisher =	 {Springer-Verlag, LNCS 2482}
+}
+
+ at InProceedings{or-discex00,
+   author =      {Paul Syverson and Michael Reed and David Goldschlag},
+   title =       {{O}nion {R}outing Access Configurations},
+   booktitle =   {DARPA Information Survivability Conference and
+                  Exposition (DISCEX 2000)},
+   year =        {2000},
+   publisher =   {IEEE CS Press},
+   pages =       {34--40},
+   volume =      {1},
+}
+   %note =        {\newline \url{http://www.onion-router.net/Publications.html}},
+
+ at Inproceedings{or-pet00,
+  title =        {{Towards an Analysis of Onion Routing Security}},
+  author =       {Paul Syverson and Gene Tsudik and Michael Reed and
+                  Carl Landwehr},
+  booktitle =    {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+  year =         2000,
+  month =        {July},
+  pages =        {96--114},
+  editor =       {H. Federrath},
+  publisher =    {Springer-Verlag, LNCS 2009},
+}
+  %note =         {\url{http://www.onion-router.net/Publications/WDIAU-2000.ps.gz}},
+
+ at Inproceedings{freenet-pets00,
+  title =        {Freenet: A Distributed Anonymous Information Storage
+    and Retrieval System},
+  author =       {Ian Clarke and Oskar Sandberg and Brandon Wiley and
+    Theodore W. Hong},
+  booktitle =    {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+  year =         2000,
+  month =        {July},
+  pages =        {46--66},
+  editor =       {H. Federrath},
+  publisher =    {Springer-Verlag, LNCS 2009},
+}
+  %note =         {\url{http://citeseer.nj.nec.com/clarke00freenet.html}},
+
+ at InProceedings{or-ih96,
+  author =       {David M. Goldschlag and Michael G. Reed and Paul
+                  F. Syverson},
+  title =        {Hiding Routing Information},
+  booktitle =    {Information Hiding, First International Workshop},
+  pages =        {137--150},
+  year =         1996,
+  editor =       {R. Anderson},
+  month =        {May},
+  publisher =    {Springer-Verlag, LNCS 1174},
+}
+
+ at InProceedings{federrath-ih96,
+  author = 	 {Hannes Federrath and Anja Jerichow and Andreas Pfitzmann},
+  title = 	 {{MIXes} in Mobile Communication Systems: Location
+                  Management with Privacy},
+  booktitle =    {Information Hiding, First International Workshop},
+  pages =        {121--135},
+  year =         1996,
+  editor =       {R. Anderson},
+  month =        {May},
+  publisher =    {Springer-Verlag, LNCS 1174},
+}
+
+
+ at InProceedings{reed-protocols97,
+  author = 	 {Michael G. Reed and Paul F. Syverson and David
+                  M. Goldschlag},
+  title = 	 {Protocols Using Anonymous Connections: Mobile Applications},
+  booktitle = 	 {Security Protocols: 5th International Workshop},
+  pages =	 {13--23},
+  year =	 1997,
+  editor =	 {Bruce Christianson and Bruno Crispo and Mark Lomas
+                  and Michael Roe},
+  month =	 {April},
+  publisher =	 {Springer-Verlag, LNCS 1361}
+}
+
+
+
+ at Article{or-jsac98,
+  author =       {Michael G. Reed and Paul F. Syverson and David
+                  M. Goldschlag},
+  title =        {Anonymous Connections and Onion Routing},
+  journal =      {IEEE Journal on Selected Areas in Communications},
+  year =         1998,
+  volume =       16,
+  number =       4,
+  pages =        {482--494},
+  month =        {May},
+}
+  %note =         {\url{http://www.onion-router.net/Publications/JSAC-1998.ps.gz}}
+
+ at Misc{TLS,
+   author =      {T. Dierks and C. Allen},
+   title =       {The {TLS} {P}rotocol --- {V}ersion 1.0},
+   howpublished = {IETF RFC 2246},
+   month =       {January},
+   year =        {1999},
+}
+%note =        {\url{http://www.rfc-editor.org/rfc/rfc2246.txt}},
+
+ at Misc{SMTP,
+   author =      {J. Postel},
+   title =       {Simple {M}ail {T}ransfer {P}rotocol},
+   howpublished = {IETF RFC 2821 (also STD0010)},
+   month =       {April},
+   year =        {2001},
+   note =        {\url{http://www.rfc-editor.org/rfc/rfc2821.txt}},
+}
+
+ at Misc{IMAP,
+   author =      {M. Crispin},
+   title =       {Internet {M}essage {A}ccess {P}rotocol --- {V}ersion 4rev1},
+   howpublished = {IETF RFC 2060},
+   month =       {December},
+   year =        {1996},
+   note =        {\url{http://www.rfc-editor.org/rfc/rfc2060.txt}},
+}
+
+ at misc{pipenet,
+  title = {PipeNet 1.1},
+  author = {Wei Dai},
+  year = 1996,
+  month = {August},
+  howpublished = {Usenet post},
+  note = {\url{http://www.eskimo.com/~weidai/pipenet.txt} First mentioned
+      in a post to the cypherpunks list, Feb.\ 1995.},
+}
+
+
+ at Misc{POP3,
+   author =      {J. Myers and M. Rose},
+   title =       {Post {O}ffice {P}rotocol --- {V}ersion 3},
+   howpublished = {IETF RFC 1939 (also STD0053)},
+   month =       {May},
+   year =        {1996},
+   note =        {\url{http://www.rfc-editor.org/rfc/rfc1939.txt}},
+}
+
+
+ at InProceedings{shuffle,
+   author =      {C. Andrew Neff},
+   title =       {A Verifiable Secret Shuffle and its Application to E-Voting},
+   booktitle =    {8th ACM Conference on Computer and Communications
+                  Security (CCS-8)},
+   pages =       {116--125},
+   year =        2001,
+   editor =      {P. Samarati},
+   month =       {November},
+   publisher =   {ACM Press},
+}
+   %note =        {\url{http://www.votehere.net/ada_compliant/ourtechnology/
+   %                    technicaldocs/shuffle.pdf}},
+
+ at InProceedings{dolev91,
+   author =      {Danny Dolev and Cynthia Dwork and Moni Naor},
+   title =       {Non-Malleable Cryptography},
+   booktitle =   {23rd ACM Symposium on the Theory of Computing (STOC)},
+   pages =       {542--552},
+   year =        1991,
+   note =        {Updated version at
+                  \url{http://citeseer.nj.nec.com/dolev00nonmalleable.html}},
+}
+
+ at TechReport{rsw96,
+   author =      {Ronald L. Rivest and Adi Shamir and David A. Wagner},
+   title =       {Time-lock puzzles and timed-release Crypto},
+   year =        1996,
+   type =        {MIT LCS technical memo},
+   number =      {MIT/LCS/TR-684},
+   month =       {February},
+   note =        {\newline \url{http://citeseer.nj.nec.com/rivest96timelock.html}},
+}
+
+ at InProceedings{web-mix,
+   author =      {Oliver Berthold and Hannes Federrath and Stefan K\"opsell},
+   title =       {Web {MIX}es: A system for anonymous and unobservable
+                  {I}nternet access},
+  booktitle =    {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+   editor =       {H. Federrath},
+   publisher =    {Springer-Verlag, LNCS 2009},
+   year =        {2000},
+}
+%   pages =       {115--129},
+
+ at InProceedings{disad-free-routes,
+   author =      {Oliver Berthold and Andreas Pfitzmann and Ronny Standtke},
+   title =       {The disadvantages of free {MIX} routes and how to overcome
+                  them},
+   booktitle =   {Designing Privacy Enhancing Technologies: Workshop
+                  on Design Issue in Anonymity and Unobservability},
+   pages =       {30--45},
+   year =        2000,
+   editor =       {H. Federrath},
+   publisher =    {Springer-Verlag, LNCS 2009},
+}
+   %note =        {\url{http://www.tik.ee.ethz.ch/~weiler/lehre/netsec/Unterlagen/anon/
+   %                    disadvantages_berthold.pdf}},
+
+ at InProceedings{boneh00,
+   author =      {Dan Boneh and Moni Naor},
+   title =       {Timed Commitments},
+   booktitle =   {Advances in Cryptology -- {CRYPTO} 2000},
+   pages =       {236--254},
+   year =        2000,
+   publisher =   {Springer-Verlag, LNCS 1880},
+   note =        {\newline \url{http://crypto.stanford.edu/~dabo/abstracts/timedcommit.html}},
+}
+
+ at InProceedings{goldschlag98,
+   author =      {David M. Goldschlag and Stuart G. Stubblebine},
+   title =       {Publicly Verifiable Lotteries: Applications of
+                  Delaying Functions},
+   booktitle =   {Financial Cryptography},
+   pages =       {214--226},
+   year =        1998,
+   publisher =   {Springer-Verlag, LNCS 1465},
+   note =        {\newline \url{http://citeseer.nj.nec.com/goldschlag98publicly.html}},
+}
+
+ at InProceedings{syverson98,
+   author =      {Paul Syverson},
+   title =       {Weakly Secret Bit Commitment: Applications to
+                  Lotteries and Fair Exchange},
+   booktitle =   {Computer Security Foundations Workshop (CSFW11)},
+   pages =       {2--13},
+   year =        1998,
+   address =     {Rockport Massachusetts},
+   month =       {June},
+   publisher =   {IEEE CS Press},
+   note =        {\newline \url{http://chacs.nrl.navy.mil/publications/CHACS/1998/}},
+}
+
+ at Misc{shoup-iso,
+   author =      {Victor Shoup},
+   title =       {A Proposal for an {ISO} {S}tandard for Public Key Encryption (version 2.1)},
+   note =        {Revised December 20, 2001. \url{http://www.shoup.net/papers/}},
+}
+
+ at Misc{shoup-oaep,
+   author =      {Victor Shoup},
+   title =       {{OAEP} Reconsidered},
+   howpublished = {{IACR} e-print 2000/060},
+   note =        {\newline \url{http://eprint.iacr.org/2000/060/}},
+}
+
+ at Misc{oaep-still-alive,
+   author =      {E. Fujisaki and D. Pointcheval and T. Okamoto and J. Stern},
+   title =       {{RSA}-{OAEP} is Still Alive!},
+   howpublished = {{IACR} e-print 2000/061},
+   note =        {\newline \url{http://eprint.iacr.org/2000/061/}},
+}
+
+ at misc{echolot,
+  author = {Peter Palfrader},
+  title = {Echolot: a pinger for anonymous remailers},
+  note = {\url{http://www.palfrader.org/echolot/}},
+}
+
+ at Misc{mixmaster-attacks,
+   author =      {Lance Cottrell},
+   title =       {Mixmaster and Remailer Attacks},
+   note =        {\url{http://www.obscura.com/~loki/remailer/remailer-essay.html}},
+}
+
+ at Misc{mixmaster-spec,
+   author =      {Ulf M{\"o}ller and Lance Cottrell and Peter
+                  Palfrader and Len Sassaman},
+   title =       {Mixmaster {P}rotocol --- {V}ersion 2},
+   year =        {2003},
+   month =       {July},
+   howpublished = {Draft},
+   note =        {\url{http://www.abditum.com/mixmaster-spec.txt}},
+}
+
+ at InProceedings{puzzles-tls,
+    author = "Drew Dean and Adam Stubblefield",
+    title = {{Using Client Puzzles to Protect TLS}},
+    booktitle = "Proceedings of the 10th USENIX Security Symposium",
+    year = {2001},
+    month = Aug,
+    publisher = {USENIX},
+}
+
+ at InProceedings{breadpudding,
+  author =       {Markus Jakobsson and Ari Juels},
+  title =        {Proofs of Work and Bread Pudding Protocols},
+  booktitle =    {Proceedings of the IFIP TC6 and TC11 Joint Working
+                  Conference on Communications and Multimedia Security
+                  (CMS '99)},
+  year =         1999,
+  month =        {September},
+  publisher =    {Kluwer}
+}
+
+ at Misc{hashcash,
+   author =      {Adam Back},
+   title =       {Hash cash},
+   note =        {\newline \url{http://www.cypherspace.org/~adam/hashcash/}},
+}
+
+ at InProceedings{oreilly-acc,
+   author =      {Roger Dingledine and Michael J. Freedman and David Molnar},
+   title =       {Accountability},
+   booktitle =   {Peer-to-peer: Harnessing the Benefits of a Disruptive
+                  Technology},
+   year =        {2001},
+   publisher =   {O'Reilly and Associates},
+}
+
+
+ at InProceedings{han,
+   author =      {Yongfei Han},
+   title =       {Investigation of non-repudiation protocols},
+   booktitle =   {ACISP '96},
+   year =        1996,
+   publisher =   {Springer-Verlag},
+}
+
+
+ at Misc{socks5,
+  key =          {socks5},
+  title =        {{SOCKS} {P}rotocol {V}ersion 5},
+  howpublished=  {IETF RFC 1928},
+  month =        {March},
+  year =         1996,
+  note =         {\url{http://www.ietf.org/rfc/rfc1928.txt}}
+}
+
+ at InProceedings{abe,
+   author =      {Masayuki Abe},
+   title =       {Universally Verifiable {MIX} With Verification Work Independent of
+                  The Number of {MIX} Servers},
+   booktitle =   {{EUROCRYPT} 1998},
+   year =        {1998},
+   publisher =   {Springer-Verlag, LNCS 1403},
+}
+
+ at InProceedings{desmedt,
+   author =      {Yvo Desmedt and Kaoru Kurosawa},
+   title =       {How To Break a Practical {MIX} and Design a New One},
+   booktitle =   {{EUROCRYPT} 2000},
+   year =        {2000},
+   publisher =   {Springer-Verlag, LNCS 1803},
+   note =        {\url{http://citeseer.nj.nec.com/447709.html}},
+}
+
+ at InProceedings{mitkuro,
+   author =      {M. Mitomo and K. Kurosawa},
+   title =       {{Attack for Flash MIX}},
+   booktitle =   {{ASIACRYPT} 2000},
+   year =        {2000},
+   publisher =   {Springer-Verlag, LNCS 1976},
+   note =        {\newline \url{http://citeseer.nj.nec.com/450148.html}},
+}
+
+ at InProceedings{hybrid-mix,
+   author =      {M. Ohkubo and M. Abe},
+   title =       {A {L}ength-{I}nvariant {H}ybrid {MIX}},
+   booktitle =   {Advances in Cryptology - {ASIACRYPT} 2000},
+   year =        {2000},
+   publisher =   {Springer-Verlag, LNCS 1976},
+}
+
+ at InProceedings{PShuffle,
+  author = {Jun Furukawa and Kazue Sako},
+  title = {An Efficient Scheme for Proving a Shuffle},
+  editor    = {Joe Kilian},
+  booktitle = {CRYPTO 2001},
+  year      = {2001},
+  publisher = {Springer-Verlag, LNCS 2139},
+}
+
+
+ at InProceedings{jakobsson-optimally,
+  author = "Markus Jakobsson and Ari Juels",
+  title = "An Optimally Robust Hybrid Mix Network (Extended Abstract)",
+  booktitle =   {Principles of Distributed Computing - {PODC} '01},
+  year = "2001",
+  publisher =   {ACM Press},
+  note = {\url{http://citeseer.nj.nec.com/492015.html}},
+}
+
+ at InProceedings{kesdogan,
+   author =      {D. Kesdogan and M. Egner and T. B\"uschkes},
+   title =       {Stop-and-Go {MIX}es Providing Probabilistic Anonymity in an Open
+                  System},
+   booktitle =   {Information Hiding (IH 1998)},
+   year =        {1998},
+   publisher =   {Springer-Verlag, LNCS 1525},
+}
+   %note =        {\url{http://www.cl.cam.ac.uk/~fapp2/ihw98/ihw98-sgmix.pdf}},
+
+ at InProceedings{socks4,
+  author =       {David Koblas and Michelle R. Koblas},
+  title =        {{SOCKS}},
+  booktitle =    {UNIX Security III Symposium (1992 USENIX Security
+                  Symposium)},
+  pages =        {77--83},
+  year =         1992,
+  publisher =    {USENIX},
+}
+
+ at InProceedings{flash-mix,
+   author =      {Markus Jakobsson},
+   title =       {Flash {M}ixing},
+   booktitle =   {Principles of Distributed Computing - {PODC} '99},
+   year =        {1999},
+   publisher =   {ACM Press},
+   note =        {\newline \url{http://citeseer.nj.nec.com/jakobsson99flash.html}},
+}
+
+ at InProceedings{SK,
+   author =      {Joe Kilian and Kazue Sako},
+   title =       {Receipt-Free {MIX}-Type Voting Scheme - A Practical Solution to
+                  the Implementation of a Voting Booth},
+   booktitle =   {EUROCRYPT '95},
+   year =        {1995},
+   publisher =   {Springer-Verlag},
+}
+
+ at InProceedings{OAEP,
+   author =      {M. Bellare and P. Rogaway},
+   year =        {1994},
+   booktitle =   {EUROCRYPT '94},
+   title =       {Optimal {A}symmetric {E}ncryption {P}adding : How To Encrypt With
+                  {RSA}},
+   publisher =   {Springer-Verlag},
+   note =        {\newline \url{http://www-cse.ucsd.edu/users/mihir/papers/oaep.html}},
+}
+ at inproceedings{babel,
+  title = {Mixing {E}-mail With {B}abel},
+  author = {Ceki G\"ulc\"u and Gene Tsudik},
+  booktitle = {{Network and Distributed Security Symposium (NDSS 96)}},
+  year = 1996,
+  month = {February},
+  pages = {2--16},
+  publisher = {IEEE},
+}
+  %note = {\url{http://citeseer.nj.nec.com/2254.html}},
+
+ at Misc{rprocess,
+   author =      {RProcess},
+   title =       {Selective Denial of Service Attacks},
+   note =        {\newline \url{http://www.eff.org/pub/Privacy/Anonymity/1999\_09\_DoS\_remail\_vuln.html}},
+}
+
+ at Article{remailer-history,
+  author = {Sameer Parekh},
+  title = {Prospects for Remailers},
+  journal = {First Monday},
+  volume = {1},
+  number = {2},
+  month = {August},
+  year = {1996},
+  note = {\url{http://www.firstmonday.dk/issues/issue2/remailers/}},
+}
+
+ at Article{chaum-mix,
+   author =      {David Chaum},
+   title =       {Untraceable electronic mail, return addresses, and digital pseudo-nyms},
+   journal =     {Communications of the ACM},
+   year =        {1981},
+   volume =      {4},
+   number =      {2},
+   month =       {February},
+}
+   %note =        {\url{http://www.eskimo.com/~weidai/mix-net.txt}},
+
+ at InProceedings{nym-alias-net,
+  author =       {David Mazi\`{e}res and M. Frans Kaashoek},
+  title =        {{The Design, Implementation and Operation of an Email
+                  Pseudonym Server}},
+  booktitle =    {$5^{th}$ ACM Conference on Computer and
+                  Communications Security (CCS'98)},
+  year =         1998,
+  publisher =    {ACM Press},
+}
+  %note =        {\newline \url{http://www.scs.cs.nyu.edu/~dm/}},
+
+ at InProceedings{tangler,
+  author =       {Marc Waldman and David Mazi\`{e}res},
+  title =        {Tangler: A Censorship-Resistant Publishing System
+                  Based on Document Entanglements},
+  booktitle =    {$8^{th}$ ACM Conference on Computer and
+                  Communications Security (CCS-8)},
+  pages =        {86--135},
+  year =         2001,
+  publisher =    {ACM Press},
+}
+  %note =         {\url{http://www.scs.cs.nyu.edu/~dm/}}
+
+ at misc{neochaum,
+   author =      {Tim May},
+   title =       {Payment mixes for anonymity},
+   howpublished = {E-mail archived at
+                  \url{http://\newline www.inet-one.com/cypherpunks/dir.2000.02.28-2000.03.05/msg00334.html}},
+}
+
+ at misc{helsingius,
+   author =      {J. Helsingius},
+   title =       {{\tt anon.penet.fi} press release},
+   note =        {\newline \url{http://www.penet.fi/press-english.html}},
+}
+
+ at InProceedings{garay97secure,
+   author =      {J. Garay and R. Gennaro and C. Jutla and T. Rabin},
+   title =       {Secure distributed storage and retrieval},
+   booktitle =   {11th International Workshop, WDAG '97},
+   pages =       {275--289},
+   year =        {1997},
+   publisher =   {Springer-Verlag, LNCS 1320},
+   note =        {\newline \url{http://citeseer.nj.nec.com/garay97secure.html}},
+}
+
+ at InProceedings{PIK,
+   author =      {C. Park and K. Itoh and K. Kurosawa},
+   title =       {Efficient anonymous channel and all/nothing election scheme},
+   booktitle =   {Advances in Cryptology -- {EUROCRYPT} '93},
+   pages =       {248--259},
+   publisher =   {Springer-Verlag, LNCS 765},
+}
+
+ at Misc{pgpfaq,
+   key =         {PGP},
+   title =       {{PGP} {FAQ}},
+   note =        {\newline \url{http://www.faqs.org/faqs/pgp-faq/}},
+}
+
+ at Article{riordan-schneier,
+   author =      {James Riordan and Bruce Schneier},
+   title =       {A Certified E-mail Protocol with No Trusted Third Party},
+   journal =     {13th Annual Computer Security Applications Conference},
+   month =       {December},
+   year =        {1998},
+   note =        {\newline \url{http://www.counterpane.com/certified-email.html}},
+}
+
+
+ at Article{crowds-tissec,
+  author =       {Michael K. Reiter and Aviel D. Rubin},
+  title =        {Crowds: Anonymity for Web Transactions},
+  journal =      {ACM TISSEC},
+  year =         1998,
+  volume =       1,
+  number =       1,
+  pages =        {66--92},
+  month =        {June},
+}
+  %note =         {\url{http://citeseer.nj.nec.com/284739.html}}
+
+ at Article{crowds-dimacs,
+   author =      {Michael K. Reiter and Aviel D. Rubin},
+   title =       {Crowds: Anonymity for Web Transactions},
+   journal =     {{DIMACS} Technical Report (Revised)},
+   volume =      {97},
+   number =      {15},
+   month =       {August},
+   year =        {1997},
+}
+
+ at Misc{advogato,
+   author =      {Raph Levien},
+   title =       {Advogato's Trust Metric},
+   note =        {\newline \url{http://www.advogato.org/trust-metric.html}},
+}
+
+ at InProceedings{publius,
+   author =      {Marc Waldman and Aviel Rubin and Lorrie Cranor},
+   title =       {Publius: {A} robust, tamper-evident, censorship-resistant and
+                  source-anonymous web publishing system},
+   booktitle =   {Proc. 9th USENIX Security Symposium},
+   pages =       {59--72},
+   year =        {2000},
+   month =       {August},
+}
+   %note =        {\newline \url{http://citeseer.nj.nec.com/waldman00publius.html}},
+
+ at Misc{freedom-nyms,
+   author =      {Russell Samuels},
+   title =       {Untraceable Nym Creation on the {F}reedom {N}etwork},
+   year =        {1999},
+   month =       {November},
+   day =         {21},
+   note =        {\newline \url{http://www.freedom.net/products/whitepapers/white11.html}},
+}
+
+ at techreport{freedom2-arch,
+  title = {Freedom Systems 2.0 Architecture},
+  author = {Philippe Boucher and Adam Shostack and Ian Goldberg},
+  institution = {Zero Knowledge Systems, {Inc.}},
+  year = {2000},
+  month = {December},
+  type = {White Paper},
+  day = {18},
+}
+
+ at techreport{freedom21-security,
+  title = {Freedom Systems 2.1 Security Issues and Analysis},
+  author = {Adam Back and Ian Goldberg and Adam Shostack},
+  institution = {Zero Knowledge Systems, {Inc.}},
+  year = {2001},
+  month = {May},
+  type = {White Paper},
+}
+
+ at inproceedings{cfs:sosp01,
+  title = {Wide-area cooperative storage with {CFS}},
+  author = {Frank Dabek and M. Frans Kaashoek and David Karger and Robert Morris and Ion Stoica},
+  booktitle = {18th {ACM} {S}ymposium on {O}perating {S}ystems {P}rinciples ({SOSP} '01)},
+  year = {2001},
+  month = {October},
+  address = {Chateau Lake Louise, Banff, Canada},
+}
+
+ at inproceedings{SS03,
+  title = {Passive Attack Analysis for Connection-Based Anonymity Systems},
+  author = {Andrei Serjantov and Peter Sewell},
+  booktitle = {Computer Security -- ESORICS 2003},
+  publisher =   {Springer-Verlag, LNCS 2808},
+  year = {2003},
+  month = {October},
+}
+  %note = {\url{http://www.cl.cam.ac.uk/users/aas23/papers_aas/conn_sys.ps}},
+
+ at Misc{pk-relations,
+   author =      {M. Bellare and A. Desai and D. Pointcheval and P. Rogaway},
+   title =       {Relations Among Notions of Security for Public-Key Encryption
+                  Schemes},
+   howpublished = {
+                  Extended abstract in {\em Advances in Cryptology - CRYPTO '98}, LNCS Vol. 1462.
+                  Springer-Verlag, 1998.
+                  Full version available from \newline \url{http://www-cse.ucsd.edu/users/mihir/}},
+}
+
+
+ at InProceedings{mix-acc,
+  author =      {Roger Dingledine and Michael J. Freedman and David
+                  Hopwood and David Molnar},
+  title =       {{A Reputation System to Increase MIX-net
+                  Reliability}},
+  booktitle =   {Information Hiding (IH 2001)},
+  pages =       {126--141},
+  year =        2001,
+  editor =      {Ira S. Moskowitz},
+  publisher =   {Springer-Verlag, LNCS 2137},
+}
+  %note =        {\url{http://www.freehaven.net/papers.html}},
+
+ at InProceedings{casc-rep,
+   author =      {Roger Dingledine and Paul Syverson},
+   title =       {{Reliable MIX Cascade Networks through Reputation}},
+  booktitle =    {Financial Cryptography},
+  year =         2002,
+  editor =       {Matt Blaze},
+  publisher =    {Springer-Verlag, LNCS 2357},
+}
+  %note =        {\newline \url{http://www.freehaven.net/papers.html}},
+
+ at InProceedings{zhou96certified,
+   author =      {Zhou and Gollmann},
+   title =       {Certified Electronic Mail},
+   booktitle =   {{ESORICS: European Symposium on Research in Computer
+                  Security}},
+   publisher =   {Springer-Verlag, LNCS 1146},
+   year =        {1996},
+   note =        {\newline \url{http://citeseer.nj.nec.com/zhou96certified.html}},
+}
+
+ at Misc{realtime-mix,
+   author =      {Anja Jerichow and Jan M\"uller and Andreas Pfitzmann and
+                  Birgit Pfitzmann and Michael Waidner},
+   title =       {{Real-Time MIXes: A Bandwidth-Efficient Anonymity Protocol}},
+   howpublished = {IEEE Journal on Selected Areas in Communications, 1998.},
+   note =        {\url{http://www.zurich.ibm.com/security/publications/1998.html}},
+}
+
+ at InProceedings{danezis:pet2003,
+  author =       {George Danezis},
+  title =        {Mix-networks with Restricted Routes},
+  booktitle =    {Privacy Enhancing Technologies (PET 2003)},
+  year =         2003,
+  editor =       {Roger Dingledine},
+  publisher =    {Springer-Verlag LNCS 2760}
+}
+
+ at InProceedings{gap-pets03,
+  author =       {Krista Bennett and Christian Grothoff},
+  title =        {{GAP} -- practical anonymous networking},
+  booktitle =    {Privacy Enhancing Technologies (PET 2003)},
+  year =         2003,
+  editor =       {Roger Dingledine},
+  publisher =    {Springer-Verlag LNCS 2760}
+}
+
+ at Article{hordes-jcs,
+  author =       {Brian Neal Levine and Clay Shields},
+  title =        {Hordes: A Multicast-Based Protocol for Anonymity},
+  journal =      {Journal of Computer Security},
+  year =         2002,
+  volume =       10,
+  number =       3,
+  pages =        {213--240}
+}
+
+ at TechReport{herbivore,
+  author =       {Sharad Goel and Mark Robson and Milo Polte and Emin G\"{u}n Sirer},
+  title =        {Herbivore: A Scalable and Efficient Protocol for Anonymous Communication},
+  institution =  {Cornell University Computing and Information Science},
+  year =         2003,
+  type =         {Technical Report},
+  number =       {TR2003-1890},
+  month =        {February}
+}
+
+ at InProceedings{p5,
+  author =       {Rob Sherwood and Bobby Bhattacharjee and Aravind Srinivasan},
+  title =        {$P^5$: A Protocol for Scalable Anonymous Communication},
+  booktitle =    {IEEE Symposium on Security and Privacy},
+  pages =        {58--70},
+  year =         2002,
+  publisher =    {IEEE CS}
+}
+
+ at phdthesis{ian-thesis,
+  title = {A Pseudonymous Communications Infrastructure for the Internet},
+  author = {Ian Goldberg},
+  school = {UC Berkeley},
+  year = {2000},
+  month = {Dec},
+}
+
+ at Article{taz,
+  author =       {Ian Goldberg and David Wagner},
+  title =        {TAZ Servers and the Rewebber Network: Enabling
+                  Anonymous Publishing on the World Wide Web},
+  journal =      {First Monday},
+  year =         1998,
+  volume =       3,
+  number =       4,
+  month =        {August},
+  note =         {\url{http://www.firstmonday.dk/issues/issue3_4/goldberg/}}
+}
+
+ at Misc{tcp-over-tcp-is-bad,
+  key =          {tcp-over-tcp-is-bad},
+  title =        {Why {TCP} Over {TCP} Is A Bad Idea},
+  author =       {Olaf Titz},
+  note =         {\url{http://sites.inka.de/sites/bigred/devel/tcp-tcp.html}}
+}
+
+ at inproceedings{wright02,
+  title = {An Analysis of the Degradation of Anonymous Protocols},
+  author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
+  booktitle = {{Network and Distributed Security Symposium (NDSS 02)}},
+  year = {2002},
+  month = {February},
+  publisher = {IEEE},
+}
+
+ at inproceedings{wright03,
+  title = {Defending Anonymous Communication Against Passive Logging Attacks},
+  author = {Matthew Wright and Micah Adler and Brian Neil Levine and Clay Shields},
+  booktitle = {IEEE Symposium on Security and Privacy},
+  pages= {28--41},
+  year = {2003},
+  month = {May},
+  publisher = {IEEE CS},
+}
+
+
+ at InProceedings{attack-tor-oak05,
+  author = 	 {Steven J. Murdoch and George Danezis},
+  title = 	 {Low-cost Traffic Analysis of {T}or},
+  booktitle = 	 {IEEE Symposium on Security and Privacy},
+  year =	 2005,
+  month =	 {May},
+  publisher =	 {IEEE CS}
+}
+
+ at Misc{jap-backdoor,
+  author={{The AN.ON Project}},
+  howpublished={Press release},
+  year={2003},
+  month={September},
+  title={German Police proceeds against anonymity service},
+  note={\url{http://www.datenschutzzentrum.de/material/themen/presse/anon-bka_e.htm}}
+}
+
+ at article{shsm03,
+  title = {Using Caching for Browsing Anonymity},
+  author = {Anna Shubina and Sean Smith},
+  journal = {ACM SIGEcom Exchanges},
+  volume = {4},
+  number = {2},
+  year = {2003},
+  month = {Sept},
+  note = {\url{http://www.acm.org/sigs/sigecom/exchanges/volume_4_(03)/4.2-Shubina.pdf}},
+}
+
+ at inproceedings{tor-design,
+  title = {Tor: The Second-Generation Onion Router},
+  author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+  booktitle = {Proceedings of the 13th USENIX Security Symposium},
+  year = {2004},
+  month = {August},
+  note = {\url{https://www.torproject.org/tor-design.pdf}}
+}
+
+ at inproceedings{flow-correlation04,
+  title = {On Flow Correlation Attacks and Countermeasures in Mix Networks},
+  author = {Ye Zhu and Xinwen Fu and Bryan Graham and Riccardo Bettati and Wei Zhao},
+  booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)},
+  year = {2004},
+  month = {May},
+  series = {LNCS},
+  note = {\url{http://students.cs.tamu.edu/xinwenfu/paper/PET04.pdf}},
+}
+
+ at InProceedings{danezis:pet2004,
+  author = "George Danezis",
+  title = "The Traffic Analysis of Continuous-Time Mixes",
+  booktitle= {Privacy Enhancing Technologies (PET 2004)},
+  editor = {David Martin and Andrei Serjantov},
+  month = {May},
+  year = {2004},
+  series = {LNCS},
+  note = {\url{http://www.cl.cam.ac.uk/users/gd216/cmm2.pdf}},
+}
+
+ at inproceedings{feamster:wpes2004,
+  title = {Location Diversity in Anonymity Networks},
+  author = {Nick Feamster and Roger Dingledine},
+  booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}},
+  year = {2004},
+  month = {October},
+  address = {Washington, DC, USA},
+  note = {\url{http://freehaven.net/doc/routing-zones/routing-zones.ps}},
+}
+
+ at inproceedings{koepsell:wpes2004,
+  title = {How to Achieve Blocking Resistance for Existing Systems Enabling Anonymous Web Surfing},
+  author = {Stefan K\"opsell and Ulf Hilling},
+  booktitle = {{Proceedings of the Workshop on Privacy in the Electronic Society (WPES 2004)}},
+  year = {2004},
+  month = {October},
+  address = {Washington, DC, USA},
+  note = {\url{http://freehaven.net/anonbib/papers/p103-koepsell.pdf}},
+}
+
+ at inproceedings{sync-batching,
+  title = {Synchronous Batching: From Cascades to Free Routes},
+  author = {Roger Dingledine and Vitaly Shmatikov and Paul Syverson},
+  booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2004)},
+  editor = {David Martin and Andrei Serjantov},
+  year = {2004},
+  month = {May},
+  series = {LNCS},
+  note = {\url{http://freehaven.net/doc/sync-batching/sync-batching.pdf}},
+}
+
+ at InProceedings{e2e-traffic,
+  author = "Nick Mathewson and Roger Dingledine",
+  title = "Practical Traffic Analysis: Extending and Resisting Statistical Disclosure",
+  booktitle= {Privacy Enhancing Technologies (PET 2004)},
+  editor = {David Martin and Andrei Serjantov},
+  month = {May},
+  year = {2004},
+  series = {LNCS},
+  note = {\url{http://freehaven.net/doc/e2e-traffic/e2e-traffic.pdf}},
+}
+
+ at Misc{dtls,
+   author =      {E. Rescorla and N. Modadugu},
+   title =       {{Datagram Transport Layer Security}},
+   howpublished = {IETF Draft},
+   month =       {December},
+   year =        {2003},
+   note =        {\url{http://www.ietf.org/internet-drafts/draft-rescorla-dtls-02.txt}},
+}
+
+ at InProceedings{usability-network-effect,
+   author={Roger Dingledine and Nick Mathewson},
+   title={Anonymity Loves Company: Usability and the Network Effect},
+   booktitle = {Designing Security Systems That People Can Use},
+   year = {2005},
+   publisher = {O'Reilly Media},
+}
+
+ at inproceedings{usability:weis2006,
+  title = {Anonymity Loves Company: Usability and the Network Effect},
+  author = {Roger Dingledine and Nick Mathewson},
+  booktitle = {Proceedings of the Fifth Workshop on the Economics of Information Security
+        (WEIS 2006)},
+  year = {2006},
+  month = {June},
+  address = {Cambridge, UK},
+  bookurl = {http://weis2006.econinfosec.org/},
+  note = {\url{http://freehaven.net/doc/wupss04/usability.pdf}},
+}
+
+ at Misc{six-four,
+  key =          {six-four},
+  title =        {{The Six/Four System}},
+  note =         {\url{http://sourceforge.net/projects/sixfour/}}
+}
+
+ at inproceedings{clayton:pet2006,
+  title = {Ignoring the Great Firewall of China},
+  author = {Richard Clayton and Steven J. Murdoch and Robert N. M. Watson},
+  booktitle = {Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006)},
+  year = {2006},
+  month = {June},
+  address = {Cambridge, UK},
+  publisher = {Springer},
+  bookurl = {http://petworkshop.org/2006/},
+  note = {\url{http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf}},
+}
+
+ at Misc{zuckerman-threatmodels,
+  key =          {zuckerman-threatmodels},
+  title =        {We've got to adjust some of our threat models},
+  author =       {Ethan Zuckerman},
+  note =         {\url{http://www.ethanzuckerman.com/blog/?p=1019}}
+}
+
+ at Misc{cgiproxy,
+  key =          {cgiproxy},
+  title =        {{CGIProxy: HTTP/FTP Proxy in a CGI Script}},
+  author =       {James Marshall},
+  note =         {\url{http://www.jmarshall.com/tools/cgiproxy/}}
+}
+
+ at Misc{circumventor,
+  key =          {circumventor},
+  title =        {{How to install the Circumventor program}},
+  author =       {Bennett Haselton},
+  note =         {\url{http://www.peacefire.org/circumventor/simple-circumventor-instructions.html}}
+}
+
+ at Misc{psiphon,
+  key =          {psiphon},
+  title =        {Psiphon},
+  author =       {Ronald Deibert et al},
+  note =         {\url{http://psiphon.civisec.org/}}
+}
+
+ at InProceedings{tcpstego,                                                                    author =       {Steven J. Murdoch and Stephen Lewis},
+  title =        {Embedding Covert Channels into {TCP/IP}},
+  booktitle = {Information Hiding: 7th International Workshop},
+  pages  =       {247--261},
+  year =         {2005},
+  editor =       {Mauro Barni and Jordi Herrera-Joancomart\'{\i} and
+Stefan Katzenbeisser and Fernando P\'{e}rez-Gonz\'{a}lez},
+  volume =       {3727},
+  series =       {LNCS},
+  address =      {Barcelona, Catalonia (Spain)},
+  month =        {June},
+  publisher = {Springer-Verlag},
+  url = {http://www.cl.cam.ac.uk/~sjm217/papers/ih05coverttcp.pdf}
+}
+
+ at phdthesis{blossom-thesis,
+  title = {Perspective Access Networks},
+  author = {Geoffrey Goodell},
+  school = {Harvard University},
+  year = {2006},
+  month = {July},
+  note = {\url{http://afs.eecs.harvard.edu/~goodell/thesis.pdf}},
+}
+
+ at inproceedings{tap:pet2006,
+  title = {On the Security of the Tor Authentication Protocol},
+  author = {Ian Goldberg},
+  booktitle = {Proceedings of the Sixth Workshop on Privacy Enhancing Technologies (PET 2006)},
+  year = {2006},
+  month = {June},
+  address = {Cambridge, UK},
+  publisher = {Springer},
+  bookurl = {http://petworkshop.org/2006/},
+  note = {\url{http://www.cypherpunks.ca/~iang/pubs/torsec.pdf}},
+}
+
+ at inproceedings{rep-anon,
+  title = {{Reputation in P2P Anonymity Systems}},
+  author = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+  booktitle = {Proceedings of Workshop on Economics of Peer-to-Peer Systems},
+  year = {2003},
+  month = {June},
+  note = {\url{http://freehaven.net/doc/econp2p03/econp2p03.pdf}},
+}
+
+ at misc{tor-challenges,
+   author       = {Roger Dingledine and Nick Mathewson and Paul Syverson},
+   title        = {Challenges in deploying low-latency anonymity},
+   year         = {2005},
+   note         = {Manuscript}
+}
+
+ at InProceedings{chaum-blind,
+  author =       {David Chaum},
+  title =        {Blind Signatures for Untraceable Payments},
+  booktitle =    {Advances in Cryptology: Proceedings of Crypto 82},
+  pages =        {199--203},
+  year =         1983,
+  editor =       {D. Chaum and R.L. Rivest and A.T. Sherman},
+  publisher =    {Plenum Press}
+}
+
+ at Article{netauth,
+  author = {Geoffrey Goodell and Paul Syverson},
+  title = {The Right Place at the Right Time: Examining the use of network location in authentication and abuse prevention},
+  journal = 	 {Communications of the ACM},
+  year = 	 2007,
+  volume = 	 50,
+  number = 	 5,
+  pages = 	 {113--117},
+  month = 	 {May}
+}
+
+ at misc{ip-to-country,
+  key = {ip-to-country},
+  title = {IP-to-country database},
+  note = {\url{http://ip-to-country.webhosting.info/}},
+}
+
+ at misc{mackinnon-personal,
+  author = {Rebecca MacKinnon},
+  title = {Private communication},
+  year = {2006},
+}
+
+ at inproceedings{pet05-bissias,
+  title = {Privacy Vulnerabilities in Encrypted HTTP Streams},
+  author = {George Dean Bissias and Marc Liberatore and Brian Neil Levine},
+  booktitle = {Proceedings of Privacy Enhancing Technologies workshop (PET 2005)},
+  year = {2005},
+  month = {May},
+  note = {\url{http://prisms.cs.umass.edu/brian/pubs/bissias.liberatore.pet.2005.pdf}},
+}
+
+ at InProceedings{infranet,
+   author =      {Nick Feamster and Magdalena Balazinska and Greg Harfst and Hari Balakrishnan and David Karger},
+   title =       {Infranet: Circumventing Web Censorship and Surveillance},
+   booktitle =   {Proceedings of the 11th USENIX Security Symposium},
+   year =        {2002},
+   month =       {August},
+   note = {\url{http://nms.lcs.mit.edu/~feamster/papers/usenixsec2002.pdf}},
+}
+
+ at techreport{ ptacek98insertion,
+  author = "Thomas H. Ptacek and Timothy N. Newsham",
+  title = "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection",
+  institution = "Secure Networks, Inc.",
+  address = "Suite 330, 1201 5th Street S.W, Calgary, Alberta, Canada, T2R-0Y6",
+  year = "1998",
+  url = "citeseer.ist.psu.edu/ptacek98insertion.html",
+}
+
+ at inproceedings{active-wardens,
+  author = "Gina Fisk and Mike Fisk and Christos Papadopoulos and Joshua Neil",
+  title = "Eliminating Steganography in Internet Traffic with Active Wardens",
+  booktitle = {Information Hiding Workshop (IH 2002)},
+  year = {2002},
+  month = {October},
+  editor = {Fabien Petitcolas},
+  publisher = {Springer-Verlag, LNCS 2578},
+}
+
+ at inproceedings{clog-the-queue,
+  title = {Don't Clog the Queue: Circuit Clogging and Mitigation in {P2P} anonymity schemes},
+  author = {Jon McLachlan and Nicholas Hopper},
+  booktitle = {Proceedings of Financial Cryptography (FC '08)},
+  year = {2008},
+  month = {January},
+}
+
+ at inproceedings{snader08,
+  title = {A Tune-up for {Tor}: Improving Security and Performance in the {Tor} Network},
+  author = {Robin Snader and Nikita Borisov},
+  booktitle = {Proceedings of the Network and Distributed Security Symposium - {NDSS} '08},
+  year = {2008},
+  month = {February},
+  publisher = {Internet Society},
+}
+
+ at inproceedings{murdoch-pet2008,
+  title = {Metrics for Security and Performance in Low-Latency Anonymity Networks},
+  author = {Steven J. Murdoch and Robert N. M. Watson},
+  booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing Technologies (PETS 2008)},
+  year = {2008},
+  month = {July},
+  address = {Leuven, Belgium},
+  pages = {115--132},
+  editor = {Nikita Borisov and Ian Goldberg},
+  publisher = {Springer},
+  bookurl = {http://petsymposium.org/2008/},
+}
+
+ at inproceedings{danezis-pet2008,
+  title = {Bridging and Fingerprinting: Epistemic Attacks on Route Selection},
+  author = {George Danezis and Paul Syverson},
+  booktitle = {Proceedings of the Eighth International Symposium on Privacy Enhancing Technologies (PETS 2008)},
+  year = {2008},
+  month = {July},
+  address = {Leuven, Belgium},
+  pages = {133--150},
+  editor = {Nikita Borisov and Ian Goldberg},
+  publisher = {Springer},
+  bookurl = {http://petsymposium.org/2008/},
+}
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "tor-design"
+%%% End: