Re: [tor-dev] Guard node security: ways forward (An update from the dev meeting)

[George Kadianakis <desnacked@xxxxxxxxxx>]

George Kadianakis <desnacked@xxxxxxxxxx> writes:

> George Kadianakis <desnacked@xxxxxxxxxx> writes:
>
>> A main theme in the recent Tor development meeting was guard node
>> security as discussed in Roger's blog post and in Tariq's et al. paper [0].
>>
>> Over the course of the meeting we discussed various guard-related
>> subjects. Here are some of them:
>>
>> a) Reducing the number of guards to 1 or 2 (#9273).
>>
>> b) Increasing the guard rotation period (to 9 months or so) (#8240).
>>
>> <snip>
>>
>> i) If we restrict the number of guards to 1, what happens to the
>>    unlucky users that pick a slow guard? What's the probability of
>>    being an unlucky user? Should we bump up the bandwidth threshold
>>    for being a guard node? How does that change the diversity of our
>>    guard selection process?
>>
>> <snip>
>>
>> To move forward, we decided that proposals should be written for (a)
>> and (b). We also decided that we should first evaluate whether doing
>> (a) and (b) are good ideas at all, especially with regards to (i).
>>
>
> I started working on evaluating whether reducing the number of guards
> to a single guard will result in horrible performance for users. Also,
> whether increasing the bandwidth threshold required for being a guard
> node will result in a less diverse guard selection process.
>
> You can find the script here: https://git.gitorious.org/guards/guards.git
>                               https://gitorious.org/guards/guards
>

And because release-early-release-often, here is a graph:
https://people.torproject.org/~asn/guards/guard_boxplot_4000.png

The middle boxplot is the probability distribution of our current
guard selection process (e.g. the most likely to be selected guard
node is selected with probability ~0.013). The right boxplot is the
probability distribution we would have if we pruned the guard nodes
that are slower than 4MB/s. We can see that in that case, the most
popular guard node has probability of ~0.15 being selected.

The left boxplot is there for comparison. It's a uniform probability
distribution which is our best case scenario with regards to security:
all guard nodes have an equal chance of being selected. (However it's
unachievable since we are doing bandwidth-based load balancing.)

Here is another graph for a lower cut-off threshold (800 kB/s):
https://people.torproject.org/~asn/guards/guard_boxplot_800.png

(Pushed graphing code to gitorious. I used seaborn, a python
visualization library I've wanted to try for a while:
https://github.com/mwaskom/seaborn )
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev