Katharina Kohls katharina.kohls@rub.de writes:
Hi everyone,
we are a team of 4 PHD students in the field of IT security, working at the Ruhr-University Bochum at the chair for systems security and the information security group.
Currently we work on a research project with the goal to leverage the security of Tor against timing attacks by integrating mixes in Tor nodes. The general idea is to differentiate high-latency and low-latency traffic among the network for applying additional delays to the former type of packets. Based on this the success of traffic analysis attacks should be decreased without restricting the low latency assurance of Tor.
We plan to integrate the mix into Tor version 0.2.5.10 and analyze its performance along with the Shadow simulator.
As there are a lot of details to consider, both regarding the technical aspects of the integration as well as practical assumptions, e.g., "how do we get DiffServ-like nodes?", we would be pleased to receive some feedback on the idea and support for the implementation of the mix. Further details on the mix and stuff will sure be provided if needed!
Hello there,
I'm also very interested in this latency-mixing research problem! We are currently trying to address these timing attacks by adding padding to our links. However, defending against these attacks with padding is not easy, and it also puts additional load to the network.
FWIW, there has been some previous work on this topic but nothing that can be used currently in a practical setting. For example, see the paper named "Blending different latency traffic with alpha-mixing" if you haven't already. The biggest challenge with that paper is switching the message-based approach to be stream-based (like Tor is).
Other potential papers are "Stop-and-Go-MIX" by Kesdogan et al. and "Garbled Routing (GR): A generic framework towards unification of anonymous communication systems" by Madani et al. But I haven't looked into them at all...
Here are some basic system-agnostic questions about the project:
a) What are the benefits from mixing low-latency Tor traffic with high-latency traffic? Is it to leverage the already existing network so that we don't need to bootstrap a second trusted anonymizing network?
On this note, do we actually get any additional security properties from mixing low-latency traffic with high-latency traffic? That is, does the low-latency traffic provide cover for the high-latency traffic? What about the opposite?
And for what kind of adversaries do these security properties apply? Will this actually confuse adversaries who run Tor relays themselves? What about network adversaries that monitor the network of Tor relays?
b) Does this increase the hard disk or memory requirement of people running Tor relays? That is in high-latency mode, will Tor relays need to store client's traffic for longer? How does that impact the memory and hard disk requirement of people running Tor relays?
c) Does this impact the legal liability of people running Tor relays?
Looking forward to learn more information about your project :)
Cheers!