diff options
author | Nick Mathewson <nickm@torproject.org> | 2003-11-03 21:05:33 +0000 |
---|---|---|
committer | Nick Mathewson <nickm@torproject.org> | 2003-11-03 21:05:33 +0000 |
commit | 2dcafa8527b6f817de6178a2c40922000e9e1a96 (patch) | |
tree | ae12906fddd7c55e5b9aaa16ba7929bb964aa494 | |
parent | 3a0d3b7c893712a1361fcb94e1dec7c061848793 (diff) | |
download | tor-2dcafa8527b6f817de6178a2c40922000e9e1a96.tar tor-2dcafa8527b6f817de6178a2c40922000e9e1a96.tar.gz |
Edits to recent edits.
svn:r739
-rw-r--r-- | doc/tor-design.tex | 22 |
1 files changed, 11 insertions, 11 deletions
diff --git a/doc/tor-design.tex b/doc/tor-design.tex index 88e2eb6f1..a73256bd0 100644 --- a/doc/tor-design.tex +++ b/doc/tor-design.tex @@ -401,12 +401,10 @@ it is a security requirement \cite{econymics,back01}. Tor should therefore not require modifying applications; should not introduce prohibitive delays; and should require the user to make as few configuration decisions -as possible. -Platform support is also an important factor in both usability and -deployability. Tor currently runs on linux, Windows, and assorted -BSDs (including MacOS X). -%XXX Did I forget any? We need to say this somewhere. It's a big deal -%XXX so should it instead be at the beginning and/or end? -PS +as possible. Finally, Tor should be easily implemented on all commonly used +platforms; we cannot require users to change their operating system in order +to be anonymous. (The current Tor implementation runs on Windows and +assorted Unix-clones including Linux, FreeBSD, and MacOS X.) \textbf{Flexibility:} The protocol must be flexible and well-specified, so that it can serve as a test-bed for future research in low-latency @@ -633,7 +631,7 @@ seven bytes, plus one byte for the command. %XXXX Discuss what happens with circIDs here. -A User's OP constructs a circuit incrementally, negotiating a +A user's OP constructs a circuit 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 \emph{create} cell to the first node in her chosen path. This cell's @@ -1344,15 +1342,16 @@ design withstands them. end-to-end timing correlations. An attacker watching patterns of traffic at the initiator and the responder will be able to confirm the correspondence with high probability. The - greatest protection currently against such confirmation is to hide + greatest protection currently available against such confirmation is to hide the connection between the onion proxy and the first Tor node, - either because it is local or behind a firewall. This approach + by running the onion proxy locally or + behind a firewall. This approach requires an observer to separate traffic originating at the onion - router from traffic passes through it; but because we do not mix + router from traffic passing through it; but because we do not mix or pad, this does not provide much defense. \item \emph{End-to-end Size correlation.} Simple packet counting - without timing consideration will also be effective in confirming + without timing correlation will also be effective in confirming endpoints of a stream. However, even without padding, we have some limited protection: the leaky pipe topology means different numbers of packets may enter one end of a circuit than exit at the other. @@ -1841,6 +1840,7 @@ issues remaining to be ironed out. In particular: cached at the ORs to avoid high loads on the directory servers. % XXX this is a design paper, not an implementation paper. the design % says that they're already cached at the ORs. Agree/disagree? +% XXX Agree. -NM \item \emph{Implementing location-hidden servers:} While Section~\ref{sec:rendezvous} describes a design for rendezvous points and location-hidden servers, these feature has not yet been |