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

More edits to edits; a few formatting fixes

Browse Source 
svn:r760
This commit is contained in:
Nick Mathewson 2003-11-04 22:52:39 +00:00
parent 5823d508df
commit 5c9e0685e6
1 changed files with 20 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

43
doc/tor-design.tex
View File

@ -119,25 +119,25 @@ application-level proxies such as Privoxy \cite{privoxy}, without trying
to duplicate those features itself.
\textbf{No mixing, padding, or traffic shaping yet:} Onion
Routing originally called for batching and reordering cells arriving from
each source, and assumed padding between ORs and, in a
later design, between onion proxies (users) and onion routers
Routing originally called for batching and reordering cells as they arrived,
assumed padding between ORs, and in
later designs added padding between onion proxies (users) and ORs
\cite{or-ih96,or-jsac98}. Tradeoffs between padding protection
and cost were discussed, but no general padding scheme was suggested.
It was theorized, \cite{or-pet00}, but not described how \emph{traffic
shaping} would generally be used. Recent research \cite{econymics}
It was theorized \cite{or-pet00} but not described how \emph{traffic
shaping} would be used. Recent research \cite{econymics}
and deployment experience \cite{freedom21-security} suggest that this
level of resource use is not practical or economical; and even full
link padding is still vulnerable \cite{defensive-dropping}. Thus,
until we have a proven and convenient design for traffic shaping or
low-latency mixing that will improve anonymity against a realistic
low-latency mixing that improves anonymity against a realistic
adversary, we leave these strategies out.
\textbf{Many TCP streams can share one circuit:} Onion Routing originally
built a separate circuit for each
application-level request, requiring
multiple public key operations for every request, and also presenting
a threat to anonymity from building so many different circuits; see
application-level request, but this required
multiple public key operations for every request, and also presented
a threat to anonymity from building so many circuits; see
Section~\ref{sec:maintaining-anonymity}. Tor multiplexes multiple TCP
streams along each circuit to improve efficiency and anonymity.
@ -157,7 +157,7 @@ congestion control uses end-to-end acks to maintain anonymity
while allowing nodes at the edges of the network to detect congestion
or flooding and send less data until the congestion subsides.
\textbf{Directory servers:} Earlier Onion Routing design
\textbf{Directory servers:} Earlier Onion Routing designs
planned to flood link-state information through the network---an approach
that can be unreliable and open to partitioning attacks or
deception. Tor takes a simplified view toward distributing link-state
@ -174,9 +174,9 @@ is comfortable with allowing different types of traffic to exit the Tor
network from his node.
\textbf{End-to-end integrity checking:} The original Onion Routing
design did no integrity checking on data. Any OR on the
design did no integrity checking on data. Any node on the
circuit could change the contents of data cells as they passed by---for
example, to alter a connection request on the fly so it would connect
example, to alter a connection request so it would connect
to a different webserver, or to `tag' encrypted traffic and look for
corresponding corrupted traffic at the network edges \cite{minion-design}.
Tor hampers these attacks by checking data integrity before it leaves
@ -200,8 +200,8 @@ to connect with hidden servers; reply onions are no longer required.
Unlike Freedom \cite{freedom2-arch}, Tor only tries to anonymize
TCP streams. It does not require patches (or built-in support) in an
operating system's network stack, which has been valuable to Tor's
TCP streams. Not requiring patches (or built-in support) in an
operating system's network stack has been valuable to Tor's
portability and deployability.
We have implemented most of the above features. Our source code is
@ -429,8 +429,7 @@ deployability, readability, and ease of security analysis. Tor aims to
deploy a simple and stable system that integrates the best well-understood
approaches to protecting anonymity.\\
\noindent{\large\bf Non-goals}\\
\label{subsec:non-goals}
\noindent{\large\bf Non-goals}\label{subsec:non-goals}\\
In favoring simple, deployable designs, we have explicitly deferred
several possible goals, either because they are solved elsewhere, or because
they are not yet solved.
@ -472,8 +471,8 @@ A global passive adversary is the most commonly assumed threat when
analyzing theoretical anonymity designs. But like all practical
low-latency systems, Tor does not protect against such a strong
adversary. Instead, we assume an adversary who can observe some fraction
of network traffic; who can generate, modify, delete, or delay traffic
on the network; who can operate onion routers of its own; and who can
of network traffic; who can generate, modify, delete, or delay
traffic; who can operate onion routers of its own; and who can
compromise some fraction of the onion routers.
In low-latency anonymity systems that use layered encryption, the
@ -623,10 +622,8 @@ to each other through a given exit node. Also, because circuits are built
in the background, OPs can recover from failed circuit creation
without delaying streams and thereby harming user experience.\\
\noindent{\large\bf Constructing a circuit}\\
\noindent{\large\bf Constructing a circuit}\label{subsubsec:constructing-a-circuit}\\
%\subsubsection{Constructing a circuit}
\label{subsubsec:constructing-a-circuit}
%
A user's OP constructs circuits incrementally, negotiating a
symmetric key with each OR on the circuit, one hop at a time. To begin
creating a new circuit, the OP (call her Alice) sends a
@ -1220,8 +1217,8 @@ identity even in the presence of router failure. Bob's service must
not be tied to a single OR, and Bob must be able to tie his service
to new ORs. \textbf{Smear-resistant:}
A social attacker who offers an illegal or disreputable location-hidden
service should not be able to ``frame'' a rendezvous router---that is,
make observers believe that the router created that service.
service should not be able to ``frame'' a rendezvous router by
making observers believe the router created that service.
%slander-resistant? defamation-resistant?
\textbf{Application-transparent:} Although we require users
to run special software to access location-hidden servers, we must not