Browse Source

some minor tweaks, for the first draft.

svn:r715
Roger Dingledine 22 years ago
parent
commit
30ba3520a2
1 changed files with 7 additions and 6 deletions
  1. 7 6
      doc/tor-design.tex

+ 7 - 6
doc/tor-design.tex

@@ -56,7 +56,7 @@ and addresses many limitations in the original Onion Routing design.
 Tor works in a real-world Internet environment, requires no special
 Tor works in a real-world Internet environment, requires no special
 privileges such as root- or kernel-level access,
 privileges such as root- or kernel-level access,
 requires little synchronization or coordination between nodes, and
 requires little synchronization or coordination between nodes, and
-provides a reasonable tradeoff between anonymity and usability/efficiency.
+provides a reasonable tradeoff between anonymity, usability, and efficiency.
 We include a new practical design for rendezvous points, as well
 We include a new practical design for rendezvous points, as well
 as a big list of open problems.
 as a big list of open problems.
 \end{abstract}
 \end{abstract}
@@ -367,10 +367,10 @@ forward secrecy feasible.
 Circuit-based anonymity designs must choose which protocol layer
 Circuit-based anonymity designs must choose which protocol layer
 to anonymize. They may choose to intercept IP packets directly, and
 to anonymize. They may choose to intercept IP packets directly, and
 relay them whole (stripping the source address) as the contents of
 relay them whole (stripping the source address) as the contents of
-the circuit \cite{tarzan:ccs02,freedom2-arch}.  Alternatively, like
+the circuit \cite{freedom2-arch,tarzan:ccs02}.  Alternatively, like
 Tor, they may accept TCP streams and relay the data in those streams
 Tor, they may accept TCP streams and relay the data in those streams
 along the circuit, ignoring the breakdown of that data into TCP frames
 along the circuit, ignoring the breakdown of that data into TCP frames
-\cite{anonnet,morphmix:fc04}. Finally, they may accept application-level
+\cite{morphmix:fc04,anonnet}. Finally, they may accept application-level
 protocols (such as HTTP) and relay the application requests themselves
 protocols (such as HTTP) and relay the application requests themselves
 along the circuit.  
 along the circuit.  
 This protocol-layer decision represents a compromise between flexibility
 This protocol-layer decision represents a compromise between flexibility
@@ -786,9 +786,9 @@ using TLS. Addressing the insider malleability attack, however, is
 more complex.
 more complex.
 
 
 We could do integrity checking of the relay cells at each hop, either
 We could do integrity checking of the relay cells at each hop, either
-by including hashes or by using a cipher mode like EAX \cite{eax}.
-But we don't want the added message-expansion overhead at each hop, and
-we don't want to leak the path length (or pad to some max path length).
+by including hashes or by using a cipher mode like EAX \cite{eax},
+but we don't want the added message-expansion overhead at each hop, and
+we don't want to leak the path length or pad to some max path length.
 Because we've already accepted that our design is vulnerable to end-to-end
 Because we've already accepted that our design is vulnerable to end-to-end
 timing attacks, we can perform integrity checking only at the edges of
 timing attacks, we can perform integrity checking only at the edges of
 the circuit without introducing any new anonymity attacks. When Alice
 the circuit without introducing any new anonymity attacks. When Alice
@@ -1894,6 +1894,7 @@ issues remaining to be ironed out. In particular:
 %\Section{Acknowledgments}
 %\Section{Acknowledgments}
 % Peter Palfrader for editing
 % Peter Palfrader for editing
 % Bram Cohen for congestion control discussions
 % Bram Cohen for congestion control discussions
+% Adam Back for suggesting telescoping circuits
 
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%