mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-10 13:13:44 +01:00
skeletal design paper
svn:r367
This commit is contained in:
parent
f8d7cff6ea
commit
a7a580977c
196
doc/tor-design.tex
Normal file
196
doc/tor-design.tex
Normal file
@ -0,0 +1,196 @@
|
||||
|
||||
\documentclass[times,10pt,twocolumn]{article}
|
||||
\usepackage{latex8}
|
||||
\usepackage{times}
|
||||
\usepackage{url}
|
||||
\usepackage{graphics}
|
||||
\usepackage{amsmath}
|
||||
|
||||
\pagestyle{empty}
|
||||
|
||||
\renewcommand\url{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url}
|
||||
\newcommand\emailaddr{\begingroup \def\UrlLeft{<}\def\UrlRight{>}\urlstyle{tt}\Url}
|
||||
|
||||
% If an URL ends up with '%'s in it, that's because the line *in the .bib/.tex
|
||||
% file* is too long, so break it there (it doesn't matter if the next line is
|
||||
% indented with spaces). -DH
|
||||
|
||||
%\newif\ifpdf
|
||||
%\ifx\pdfoutput\undefined
|
||||
% \pdffalse
|
||||
%\else
|
||||
% \pdfoutput=1
|
||||
% \pdftrue
|
||||
%\fi
|
||||
|
||||
\begin{document}
|
||||
|
||||
%% Use dvipdfm instead. --DH
|
||||
%\ifpdf
|
||||
% \pdfcompresslevel=9
|
||||
% \pdfpagewidth=\the\paperwidth
|
||||
% \pdfpageheight=\the\paperheight
|
||||
%\fi
|
||||
|
||||
\title{Tor: Design of a Next-generation Onion Router}
|
||||
|
||||
\author{Roger Dingledine \\ The Free Haven Project \\ arma@freehaven.net \and
|
||||
Nick Mathewson \\ The Free Haven Project \\ nickm@freehaven.net \and
|
||||
Paul Syverson \\ Naval Research Lab \\ syverson@itd.nrl.navy.mil}
|
||||
|
||||
\maketitle
|
||||
\thispagestyle{empty}
|
||||
|
||||
\begin{abstract}
|
||||
We present Tor, a connection-based anonymous communication system based
|
||||
on onion routing.
|
||||
Tor works in a real-world Internet environment,
|
||||
requires little synchronization or coordination between nodes, and
|
||||
protects against known anonymity-breaking attacks as well
|
||||
as or better than other systems with similar design parameters.
|
||||
\end{abstract}
|
||||
|
||||
%\begin{center}
|
||||
%\textbf{Keywords:} anonymity, peer-to-peer, remailer, nymserver, reply block
|
||||
%\end{center}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{Overview}
|
||||
\label{sec:intro}
|
||||
|
||||
Onion routing is a TCP-based anonymous communication system
|
||||
The onion routing project published a number of papers several years
|
||||
ago \cite{x,y,z}, but because the only implementation was a fragile
|
||||
proof-of-concept that ran on a single machine, many critical design issues
|
||||
were not considered or addressed. Here we describe Tor, a protocol for
|
||||
asynchronous, loosely federated onion routers that provides the following
|
||||
improvements over the old onion routing design:
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Congestion control:} Foo
|
||||
|
||||
\item \textbf{No mixing or traffic shaping:}
|
||||
|
||||
\item \textbf{Applications talk to the onion proxy via socks:}
|
||||
|
||||
\item \textbf{Directory servers:}
|
||||
|
||||
\item \textbf{Forward security:}
|
||||
|
||||
\item \textbf{Many applications can share one circuit:}
|
||||
|
||||
\item \textbf{End-to-end integrity checking:}
|
||||
|
||||
\item \textbf{Robustness to node failure:} router twins
|
||||
|
||||
\item \textbf{Exit policies:}
|
||||
Tor provides a consistent mechanism for each node to specify and
|
||||
advertise an exit policy.
|
||||
|
||||
\item \textbf{Rendezvous points:}
|
||||
location-protected servers
|
||||
|
||||
\end{itemize}
|
||||
|
||||
We review mixes and mix-nets in Section \ref{sec:background},
|
||||
describe our goals and assumptions in Section \ref{sec:assumptions},
|
||||
and then address the above list of improvements in Sections
|
||||
\ref{sec:design}-\ref{sec:nymservers}. We then summarize how our design
|
||||
stands up to known attacks, and conclude with a list of open problems.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{Threat model and background}
|
||||
\label{sec:background}
|
||||
|
||||
anonymizer
|
||||
pipenet
|
||||
freedom
|
||||
onion routing
|
||||
isdn-mixes
|
||||
crowds
|
||||
real-time mixes, web mixes
|
||||
anonnet (marc rennhard's stuff)
|
||||
morphmix
|
||||
P5
|
||||
gnunet
|
||||
rewebbers
|
||||
tarzan
|
||||
herbivore
|
||||
|
||||
\SubSection{Known attacks against low-latency anonymity systems}
|
||||
|
||||
|
||||
|
||||
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
|
||||
of the attacks and our defenses against them in Section \ref{sec:attacks}.
|
||||
|
||||
\Section{Design goals and assumptions}
|
||||
\label{sec:assumptions}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{The Tor Design}
|
||||
\label{sec:design}
|
||||
|
||||
|
||||
\Section{Other design decisions}
|
||||
|
||||
\SubSection{Exit policies and abuse}
|
||||
\label{subsec:exitpolicies}
|
||||
|
||||
\SubSection{Directory Servers}
|
||||
\label{subsec:dir-servers}
|
||||
|
||||
\Section{Rendezvous points: pseudonyms with responder anonymity}
|
||||
\label{sec:rendezvous}
|
||||
|
||||
\Section{Maintaining anonymity sets}
|
||||
\label{sec:maintaining-anonymity}
|
||||
|
||||
\SubSection{Using a circuit many times}
|
||||
\label{subsec:many-messages}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{Attacks and Defenses}
|
||||
\label{sec:attacks}
|
||||
|
||||
Below we summarize a variety of attacks and how well our design withstands
|
||||
them.
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{Future Directions and Open Problems}
|
||||
\label{sec:conclusion}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\Section{Acknowledgments}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\bibliographystyle{latex8}
|
||||
\bibliography{minion-design}
|
||||
|
||||
\end{document}
|
||||
|
||||
% Style guide:
|
||||
% U.S. spelling
|
||||
% avoid contractions (it's, can't, etc.)
|
||||
% 'mix', 'mixes' (as noun)
|
||||
% 'mix-net'
|
||||
% 'mix', 'mixing' (as verb)
|
||||
% 'Mixminion Project'
|
||||
% 'Mixminion' (meaning the protocol suite or the network)
|
||||
% 'Mixmaster' (meaning the protocol suite or the network)
|
||||
% 'middleman' [Not with a hyphen; the hyphen has been optional
|
||||
% since Middle English.]
|
||||
% 'nymserver'
|
||||
% 'Cypherpunk', 'Cypherpunks', 'Cypherpunk remailer'
|
||||
%
|
||||
% 'Whenever you are tempted to write 'Very', write 'Damn' instead, so
|
||||
% your editor will take it out for you.' -- Misquoted from Mark Twain
|
||||
|
Loading…
Reference in New Issue
Block a user