[tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul

[Mike Perry]

Mike Perry:
> I spent some time trying to clean up proposal 247 based on everyone's
> comments, as well as based on my own thoughts. Please have a look if you
> commented on the original proposal, and complain if I've not taken your
> thoughts into account.

I spent yet more time thinking about the new threat model and what the
adversary's expectation for how long they will have after the Sybil
compromise for the third guard completes before the second Guard rotates
away, and I have some awesome results. It turns out that if we make all
node rotation times fully independent, then the point at which the
adversary wins the Sybil attack on layer 3 will be uniformly distributed
with respect to the rotation period of the layer two guards.

With the parameters I specified, this means that when you sum the total
remaining rotation expectations, the adversary will have at least a 19%
probability that they will have less than a day remaining before the
layer two guard changes on them after they win the Sybil, and at least a
32% probability that they will have less than two days before this
happens.

IMO, this is great news, as it shows that we can indeed force the
adversary to risk compromising/coercing nodes that end up having no
utility to them with high probability.

I've added these results to Section 3.2.3 of the proposal in my remote,
and also added the full python script used to generate all tables as
Appendix A.

Here's the new piece of Section 3.2.3:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev#n331

And Appendix A with the table generation script:
https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/247-hs-guard-discovery.txt?h=guard_discovery_dev#n576


I also noted in Section 6 that we may want to consider enforcing
different GeoIP countries for the first and second layer guards. Against
some adversaries, this may increase the expenditure of the attack, but
in others it may simply leak info to the adversary that they can use for
other attacks. Not sure what the right tradeoff is here.


The git commit of the proposal overhaul I posted to the list was
0d676335088bce2954a68b77e2fca4347ec7ae3d. The new head is currently
158d3b22e27f032ed64091d25205fb941b352e3d. The full history is still
preserved in my guard_discovery_dev branch in my remote.

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150914/3e8711bb/attachment-0001.sig>