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

While this is a very interesting idea, I wonder if it can actually hold true
with the parameters in the proposal.

Let's say I'm an attacker that just Sybil'ed the third hop. I can trivially
verify my success by doing a traffic confirmation attack. Since I own the third
hop, I now learn the second hop.

I don't know how much time is left before the second hop rotates but I know that
I have to compromise it somehow. So I start preparing my compromise attack which
might take a few hours or days (by writing my exploit, getting a warrant, or
ordering my goons to visit the data center).

As an attacker, before launching my compromise attack (actually launching the
exploit, or entering the data center), I would again run my confirmation attack
to ensure that the second hop hasn't rotated.

If the second hop has rotated in the meanwhile, tough luck. As the attacker, I
will need to rerun my Sybil attack and start from scratch.

However, if the second hop has not rotated, then I can launch my compromise
attack, which usually takes a few minutes to hours to complete. Those minutes or
hours *are* the moments of uncertainty for the attacker, since if the hop
rotates during that time the attacker is screwed (they just compromised
something useless).

Unfortunately, I think that with the values in our proposal, I don't think we
can rely that the second hop will rotate during those crucial minutes/hours.

What I'm trying to say is that only _very_ unlucky or stupid attackers will end
up compromising something useless. What I consider more likely is that if it
takes a while to prepare the attack (like write a whole exploit), then maybe the
second hop rotates during the preparation time, but that won't expose the attacker.

I'm trying to not be negative here, because I actually like the skewed rotation
distribution and everything. I'm just not sure how much we can rely on this. 

=================================================================================

Of course the ideal thing here would be to rotate the second-hop a few hours
after we rotate the third-hop. That would give the attacker a very small window
of compromise.

Unfortunately, since we want the third-hop to rotate fast, this means that the
second-hop would also have to rotate fast. This is unacceptable since that would
make the second hop vulnerable to Sybil attacks which is very bad (since the
attacker would jump directly to the second hop with a Sybil attack).
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev