[tor-dev] Tor Attack Implementations (Master's Thesis: Tor & Mixes)
Florian Rüchel
florian.ruechel.tor at inexplicity.de
Mon Feb 16 10:43:14 UTC 2015
Hi,
> Yes, I'm also wondering whether the anonymity of low-latency Tor would
> increase if we plugged a high-latency network into it, and also the
> opposite. I'm curious on whether one network will act as cover traffic
> for the other, and what kind of adversaries that would fool.
>
> On this topic you might also enjoy the paper "Sleeping dogs lie on a
> bed of onions but wake when mixed" by Paul Syverson:
> https://petsymposium.org/2011/papers/hotpets11-final10Syverson.pdf
I'll take a look, thank you.
>
>> However, for this evaluation/simulation to work, I need to attack my
>> simulation, i.e. become the adversary and measure the effectiveness of
>> my attacks. And for this, I need the actual implementation. So if anyone
>> has access or can direct me to implementations that I can use, I would
>> be glad for your help.
>>
>
> What implementations do you mean?
Well the attacks I find exist in theory, such as traffic confirmation.
However, when I run my simulation of the Tor network, I need to perform
an attack and measure its effectiveness. That is, I want to find out
whether the attacks I have can hurt the anonymity or improve it etc.
I'll use shadow here to simulate the network and want to have some
passive (or even active) attacks that I can run against it. Having an
attack that can simply perform a passive attack on packet dumps would
also be great (this would be very easy to run with shadow).
>
> I'm curious to how you are going to use simulation here. I also
> imagine that actually integrating mixminion with Tor on a level that
> would allow simulation will be non-trivial engineering work.
Yes, that will be a major question. My initial though was running
integrating Mixminion into Tor and in the process adapting it to fit
into Tor. Since the two have many similarities this should actually be
possible.
However, I think this might be way too time-consuming, even if it was
just a very basic implementation. The reason for this is that Tor never
really poses the question of delaying traffic and "just does it" except
for bandwidth limitation.
Thus, I'd need a completely new mechanism that will decide whether to
delay or not and it seems hard to find out the layer at which that
should happen.
So I currently have a slight tendency to just use the mixminion
implementation and run it as a shadow plugin. Then I run both on the
same relay nodes and just ignore the service port in my analysis
(assuming in a real-world implementation it would integrate into Tor).
However, I am not sure whether this might hurt my simulation as it might
turn out that scheduling or some other mechanism might split the two
processes so much that they can still be identified.
>
> In any case, if you have specific Shadow questions, you might want to
> speak with Rob Jansen who develops Shadow and who is also interested
> in hidden services research.
Thank you for the information. I will get in touch with him and see
whether he can help on specific issues that I might encounter using Shadow.
>
>> It would also help me a lot if you can direct me to papers or articles
>> that have shown specific attacks that are known to work on the current
>> network.
>>
>> Finally, I am currently considering using Mixminion as my basis for a
>> mix network as it seems well designed and addresses a lot of known
>> attacks. I currently do not plan to evaluate its security but instead
>> only the effect its usage has on attacks that work on regular Tor users.
>> However, if anyone can propose a better mix network to base my work on,
>> please let me know.
>>
>
> Hm, not sure how exactly the integration will work here, but mixminion
> sounds like a decent choice maybe. It's also developed by Nick, who is
> the Tor developer.
>
Yes that is one of the reasons I chose it: If a potential goal would be
to provide high-latency anonymity within Tor, a design that is already
similar might be beneficial.
More information about the tor-dev
mailing list