Browse Source

Add initial background mumblings; more work tomorrow

svn:r586
Nick Mathewson 20 years ago
parent
commit
0149c4ed55
1 changed files with 94 additions and 4 deletions
  1. 94 4
      doc/tor-design.tex

+ 94 - 4
doc/tor-design.tex

@@ -167,13 +167,78 @@ open problems.
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 
-\Section{Threat model and background}
+\Section{Background and threat model}
 \label{sec:background}
 \label{sec:background}
 
 
+\SubSection{Related work}
+\label{sec:related-work}
+Modern anonymity designs date to Chaum's Mix-Net\cite{chaum-mix} design of
+1981.  Chaum proposed hiding sender-recipient connections by wrapping
+messages in several layers of public key cryptography, and relaying them
+through a path composed of Mix servers.  Mix servers in turn decrypt, delay,
+and re-order messages, before relay them along the path towards their
+destinations.
+
+Subsequent relay-based anonymity designs have diverged in two principal
+directions.  Some have, such as Babel\cite{babel}, Mixmaster\cite{mixmaster},
+and Mixminion\cite{minion-design}, attempt to maximize anonymity at the cost
+of introducing comparatively large and variable latencies.  Because of this
+decision, such \emph{high-latency} networks are well-suited for anonymous
+email, but introduce too much lag for interactive tasks such as web browsing,
+internet chat, or SSH connections.
+
+Tor belongs to the second category: \emph{low-latency} designs that attempt
+to anonymize interactive network traffic.  Because such traffic tends to
+involve a relatively large numbers of packets, it is difficult to prevent an
+attacker who can eavesdrop entry and exit points from correlating packets
+entering the anonymity network with packets leaving it. Although some
+work has been done to frustrate these attacks, they still...  
+[XXX go on to explain how the design choices implied in low-latency result in
+significantly different designs.]
+
+The simplest low-latency designs are single-hop proxies such as the
+Anonymizer, wherein a single trusted server removes identifying users' data
+before relaying it.  These designs are easy to analyze, but require end-users
+to trust the anonymizing proxy.
+
+More complex are distributed-trust, channel-based anonymizing systems.  In
+these designs, a user establishes one or more medium-term bidirectional
+end-to-end tunnels to exit servers, and uses those tunnels to deliver a
+number of low-latency packets to and from one or more destinations per
+tunnel.  Establishing tunnels is comparatively expensive and typically
+requires public-key cryptography, whereas relaying packets along a tunnel is
+comparatively inexpensive.  Because a tunnel crosses several servers, no
+single server can learn the user's communication partners.
+[XXX give examples.]  
+[XXX Everybody I know except Crowds and gnunet is in this category.  Am I
+right?]
+
+[XXX Should we add a paragraph dividing servers by all-at-once approach to
+  tunnel-building (OR1,Freedom1) versus piecemeal approach
+  (OR2,Anonnet?,Freedom2) ?]
+
+Distributed-trust anonymizing systems differ in how they prevent attackers
+from controlling too many servers and thus compromising too many user paths.
+Some protocols rely on a centrally maintained set of well-known anonymizing
+servers.  Others (such as Tarzan and MorphMix) allow unknown users to run
+servers, while using a limited resource (DHT space for Tarzan; IP space for
+MorphMix) to prevent an attacker from owning too much of the network.
+[XXX what else?  What does (say) crowds do?]
+
+Channel-based anonymizing systems also differ in their use of dummy traffic.
+[XXX]
+
+Finally, several systems provide low-latency anonymity without channel-based
+communication.  Crowds and [XXX] provide anonymity for HTTP requests; [...]
+
+[XXX Mention error recovery?]
+
+
 anonymizer
 anonymizer
 pipenet
 pipenet
-freedom
-onion routing
+freedom v1
+freedom v2
+onion routing v1
 isdn-mixes
 isdn-mixes
 crowds
 crowds
 real-time mixes, web mixes
 real-time mixes, web mixes
@@ -184,18 +249,43 @@ gnunet
 rewebbers
 rewebbers
 tarzan
 tarzan
 herbivore
 herbivore
+hordes
+cebolla (?)
 
 
-\SubSection{Known attacks against low-latency anonymity systems}
+[XXX Close by mentioning where Tor fits.]
 
 
+\SubSection{Our threat model}
+\label{subsec:threat-model}
 
 
+\SubSection{Known attacks against low-latency anonymity systems}
+\label{subsec:known-attacks}
 
 
 We discuss each of these attacks in more detail below, along with the
 We discuss each of these attacks in more detail below, along with the
 aspects of the Tor design that provide defense. We provide a summary
 aspects of the Tor design that provide defense. We provide a summary
 of the attacks and our defenses against them in Section \ref{sec:attacks}.
 of the attacks and our defenses against them in Section \ref{sec:attacks}.
 
 
+Passive attacks:
+simple observation,
+timing correlation,
+size correlation,
+option distinguishability,
+
+Active attacks:
+key compromise,
+iterated subpoena,
+run recipient,
+run a hostile node,
+compromise entire path,
+selectively DOS servers,
+introduce timing into messages,
+directory attacks,
+tagging attacks
+
 \Section{Design goals and assumptions}
 \Section{Design goals and assumptions}
 \label{sec:assumptions}
 \label{sec:assumptions}
 
 
+[XXX Perhaps the threat model belongs here.]
+
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 
 \Section{The Tor Design}
 \Section{The Tor Design}