[metrics-team] Report on protecting Tor from Sybil attacks
phw at nymity.ch
Sat Feb 27 21:07:30 UTC 2016
Thanks for your thoughts, nusenu.
On Sat, Feb 27, 2016 at 03:31:42PM +0000, nusenu wrote:
> > 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
Right, I will add a clarifying sentence.
> Another question that comes up is: How do you tell benign Sybils apart
> from non-benign Sybils?
That's not always possible. Most of the malicious ones we caught were
tampering with exit traffic or with the DHT.
> > 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
> I was also not able to find them at
> or in
> (i.e. there is no 2014-08 folder/file)
Yes, we only provide an attack summary. I will rephrase that.
> > Table 2: The Sybil groups
> Cross-checking with some OrNetRadar  emails:
> Jan 2016 cloudvps family size: 61 vs 97
> (if we ignore non-running relays, up=0, then the counts match)
The numbers in Table 2 are the total number of fingerprints we have
> Does sybilhunter take relays without valid flags into account?
> Onionoo does (and should continue to do so) - which could explain the
Sybilhunter generally considers relays without the valid flag.
> What is your "observation window size" for churn based detection?
> In Figure 10 you mention 1h, 12h and 24h "smoothing window sizes".
The window size in the published data is one, so it can easily be
> cloudvps (125 relays, 2015-12-30) - not in list?
There are many groups that we did not include in the table because we
are limited by space.
> > Figure 4
> Are there plans to add such graphs to metrics?
> or is that part of
Yes, I would like to add the churn rate and the uptime visualisation to
metrics. I currently don't have much time to work on this, so there's
no ETA. I didn't file this ticket.
> > 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"
We changed that. The phrasing in the paper is correct.
> > [...] 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
That's indeed a mistake, thanks for pointing it out. The correct number
is nine. Tonga is a bridge authority, not a directory authority.
More information about the metrics-team