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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Mike Perry <mikeperry@xxxxxxxxxxxxxx> writes:

> 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
>

Hm. how come the CDF is defined this way?

Specifically, why do we do the following?

  For durations d greater than t days, we take the fraction of that rotation
  period's selection probability and multiply it by t/d and add it to the
  density. In other words:

I'm more familiar with the CDF definition used in commit acf86d7 but changed afterwards.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev