Tor-Onion-Router-Review

Name: Samuel Tay
UW Net ID: tays
Paper: Tor: The Second-Generation Onion Router
Authors: Roger Dingledine, Nick Mathewson, Paul Syverson

Paper Review

  • Problem: Broadly speaking, the motivation behind Tor is to allow parties to communicate anonymously on the internet, balancing the tradeoffs between anonymity, usability, and efficiency. There is a first-generation onion router, but it had many design flaws to overcome:
    • a single hostile node could record traffic and then force successive nodes in a circuit to decrypt it
    • every application protocol required a separate application proxy
    • used an expensive padding mechanism without strong evidence of security guarantees
    • required a new circuit for each application, which is not only inefficient, it potentially compromises anonymity
    • there were no integrity checks between nodes on a circuit, so a compromised node could alter data and get the corresponding corrupted traffic at the network edge
  • Approach: Tor sets out to improve on the original onion router with these goals in mind: deployability, usability, flexibility, and simple design. More specifically, it should be inexpensive, not create liabilities for volunteer operators, not require kernel patches to run. Tor improves on the original design flaws (respectively) in the following ways:
    • uses a new telescoping design is used where keys in the circuit can be deleted, and compromised nodes cannot decrypt old traffic
    • uses the standard SOCKS proxy interface, allowing most TCP-based programs to run on Tor without modification
    • does not provide mixing or padding or traffic shaping, at least not until there is evidence that it will be worth it
    • multiplexes TCP streams along a single circuit
    • verifies data integrity along the circuit
  • New ideas: There were obviously a large number of new ideas in the design of Tor, but I'll name a couple. The biggest design decision in my opinion is to build on top of TCP; Tor is now getting a lot for free with this decision, and it is a decision in line with all four of the goals enumerated above. There are a couple of tweaks necessary though, like using Privoxy to avoid the DNS resolution that some applications perform before passing the address to the Tor client. Another new idea is the incremental adding to the SHA-1 digest of all the relay cells created, and including the start of the current digest within the relay cell. This seems similar to the CBC technique we saw in block ciphers.
  • Improvements: I'm simply not well versed in this literature to offer meaningful feedback on improvements. This paper was really dense, but there was a lot to explain, and I'm not sure how they could have done it any better.
  • New directions: The paper mentioned many avenues where the current system can be improved. One of these is scaling the performance; as the network grows, there is a greater chance of building a slow circuit, so latency seems to be steadily increasing with growth. A more permanent network topology solution would be important in the future. Another important area for more research is a cost/benefit analysis of cover traffic, to advise whether or not padding offers legitimate security.