[metrics-team] Report on protecting Tor from Sybil attacks

[nusenu]

nice!


> Sybils per se do not have to be malicious; a relay operator could 
> simply have forgotten to configure her relays as a relay family. 
> Such Sybils are no threat to the Tor network

That implies to some extend that the MyFamily setting is useless as it
makes no difference if set or not.

I would argue that even non-actively malicious "undeclared families" are
a risk to tor clients because opsec failures will likely affect all
relays in that undeclared family. If the operator's client gets
compromised the odds are high that all relays fall with it. Operators of
non properly configured families are therefore a more valuable target
for malicious entities than an operator with a proper MyFamily
configuration.

this reasoning is supported to some extend on page 9:
> In fact, we cannot rule out that the adversary was upstream,  or gained control
> over these relays.

We do no only have to trust people not acting in bad fate but also, that
they do not fall for an attack themselves - which is a significantly
different matter.

Another question that comes up is: How do you tell benign Sybils apart
from non-benign Sybils?

> Our modules ran [...] and discovered 251 malicious exit relays, shown
> in Appendix A

Appendix A and table 4 do not "show" any relay information (like
fingerprints)

I was also not able to find them at
https://nymity.ch/sybilhunting/
or in
https://nymity.ch/sybilhunting/sybil-groups.tar.bz2
(i.e. there is no 2014-08 folder/file)


> Table 2: The Sybil groups 

Cross-checking with some OrNetRadar [1] emails:

Jan 2016 cloudvps family size: 61 vs 97
http://article.gmane.org/gmane.network.onion-routing.ornetradar/854
(if we ignore non-running relays, up=0, then the counts match)

Does sybilhunter take relays without valid flags into account?
Onionoo does (and should continue to do so) - which could explain the
difference.

What is your "observation window size" for churn based detection?
In Figure 10 you mention 1h, 12h and 24h "smoothing window sizes".

cloudvps (125 relays, 2015-12-30) - not in list?
http://article.gmane.org/gmane.network.onion-routing.ornetradar/816


> Figure 4

Are there plans to add such graphs to metrics?
https://trac.torproject.org/projects/tor/ticket/15594

or is that part of
https://lists.torproject.org/pipermail/metrics-team/2016-January/000060.html


> Once all sequences are sorted, we color adjacent sequences in red if
> their uptime sequence is identical.

from Dec 2015:
"Right, I don't use perfect matching, so we can account for some noise"

https://lists.torproject.org/pipermail/tor-dev/2015-December/010042.html



> [...] by eight distributed directory authorities [...]
> [...] the nine directory authorities vote [...]
> The majority of directory authorities, i.e., five out of eight

8... 9...
how about 10 ;)
moria1, gabelmoo, dannenberg, tor26, urras, maatuska, dizum, Faravahar,
Tonga, longclaw



[1] https://lists.riseup.net/www/info/ornetradar

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20160227/3b25c3ce/attachment.sig>