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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev