George Kadianakis desnacked@riseup.net writes:
George Kadianakis desnacked@riseup.net 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 )