[tor-dev] Support for mix integration research

[George Kadianakis]

Katharina Kohls <katharina.kohls at 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!