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

[Tariq Elahi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey George,
Glad to see that guard questions are still being asked.
Some thoughts from your plots.

On 24-Feb-14 9:06 PM, George Kadianakis wrote:
> 
> 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.

A question: How much of the total BW was dropped due to the condition
"guard BW must be greater than 4MB"?

- From a security perspective:
While the top guard did get ~0.015 rather than ~0.013, a change of
+~15% on its original probability of being selected, all the other
guards also got a boost. Thinking about it from a steady state: the
increase in chance (+X%) of being picked is due to the fact that they
_do_ now own +X% more bw than before. They haven't gained something
for nothing. So it seems that dropping bandwidth is not harmful if we
forget about the previous state of the network.

Have I got something wrong in this analysis?

Other thoughts: raising the bar on guards leads to good things(tm).
Not amazing(R), though. One, you get less relays that shouldn't really
be guards slowing things down. Two, an adversary can't take control of
a large number of slow relays (like in a botnet of residential
computers) and run guards that in aggregate give them a lot of
bandwidth (which is how guards are selected, i.e. the adversary gets
one of their bots picked because the chance of one of the bots being
picked in aggregate is high) and at the same time slow down service
for a client who actually will use that bad guard with low bandwidth.
The trick, as you have pointed out, is in picking this cut-off point.
But dropping the bottom most doesn't really hurts things, apart form
the feeling of leaving bandwidth on the table.

Looking forward to seeing progress. :)

Cheers,
Tariq
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJTDCFnAAoJEJaS+qOeq5CkB1QH/2Elbogxn4jY54fi69UxT4lp
hgRBSrYJwVH41SqmIe+pZgKk0R6SvLMK3UQiEMKGqH/ah25uR18KBV+g/t57gXzm
hI/u/tXophbF6fIk+EnA1PdYgyFsF3fPoxieT4HHvsui/y/Xadt49reRBrE209I0
/uMT1yIWDv24Hr03HQz2vFX8EXM/L0veBnbBjH9BvHWa2+bEKnYd/RdY/+4BLHY6
jfi6/eqOSgvRGgazSuepH3sNUJ2s9OtvOVtp33I8WX90QVW+UWPwXeozNi3m9PSg
p8CYHiL4VhBcM3ttj39U15s4Z1jKW/c1bUnb+AkGxdCVEqTPT3aONGegv2EbTvo=
=GsDo
-----END PGP SIGNATURE-----