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

commit c55937a3782b166e85f97dac308f258009794de8 Author: Karsten Loesing karsten.loesing@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@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@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@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@envcntreset\iffalse +\DeclareOption{envcountreset}{\let\if@envcntreset\iftrue} +\DeclareOption{citeauthoryear}{\let\citeauthoryear=Y} +\DeclareOption{oribibl}{\let\oribibl=Y} +\let\if@custvec\iftrue +\DeclareOption{orivec}{\let\if@custvec\iffalse} +\let\if@envcntsame\iffalse +\DeclareOption{envcountsame}{\let\if@envcntsame\iftrue} +\let\if@envcntsect\iffalse +\DeclareOption{envcountsect}{\let\if@envcntsect\iftrue} +\let\if@runhead\iffalse +\DeclareOption{runningheads}{\let\if@runhead\iftrue} + +\let\if@openbib\iffalse +\DeclareOption{openbib}{\let\if@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@chapter} + +\newif\if@mainmatter @mainmattertrue +\newcommand\frontmatter{\cleardoublepage + @mainmatterfalse\pagenumbering{Roman}} +\newcommand\mainmatter{\cleardoublepage + @mainmattertrue\pagenumbering{arabic}} +\newcommand\backmatter{\if@openright\cleardoublepage\else\clearpage\fi + @mainmatterfalse} + +\renewcommand\part{\cleardoublepage + \thispagestyle{empty}% + \if@twocolumn + \onecolumn + @tempswatrue + \else + @tempswafalse + \fi + \null\vfil + \secdef@part@spart} + +\def@part[#1]#2{% + \ifnum \c@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@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@twoside + \null + \thispagestyle{empty}% + \newpage + \fi + \if@tempswa + \twocolumn + \fi} + +\newcommand\chapter{\clearpage + \thispagestyle{empty}% + \global@topnum\z@ + @afterindentfalse + \secdef@chapter@schapter} +\def@chapter[#1]#2{\ifnum \c@secnumdepth >\m@ne + \if@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@twocolumn + @topnewpage[@makechapterhead{#2}]% + \else + @makechapterhead{#2}% + @afterheading + \fi} +\def@makechapterhead#1{% +% \vspace*{50\p@}% + {\centering + \ifnum \c@secnumdepth >\m@ne + \if@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@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@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@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@restonecol\twocolumn\fi} + +\def\l@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@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@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@th \mkern @dotsep mu.\mkern + @dotsep mu$}\hfill + \nobreak\hbox to@pnumwidth{\hss #2}% + \fi\par + \penalty@highpenalty \endgroup} + +\def\l@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@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@section{@dottedtocline{1}{\tocchpnum}{\tocsecnum}} +\def\l@subsection{@dottedtocline{2}{\tocsectotal}{\tocsubsecnum}} +\def\l@subsubsection{@dottedtocline{3}{\tocsubsectotal}{\tocsubsubsecnum}} +\def\l@paragraph{@dottedtocline{4}{\tocsubsubsectotal}{\tocparanum}} +\def\l@subparagraph{@dottedtocline{5}{\tocparatotal}{\tocsubparanum}} + +\def\listoffigures{@restonecolfalse\if@twocolumn@restonecoltrue\onecolumn + \fi\section*{\listfigurename@mkboth{{\listfigurename}}{{\listfigurename}}} + @starttoc{lof}\if@restonecol\twocolumn\fi} +\def\l@figure{@dottedtocline{1}{0em}{1.5em}} + +\def\listoftables{@restonecolfalse\if@twocolumn@restonecoltrue\onecolumn + \fi\section*{\listtablename@mkboth{{\listtablename}}{{\listtablename}}} + @starttoc{lot}\if@restonecol\twocolumn\fi} +\let\l@table\l@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@enumiv}}% + {\settowidth\labelwidth{@biblabel{#1}}% + \leftmargin\labelwidth + \advance\leftmargin\labelsep + \if@openbib + \advance\leftmargin\bibindent + \itemindent -\bibindent + \listparindent \itemindent + \parsep \z@ + \fi + \usecounter{enumiv}% + \let\p@enumiv@empty + \renewcommand\theenumiv{@arabic\c@enumiv}}% + \if@openbib + \renewcommand\newblock{\par}% + \else + \renewcommand\newblock{\hskip .11em @plus.33em @minus.07em}% + \fi + \sloppy\clubpenalty4000\widowpenalty4000% + \sfcode`.=@m} + {\def@noitemerr + {@latex@warning{Empty `thebibliography' environment}}% + \endlist} +\def@lbibitem[#1]#2{\item[{[#1]}\hfill]\if@filesw + {\let\protect\noexpand\immediate + \write@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces} +\newcount@tempcntc +\def@citex[#1]#2{\if@filesw\immediate\write@auxout{\string\citation{#2}}\fi + @tempcnta\z@@tempcntb\m@ne\def@citea{}@cite{@for@citeb:=#2\do + {@ifundefined + {b@@citeb}{@citeo@tempcntb\m@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@ne + @citea\def@citea{,}\hbox{\csname b@@citeb\endcsname}% + \else + \advance@tempcntb@ne + \ifnum@tempcntb=@tempcntc + \else\advance@tempcntb\m@ne@citeo + @tempcnta@tempcntc@tempcntb@tempcntc\fi\fi}}@citeo}{#1}} +\def@citeo{\ifnum@tempcnta>@tempcntb\else + @citea\def@citea{,,\hskip\z@skip}% + \ifnum@tempcnta=@tempcntb\the@tempcnta\else + {\advance@tempcnta@ne\ifnum@tempcnta=@tempcntb \else + \def@citea{--}\fi + \advance@tempcnta\m@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@openbib + \advance\leftmargin\bibindent + \itemindent -\bibindent + \listparindent \itemindent + \parsep \z@ + \fi + \usecounter{enumiv}% + \let\p@enumiv@empty + \renewcommand\theenumiv{}}% + \if@openbib + \renewcommand\newblock{\par}% + \else + \renewcommand\newblock{\hskip .11em @plus.33em @minus.07em}% + \fi + \sloppy\clubpenalty4000\widowpenalty4000% + \sfcode`.=@m} + {\def@noitemerr + {@latex@warning{Empty `thebibliography' environment}}% + \endlist} + \def@cite#1{#1}% + \def@lbibitem[#1]#2{\item[]\if@filesw + {\def\protect##1{\string ##1\space}\immediate + \write@auxout{\string\bibcite{#2}{#1}}}\fi\ignorespaces} + \fi +\else +@cons@openbib@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@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@xt@\hsize{\hfil\box@tempboxa\hfil}% + \fi + \vskip\belowcaptionskip} + +\def\fps@figure{htbp} +\def\fnum@figure{\figurename\thinspace\thefigure} +\def @floatboxreset {% + \reset@font + \small + @setnobreak + @setminipage +} +\def\fps@table{htbp} +\def\fnum@table{\tablename~\thetable} +\renewenvironment{table} + {\setlength\abovecaptionskip{0\p@}% + \setlength\belowcaptionskip{10\p@}% + @float{table}} + {\end@float} +\renewenvironment{table*} + {\setlength\abovecaptionskip{0\p@}% + \setlength\belowcaptionskip{10\p@}% + @dblfloat{table}} + {\end@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@inst}$\enspace\ignorespaces}% + \setbox0=\vbox{\def\thanks##1{}@institute}% + \ifnum\c@@inst=1\relax + \else + \setcounter{footnote}{\c@@inst}% + \setcounter{@inst}{1}% + \noindent$^{\the@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@footnote}% + \if@twocolumn + \ifnum \col@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@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@xdef\toc@uthor{@author}}% + \else + \def\{\noexpand\protect\noexpand\newline}% + \protected@xdef\scratch{\the\tocauthor}% + \protected@xdef\toc@uthor{\scratch}% + \fi + \addtocontents{toc}{{\protect\raggedright\protect\leftskip15\p@ + \protect\rightskip@tocrmarg + \protect\itshape\toc@uthor\protect\endgraf}}% + \if@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@envcntsect + \def@thmcountersep{.} + \spnewtheorem{theorem}{Theorem}[section]{\bfseries}{\itshape} +\else + \spnewtheorem{theorem}{Theorem}{\bfseries}{\itshape} + \if@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@envcntsame % alle Umgebungen wie Theorem. + \def\spn@wtheorem#1#2#3#4{@spothm{#1}[theorem]{#2}{#3}{#4}} +\else % alle Umgebungen mit eigenem Zaehler + \if@envcntsect % mit section numeriert + \def\spn@wtheorem#1#2#3#4{@spxnthm{#1}{#2}[section]{#3}{#4}} + \else % nicht mit section numeriert + \if@envcntreset + \def\spn@wtheorem#1#2#3#4{@spynthm{#1}{#2}{#3}{#4} + @addtoreset{#1}{section}} + \else + \def\spn@wtheorem#1#2#3#4{@spynthm{#1}{#2}{#3}{#4} + @addtoreset{#1}{chapter}}% + \fi + \fi +\fi +\spn@wtheorem{case}{Case}{\itshape}{\rmfamily} +\spn@wtheorem{conjecture}{Conjecture}{\itshape}{\rmfamily} +\spn@wtheorem{corollary}{Corollary}{\bfseries}{\itshape} +\spn@wtheorem{definition}{Definition}{\bfseries}{\itshape} +\spn@wtheorem{example}{Example}{\itshape}{\rmfamily} +\spn@wtheorem{exercise}{Exercise}{\itshape}{\rmfamily} +\spn@wtheorem{lemma}{Lemma}{\bfseries}{\itshape} +\spn@wtheorem{note}{Note}{\itshape}{\rmfamily} +\spn@wtheorem{problem}{Problem}{\itshape}{\rmfamily} +\spn@wtheorem{property}{Property}{\itshape}{\rmfamily} +\spn@wtheorem{proposition}{Proposition}{\bfseries}{\itshape} +\spn@wtheorem{question}{Question}{\itshape}{\rmfamily} +\spn@wtheorem{solution}{Solution}{\itshape}{\rmfamily} +\spn@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@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@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@runhead\ps@headings\else +\ps@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 +@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}, +} + + +@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} +} + +@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 +@misc{tannenbaum96, + author = "Andrew Tannenbaum", + title = "Computer Networks", + year = "1996", + publisher = "Prentice Hall, 3rd edition", +} + +@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", +} +@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}, +} + +@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}, +} + +@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}, +} + +@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}, +} + + +@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} +} + +@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}, +} + +@inproceedings{cebolla, + title = {{Cebolla: Pragmatic IP Anonymity}}, + author = {Zach Brown}, + booktitle = {Ottawa Linux Symposium}, + year = {2002}, + month = {June}, +} + +@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}, +} + +@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/%7D%7D, +} +% note = {Submitted to HotNets-II. \url{http://codeen.cs.princeton.edu/%7D%7D, + +@Misc{anonymizer, + key = {anonymizer}, + title = {The {Anonymizer}}, + note = {\url{http://anonymizer.com/%7D%7D +} + +@Misc{privoxy, + key = {privoxy}, + title = {{Privoxy}}, + note = {\url{http://www.privoxy.org/%7D%7D +} + +@Misc{i2p, + key = {i2p}, + title = {{I2P}}, + note = {\url{http://www.i2p.net/%7D%7D +} + +@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/%7D%7D +} + +@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} +} + +@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}, + +@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}, +} + +@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)}, +} + +@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)}, +} + +@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%7D%7D, + + +@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%7D%7D, + +@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}}, + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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, +} + +@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%7D%7D, + +@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%7D%7D, + +@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%7D%7D, + + + + +@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}, +} + +@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, +} + + +@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} +} + + +@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}, +} + +@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} +} + + +@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} +} + +@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%7D%7D, + +@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%7D%7D, + +@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%7D%7D, + +@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}, +} + +@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}, +} + + +@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} +} + + + +@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%7D%7D + +@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%7D%7D, + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D First mentioned + in a post to the cypherpunks list, Feb.\ 1995.}, +} + + +@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%7D%7D, +} + + +@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}}, + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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}, + +@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}}, + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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/%7D%7D, +} + +@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/%7D%7D, +} + +@Misc{shoup-oaep, + author = {Victor Shoup}, + title = {{OAEP} Reconsidered}, + howpublished = {{IACR} e-print 2000/060}, + note = {\newline \url{http://eprint.iacr.org/2000/060/%7D%7D, +} + +@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/%7D%7D, +} + +@misc{echolot, + author = {Peter Palfrader}, + title = {Echolot: a pinger for anonymous remailers}, + note = {\url{http://www.palfrader.org/echolot/%7D%7D, +} + +@Misc{mixmaster-attacks, + author = {Lance Cottrell}, + title = {Mixmaster and Remailer Attacks}, + note = {\url{http://www.obscura.com/~loki/remailer/remailer-essay.html%7D%7D, +} + +@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%7D%7D, +} + +@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}, +} + +@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} +} + +@Misc{hashcash, + author = {Adam Back}, + title = {Hash cash}, + note = {\newline \url{http://www.cypherspace.org/~adam/hashcash/%7D%7D, +} + +@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}, +} + + +@InProceedings{han, + author = {Yongfei Han}, + title = {Investigation of non-repudiation protocols}, + booktitle = {ACISP '96}, + year = 1996, + publisher = {Springer-Verlag}, +} + + +@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%7D%7D +} + +@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}, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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}, +} + +@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}, +} + + +@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%7D%7D, +} + +@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%7D%7D, + +@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}, +} + +@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%7D%7D, +} + +@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}, +} + +@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%7D%7D, +} +@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%7D%7D, + +@Misc{rprocess, + author = {RProcess}, + title = {Selective Denial of Service Attacks}, + note = {\newline \url{http://www.eff.org/pub/Privacy/Anonymity/1999%5C_09%5C_DoS%5C_remail%5C_vuln..., +} + +@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/%7D%7D, +} + +@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%7D%7D, + +@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/%7D%7D, + +@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/%7D%7D + +@misc{neochaum, + author = {Tim May}, + title = {Payment mixes for anonymity}, + howpublished = {E-mail archived at + \url{http://%5Cnewline www.inet-one.com/cypherpunks/dir.2000.02.28-2000.03.05/msg00334.html}}, +} + +@misc{helsingius, + author = {J. Helsingius}, + title = {{\tt anon.penet.fi} press release}, + note = {\newline \url{http://www.penet.fi/press-english.html%7D%7D, +} + +@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%7D%7D, +} + +@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}, +} + +@Misc{pgpfaq, + key = {PGP}, + title = {{PGP} {FAQ}}, + note = {\newline \url{http://www.faqs.org/faqs/pgp-faq/%7D%7D, +} + +@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%7D%7D, +} + + +@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%7D%7D + +@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}, +} + +@Misc{advogato, + author = {Raph Levien}, + title = {Advogato's Trust Metric}, + note = {\newline \url{http://www.advogato.org/trust-metric.html%7D%7D, +} + +@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%7D%7D, + +@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%7D%7D, +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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%7D%7D, + +@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/%7D%7D, +} + + +@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%7D%7D, + +@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%7D%7D, + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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} +} + +@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} +} + +@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} +} + +@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} +} + +@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} +} + +@phdthesis{ian-thesis, + title = {A Pseudonymous Communications Infrastructure for the Internet}, + author = {Ian Goldberg}, + school = {UC Berkeley}, + year = {2000}, + month = {Dec}, +} + +@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/%7D%7D +} + +@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%7D%7D +} + +@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}, +} + +@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}, +} + + +@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} +} + +@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%7D%7D +} + +@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%7D%7..., +} + +@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%7D%7D +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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}, +} + +@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/%7D, + note = {\url{http://freehaven.net/doc/wupss04/usability.pdf%7D%7D, +} + +@Misc{six-four, + key = {six-four}, + title = {{The Six/Four System}}, + note = {\url{http://sourceforge.net/projects/sixfour/%7D%7D +} + +@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/%7D, + note = {\url{http://www.cl.cam.ac.uk/~rnc1/ignoring.pdf%7D%7D, +} + +@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%7D%7D +} + +@Misc{cgiproxy, + key = {cgiproxy}, + title = {{CGIProxy: HTTP/FTP Proxy in a CGI Script}}, + author = {James Marshall}, + note = {\url{http://www.jmarshall.com/tools/cgiproxy/%7D%7D +} + +@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%... +} + +@Misc{psiphon, + key = {psiphon}, + title = {Psiphon}, + author = {Ronald Deibert et al}, + note = {\url{http://psiphon.civisec.org/%7D%7D +} + +@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%7D +} + +@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%7D%7D, +} + +@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/%7D, + note = {\url{http://www.cypherpunks.ca/~iang/pubs/torsec.pdf%7D%7D, +} + +@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%7D%7D, +} + +@misc{tor-challenges, + author = {Roger Dingledine and Nick Mathewson and Paul Syverson}, + title = {Challenges in deploying low-latency anonymity}, + year = {2005}, + note = {Manuscript} +} + +@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} +} + +@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} +} + +@misc{ip-to-country, + key = {ip-to-country}, + title = {IP-to-country database}, + note = {\url{http://ip-to-country.webhosting.info/%7D%7D, +} + +@misc{mackinnon-personal, + author = {Rebecca MacKinnon}, + title = {Private communication}, + year = {2006}, +} + +@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%7D%7D, +} + +@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%7D%7D, +} + +@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", +} + +@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}, +} + +@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}, +} + +@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}, +} + +@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/%7D, +} + +@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/%7D, +} + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "tor-design" +%%% End: