Re: [tor-talk] on the topic of tor's weaknesses

[Chris Wheeler <grintor@xxxxxxxxx>]

On Wed, Feb 29, 2012 at 4:17 PM, grarpamp <grarpamp@xxxxxxxxx> wrote:

> >>> It may take a while for a clientA to use said entry but when
> >>> they do it seems it would be quite easy to time/count correlate
> >>> or munge the HS traffic of clientA. And only require two nodes
> >>> (hs, entry) and no GPA taps to do so.
>
> >> That's why guards were introduced: They will not completely
> >> eliminate the above class of attacks, but at least make it
> >> statistically much less likely; since you will only use 3 out
> >> of 800 or so guard nodes per month.
>
> Though I did not explicitly say so, I implied the current state
> with phrase 'take a while'... that today's client picks an 'entry'
> node and makes it one of its 'guards'.
>
>
> > OK, so taking that all into account, is it more likely that you
> > will be de-anonymized using public services through tor (ie
> > browsing the web) or using hidden services through tor?
>
> I'm guessing equivalent. Unless using encrypted clearnet services.
> For which (and under the above two node example) Sting can no longer
> prove user was involved with certain content on the far side without
> legal process to the host. Due to cost, time and log sync issues,
> Sting would obviously prefer to run their own service, were it legal
> to do so.
>
> Though HS is more hops away, I doubt it would affect timing or byte
> counting all that much.
>
> That was my first thought too, but then what is the point of making hidden
services seven hops away? But regular services three hops away? What does
more hops accomplish in terms of anonymity? And why does it not benefit
regular services in the same way? (if it did all circuits would be made
seven hops I  assume)

>
> >> Can such an entry know when it's being used as an entry by
> >> whatever appears to its left? I think that is what I describe
> >> relies on.
>
> I was just unsure as to whether the entry (guard) could be instrumented
> to, in fact, tell when it is being used as an entry by a client to
> its left. That's the dead giveaway in this two node case afaik.
>
> > The short but incomplete answer is yes.
>
> And Msr. Syverson seems to indicate that it can be.
>
>
> > See "Locating Hidden Servers"
>
> My example is not about 'locating HS', only to locating users
> (clients) with [an entry (guard) and an end node (clearnet exit or
> HS)].
>
>
> If it was the example, by similar construction...
> Unless the last relay before an HS (indeed the HS's EG) could know
> that an HS is the next jump to its right for some subset of the
> traffic to said EG's right, Bust (as opposed to Sting) could not
> pair its deployment of said HS_EG with its own client data pump to
> find the HS.
>
> Again a general picture:
> client <> clientEG <> relayN <> HS_EG/relay <> HS/exit
>
>
> >> Doesn't this mean bad news for users of hidden services,
>
> > The important thing is to understand what security is provided
> > http://freehaven.net/anonbib/
>
> > Entry guards ...
> > If one of them is evil, it will see the entry side of (a large
> > fraction of) your circuits and will be able to associate you with
> > your destination whenever you go to a hostile destination or use
> > a hostile exit. What Lasse and I showed was that you weren't
> > really much worse off from this than when choosing circuits with
> > random entry relays.
>
> Yes, the weakness seems clearer now. Unless there's a way to modify
> the system so that the EG does not know it's an EG for a given
> client stream to its left, it would just be a foregone fact of life
> as part of the unsolved timing/etc attack class.
>
>
> How much of a risk is it? Perhaps only canaries, or a realworld
> test undertaken on this list, will tell.
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk