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

[Chris Wheeler <grintor@xxxxxxxxx>]

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?

On Wed, Feb 29, 2012 at 9:14 AM, Ralf-Philipp Weinmann
<ralf@xxxxxxxxxxxxxx>wrote:

>
> On Feb 29, 2012, at 11:17 AM, grarpamp wrote:
>
> >> The main problem, besides the overhead, is that padding doesn't work
> >> if an adversary can do something as trivial as very briefly delaying
> >> It is too easy for an adversary to put a traffic signature on a
> >> circuit in one place, and look for it elsewhere. If he owns, e.g., the
> >> first node and any of the last node, the link to the destination, or
> >> the destination it won't matter what kind of padding is done. There's
> >> lots of published work showing this in various ways. Some already
> >> alluded to in this thread. If nothing else the adversary can just kill
> >> the connection at the first node and see which connection exiting the
> >> network dies.
> >
> > Doesn't this mean bad news for users of hidden services, and to a
> > lesser extent clearnet services (since they're not as 'illegal' and thus
> > maybe lesser hot targets for snagging users). IE:
> >
> > Sting runs a HS and an entry. Thus Sting has full packets, timing,
> > cleartext and logs of anyone that builds: clientA <> entry <---> HS
> >
> > There may even be these additional structures to the left of clientA's
> > entry, for which the role of entry may switch to relay or exit, but for
> > which entry may be still able to discriminate among on its left...
> > clientB
> > clientC <> relay
> > clientD [...] <> relay <> relay [...]
> >
> > 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.
>
> Cheers,
> Ralf
>
> _______________________________________________
> 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