Guard nodes (was: Re: [or-cvs] r13101)

Roger Dingledine arma at mit.edu
Fri Jan 11 13:21:29 UTC 2008


On Fri, Jan 11, 2008 at 11:57:20AM +0100, Karsten Loesing wrote:
> | +Entry guards seem to defend against all sorts of attacks. Can we work
> | +through all the benefits they provide? Papers like Nikita's CCS 2007
> | +paper make me think their value is not well-understood by the research
> | +community.
> 
> There is one thing with guards that I am still unsure about. Maybe
> somebody can clear that up for me?
> 
> When using guards against the locating attack of hidden services, does
> it make any difference for this attack _how_many_ requests an attacker
> performs to the hidden service? More precise: Would a single request (or
> a very low number) suffice when the attacker is picked as guard node,
> and would an unlimited number of requests not be enough when the
> attacker is not picked as guard node?

That's my claim, yes.

It would be useful to get a better intuition about reasonable situations
where this claim is false.

It's actually a bit more subtle than the above -- Tor clients do use
alternate guard nodes if their preferred guards go down or become
unguardworthy, and the set of guard-worthy nodes in the network does
change over time. So you have to consider the timeframe of the unlimited
number of requests. Perhaps a better way to say it is that the success
of the attack during a given interval doesn't improve with the number
of requests.

Though a correlation attack to identify guards and an active attack to
knock them down would shorten the interval.

And even then it's not quite right, because I bet somebody could show,
for a given statistical attack, that it gets more accurate results with
two requests than one. So maybe I mean that it doesn't improve with
large numbers of requests. :)

But yes, I still make the basic assumption that there exists a statistical
attack that's good enough with just a single request -- even if we
haven't discovered it quite yet.

--Roger



More information about the tor-dev mailing list