nihilist/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-11-13 06:33:44 +01:00
Code Issues Packages Projects Releases Wiki Activity

more minor changes/additions

Browse Source 
svn:r692
This commit is contained in:
Roger Dingledine 2003-10-30 04:05:28 +00:00
parent 85aeaef6db
commit 2366ff33a9
1 changed files with 52 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

85
doc/tor-design.tex
View File

@ -170,8 +170,6 @@ anonymity against a realistic adversary, we leave these strategies out.
allows traffic to exit the circuit from the middle---thus allows traffic to exit the circuit from the middle---thus
frustrating traffic shape and volume attacks based on observing exit frustrating traffic shape and volume attacks based on observing exit
points. points.
%Or something like that. hm. Tone this down maybe? Or support it. -RD
%How's that? -PS
\item \textbf{Congestion control:} Earlier anonymity designs do not \item \textbf{Congestion control:} Earlier anonymity designs do not
address traffic bottlenecks. Unfortunately, typical approaches to load address traffic bottlenecks. Unfortunately, typical approaches to load
@ -344,7 +342,7 @@ build the anonymous channel all at once, using a layered ``onion'' of
public-key encrypted messages, each layer of which provides a set of session public-key encrypted messages, each layer of which provides a set of session
keys and the address of the next server in the channel. Tor as described keys and the address of the next server in the channel. Tor as described
herein, later designs of Freedom, and AnonNet \cite{anonnet} build the herein, later designs of Freedom, and AnonNet \cite{anonnet} build the
channel in stages, extending it one hop at a time, Amongst other things, this channel in stages, extending it one hop at a time. This approach
makes perfect forward secrecy feasible. makes perfect forward secrecy feasible.
Distributed-trust anonymizing systems differ in how they prevent attackers Distributed-trust anonymizing systems differ in how they prevent attackers
@ -375,12 +373,12 @@ has also been designed for other types of systems, including
ISDN \cite{isdn-mixes}, and mobile applications such as telephones and ISDN \cite{isdn-mixes}, and mobile applications such as telephones and
active badging systems \cite{federrath-ih96,reed-protocols97}. active badging systems \cite{federrath-ih96,reed-protocols97}.
Some systems, such as Crowds \cite{crowds-tissec}, do not rely changing the Some systems, such as Crowds \cite{crowds-tissec}, do not rely on changing the
appearance of packets to hide the path; rather they try to prevent an appearance of packets to hide the path; rather they try to prevent an
intermediary from knowing when whether it is talking to an ultimate intermediary from knowing whether it is talking to an initiator
initiator, or just another intermediary. Crowds uses no public-key or just another intermediary. Crowds uses no public-key
encryption, but the responder and all data are visible to all encryption, but the responder and all data are visible to all
nodes on the path so that anonymity of connection initiator depends on nodes on the path; so anonymity of the connection initiator depends on
filtering all identifying information from the data stream. Crowds only filtering all identifying information from the data stream. Crowds only
supports HTTP traffic. supports HTTP traffic.
@ -439,14 +437,21 @@ Tor's evolution.
for every protocol). This requirement also precludes systems in which for every protocol). This requirement also precludes systems in which
users who do not benefit from anonymity are required to run special users who do not benefit from anonymity are required to run special
software in order to communicate with anonymous parties. software in order to communicate with anonymous parties.
% XXX Our rendezvous points require clients to use our software to get to
% the location-hidden servers.
% Or at least, they require somebody near the client-side running our
% software. We haven't worked out the details of keeping it transparent
% for Alice if she's using some other http proxy somewhere. I guess the
% external http proxy should route through a Tor client, which automatically
% translates the foo.onion address? -RD
\item[Usability:] A hard-to-use system has fewer users---and because \item[Usability:] A hard-to-use system has fewer users---and because
anonymity systems hide users among users, a system with fewer users anonymity systems hide users among users, a system with fewer users
provides less anonymity. Thus, usability is not only a convenience, but is provides less anonymity. Usability is not only a convenience for Tor:
a security requirement for anonymity systems. In order to be usable, Tor it is a security requirement \cite{econymics,back01}. Tor
should work with most of a user's unmodified applications; shouldn't should work with most of a user's unmodified applications; shouldn't
introduce prohibitive delays; and should require the user to make as few introduce prohibitive delays; and should require the user to make as few
configuration decisions as possible. configuration decisions as possible.
\item[Flexibility:] Third, the protocol must be flexible and \item[Flexibility:] The protocol must be flexible and
well-specified, so that it can serve as a test-bed for future research in well-specified, so that it can serve as a test-bed for future research in
low-latency anonymity systems. Many of the open problems in low-latency low-latency anonymity systems. Many of the open problems in low-latency
anonymity networks (such as generating dummy traffic, or preventing anonymity networks (such as generating dummy traffic, or preventing
@ -468,31 +473,34 @@ Tor's evolution.
\end{description} \end{description}
\subsection{Non-goals} \subsection{Non-goals}
In favoring conservative, deployable designs, we have explicitly deferred a In favoring conservative, deployable designs, we have explicitly deferred
number of goals---not because they are undesirable in anonymity systems---but a number of goals. Many of these goals are desirable in anonymity systems,
these goals are either solved elsewhere, or present an area of active but we choose to defer them either because they are solved elsewhere,
research lacking a generally accepted solution. or because they present an area of active research lacking a generally
accepted solution.
\begin{description} \begin{description}
\item[Not Peer-to-peer:] Unlike Tarzan or Morphmix, Tor does not attempt to \item[Not Peer-to-peer:] Tarzan and Morphmix aim to
scale to completely decentralized peer-to-peer environments with thousands scale to completely decentralized peer-to-peer environments with thousands
of short-lived servers, many of which may be controlled by an adversary. of short-lived servers, many of which may be controlled by an adversary.
Because of the many open problems in this approach, Tor uses a more
conservative design.
\item[Not secure against end-to-end attacks:] Tor does not claim to provide a \item[Not secure against end-to-end attacks:] Tor does not claim to provide a
definitive solution to end-to-end timing or intersection attacks for users definitive solution to end-to-end timing or intersection attacks. Some
who do not run their own Onion Routers. approaches, such as running an onion router, may help; see Section
% Mention would-be approaches. -NM \ref{sec:analysis} for more discussion.
% Does that mean we do claim to solve intersection attack for
% the enclave-firewall model? -RD
% I don't think we should. -NM
\item[No protocol normalization:] Tor does not provide \emph{protocol \item[No protocol normalization:] Tor does not provide \emph{protocol
normalization} like Privoxy or the Anonymizer. In order to make clients normalization} like Privoxy or the Anonymizer. In order to make clients
indistinguishable when they complex and variable protocols such as HTTP, indistinguishable when they use complex and variable protocols such as HTTP,
Tor must be layered with a filtering proxy such as Privoxy to hide Tor must be layered with a filtering proxy such as Privoxy to hide
differences between clients, expunge protocol features that leak identity, differences between clients, expunge protocol features that leak identity,
and so on. Similarly, Tor does not currently integrate tunneling for and so on. Similarly, Tor does not currently integrate tunneling for
non-stream-based protocols; this too must be provided by an external non-stream-based protocols like UDP; this too must be provided by
service. an external service.
\item[Not steganographic:] Tor does doesn't try to conceal which users are % Actually, tunneling udp over tcp is probably horrible for some apps.
% Should this get its own non-goal bulletpoint? The motivation for
% non-goal-ness would be burden on clients / portability.
\item[Not steganographic:] Tor does not try to conceal which users are
sending or receiving communications; it only tries to conceal whom they are sending or receiving communications; it only tries to conceal whom they are
communicating with. communicating with.
\end{description} \end{description}
@ -500,8 +508,8 @@ research lacking a generally accepted solution.
\SubSection{Adversary Model} \SubSection{Adversary Model}
\label{subsec:adversary-model} \label{subsec:adversary-model}
Although a global passive adversary is the most commonly assumed when A global passive adversary is the most commonly assumed when
analyzing theoretical anonymity designs, like all practical low-latency analyzing theoretical anonymity designs. But like all practical low-latency
systems, Tor is not secure against this adversary. Instead, we assume an systems, Tor is not secure against this adversary. Instead, we assume an
adversary that is weaker than global with respect to distribution, but that adversary that is weaker than global with respect to distribution, but that
is not merely passive. Our threat model expands on that from is not merely passive. Our threat model expands on that from
@ -577,10 +585,12 @@ is not merely passive. Our threat model expands on that from
%% Tor-node retains the same signature keys and other private %% Tor-node retains the same signature keys and other private
%% state-information as the component it replaces). %% state-information as the component it replaces).
First, we assume most directory servers are honest, reliable, accurate, and First, we assume that a threshold of directory servers are honest,
trustworthy. That is, we assume that users periodically cross-check server reliable, accurate, and trustworthy.
directories, and that they always have access to at least one directory %% the rest of this isn't needed, if dirservers do threshold concensus dirs
server that they trust. % To augment this, users can periodically cross-check
%directories from each directory server (trust, but verify).
%, and that they always have access to at least one directory server that they trust.
Second, we assume that somewhere between ten percent and twenty Second, we assume that somewhere between ten percent and twenty
percent\footnote{In some circumstances---for example, if the Tor network is percent\footnote{In some circumstances---for example, if the Tor network is
@ -901,6 +911,7 @@ The attacker must be able to guess all previous bytes between Alice
and Bob on that circuit (including the pseudorandomness from the key and Bob on that circuit (including the pseudorandomness from the key
negotiation), plus the bytes in the current cell, to remove or modify the negotiation), plus the bytes in the current cell, to remove or modify the
cell. The computational overhead isn't so bad, compared to doing an AES cell. The computational overhead isn't so bad, compared to doing an AES
% XXX We never say we use AES. Say it somewhere above?
crypt at each hop in the circuit. We use only four bytes per cell to crypt at each hop in the circuit. We use only four bytes per cell to
minimize overhead; the chance that an adversary will correctly guess a minimize overhead; the chance that an adversary will correctly guess a
valid hash, plus the payload the current cell, is acceptly low, given valid hash, plus the payload the current cell, is acceptly low, given
@ -1166,7 +1177,7 @@ can upload their router descriptors.
rotation (link, onion, identity); Everybody already know directory rotation (link, onion, identity); Everybody already know directory
keys; how to approve new nodes (advogato, sybil, captcha (RTT)); keys; how to approve new nodes (advogato, sybil, captcha (RTT));
policy for handling connections with unknown ORs; diff-based policy for handling connections with unknown ORs; diff-based
retrieval; diff-based consesus; separate liveness from descriptor retrieval; diff-based consensus; separate liveness from descriptor
list]] list]]
Of course, a variety of attacks remain. An adversary who controls a Of course, a variety of attacks remain. An adversary who controls a
@ -1197,7 +1208,10 @@ techniques \cite{castro-liskov}.
But this library, while more efficient than previous Byzantine agreement But this library, while more efficient than previous Byzantine agreement
systems, is still complex and heavyweight for our purposes: we only need systems, is still complex and heavyweight for our purposes: we only need
to compute a single algorithm, and we do not require strict in-order to compute a single algorithm, and we do not require strict in-order
computation steps. The Tor directory servers build a consensus directory computation steps. Indeed, the complexity of Byzantine agreement protocols
threatens our security, because users cannot easily understand it and
thus have less trust in the directory servers. The Tor directory servers
build a consensus directory
through a simple four-round broadcast protocol. First, each server signs through a simple four-round broadcast protocol. First, each server signs
and broadcasts its current opinion to the other directory servers; each and broadcasts its current opinion to the other directory servers; each
server then rebroadcasts all the signed opinions it has received. At this server then rebroadcasts all the signed opinions it has received. At this
@ -1228,6 +1242,11 @@ won't aid traffic analysis by forcing clients to periodically announce
their existence to any central point. their existence to any central point.
% Mention Hydra as an example of non-clique topologies. -NM, from RD % Mention Hydra as an example of non-clique topologies. -NM, from RD
% also find some place to integrate that dirservers have to actually
% lay test circuits and use them, otherwise routers could connect to
% the dirservers but discard all other traffic.
% in some sense they're like reputation servers in \cite{mix-acc} -RD
\Section{Rendezvous points: location privacy} \Section{Rendezvous points: location privacy}
\label{sec:rendezvous} \label{sec:rendezvous}