update TODO, patch design paper

svn:r963

doc/TODO

@@ -1,4 +1,3 @@
-improve how it behaves when i remove a line from the approved-routers files
 
 Legend:
 SPEC!!  - Not specified
@@ -15,14 +14,16 @@ ARMA    - arma claims
 For 0.0.2pre17:
         o Put a H(K | handshake) into the onionskin response
         o Make cells 512 bytes
-        - Reduce streamid footprint from 7 bytes to 2 bytes
-          - Check for collisions in streamid (now possible with
+        o Reduce streamid footprint from 7 bytes to 2 bytes
+          X Check for collisions in streamid (now possible with
             just 2 bytes), and back up & replace with padding if so
-        - Use the 4 reserved bytes in each cell header to keep 1/5
+        o Use the 4 reserved bytes in each cell header to keep 1/5
           of a sha1 of the ongoing relay payload (move into stream header)
         o Move length into the stream header too
         o Make length 2 bytes
-        - Spec the stream_id stuff. Clarify that nobody on the backward
+        D increase DH key length
+        D increase RSA key length
+        D Spec the stream_id stuff. Clarify that nobody on the backward
           stream should look at stream_id.
 
 Cell:
@@ -62,6 +63,7 @@ For 0.0.2pre14:
                   middle nodes.
 
 Short-term:
+        - improve how it behaves when i remove a line from the approved-routers files
         - Make tls connections tls_close intentionally
         o Rename ACI to circID
         . integrate rep_ok functions, see what breaks
@@ -123,11 +125,12 @@ On-going
         . Go through log messages, reduce confusing error messages.
         . make the logs include more info (fd, etc)
         . Unit tests
+        . Update the spec so it matches the code
 
 Mid-term:
         - Rotate tls-level connections -- make new ones, expire old ones.
           So we get actual key rotation, not just symmetric key rotation
-        - Are there anonymity issues with sequential streamIDs? Sequential
+        o Are there anonymity issues with sequential streamIDs? Sequential
           circIDs? Eg an attacker can learn how many there have been.
           The fix is to initialize them randomly rather than at 1.
         - Look at having smallcells and largecells
@@ -161,7 +164,7 @@ NICK            . Handle half-open connections
                 o Design
                 - Spec
                 - Implement
-        - Tests
+        . Tests
                 o Testing harness/infrastructure
                 D System tests (how?)
                 - Performance tests, so we know when we've improved

doc/tor-design.tex

@@ -160,7 +160,7 @@ or flooding and send less data until the congestion subsides.
 
 \textbf{Directory servers:} The earlier Onion Routing design
 planned to flood link-state information through the network---an approach
-that can be unreliable and open to partitioning attacks.
+that can be unreliable and complex. % open to partitioning attacks.
 Tor takes a simplified view toward distributing such
 information. Certain more trusted nodes act as \emph{directory
 servers}: they provide signed directories that describe known
@@ -703,8 +703,8 @@ occurred, and the cell is discarded.)
 
 OPs treat incoming relay cells similarly: they iteratively unwrap the
 relay header and payload with the session keys shared with each
-OR on the circuit, from the closest to farthest.  (Because we use a
-stream cipher, encryption operations may be inverted in any order.)
+OR on the circuit, from the closest to farthest. % (Because we use a
+%stream cipher, encryption operations may be inverted in any order.)
 If at any stage the OP recognizes the streamID, the cell must have
 originated at the OR whose encryption has just been removed.
 
@@ -842,7 +842,7 @@ first four bytes of the current digest.  Each also keeps a SHA-1
 digest of data received, to verify that the received hashes are correct.
 
 To be sure of removing or modifying a cell, the attacker must be able
-to either deduce the current digest state (which depends on all
+to deduce the current digest state (which depends on all
 traffic between Alice and Bob, starting with their negotiated key).
 Attacks on SHA-1 where the adversary can incrementally add to a hash
 to produce a new valid hash don't work, because all hashes are
@@ -1188,7 +1188,7 @@ must build circuits and use them to anonymously test router reliability
 Using directory servers is simpler and more flexible than flooding.
 Flooding is expensive, and complicates the analysis when we
 start experimenting with non-clique network topologies. Signed
-directories are less expensive, because they can be cached by other
+directories can be cached by other
 onion routers.
 Thus directory servers are not a performance
 bottleneck when we have many users, and do not aid traffic analysis by
@@ -1656,7 +1656,7 @@ confirmation will immediately and automatically defeat a low-latency
 anonymity system. Even high-latency anonymity systems can be
 vulnerable to end-to-end traffic confirmation, if the traffic volumes
 are high enough, and if users' habits are sufficiently distinct
-\cite{limits-open,statistical-disclosure}. Can anything be done to
+\cite{statistical-disclosure,limits-open}. Can anything be done to
 make low-latency systems resist these attacks as well as high-latency
 systems? Tor already makes some effort to conceal the starts and ends of
 streams by wrapping long-range control commands in identical-looking