diff options
| -rw-r--r-- | doc/TODO | 17 | ||||
| -rw-r--r-- | doc/tor-design.tex | 12 |
2 files changed, 16 insertions, 13 deletions
@@ -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 diff --git a/doc/tor-design.tex b/doc/tor-design.tex index df93baab3..0536aa6f5 100644 --- a/doc/tor-design.tex +++ b/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 |