[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: Torbutton Documentation - Adversary Capabilities. - fork: Normalization of XHR requests
Paul Syverson wrote:
On Tue, Jul 13, 2010 at 05:30:27PM +0100, Anon Mus wrote:
Paul Syverson wrote:
Tor doesn't do any batching or delaying. This is just another way you
could be identified by timing attacks. Tor provides no resistance to
timing attacks, and so far there are no countermeasures that have
been identified as working against a passive, much less active, adversary
without imposing unacceptably high overhead or limitations.
Since Tor's inception (must be getting ion for 10 years now) it has been
getting faster year after year, this is due to network speed and bandwidth
increases, which have been about a 200 fold (e.g. speeds of 100+Kbps max
2003 to 20+Mbps today).
OK, there have been some increases in web page byte size but it not more
than 10 fold.
That means a real speed increase of at least 10 fold. So perhaps Tor
developers should start putting in some "timing attack" protection. It
seems to me that the time is right. What is holding them back? Are they
afraid of global big brother complaining they cannot identify users at
will? Anonymous should mean anonymous, no?
Even assuming your description of the evolution of Tor network
communication processing is correct, I don't understand what increase
in network speed (throughput?) or bandwidth have to do with making it
more feasible to protect against timing attacks.
Obvious really, I quote you (from above) "without imposing unacceptably
high overhead" - if the speeds & bandwidth (you might like to read up on
this subject) are up 10 fold then the latency is down. Pages load fast
now, so there IS room for some extra "ovehead" now. Didn't you figure
that out?
There are lots of methods that can be employed to resist against timing
attacks... and there's definite resistance to implementing them, even
though its obvious on first principles that they DO work and that other
anonymity systems have/do use them. The obvious one are..
1. Bundling/Multiplexing individual streams into mixed streams,
individual streams can even be split by over multiple routes then
reconstituted. (means streams cannot reliably be followed). - adds entropy.
2. Caching by exit nodes (means streams cannot always be tracked from
the external site) - adds entropy.
3. Variable (3-n random pattern) node size paths (means timing attack
adversaries cannot EASILY predict route start and end) - adds entropy.
4. Random variable packet delay/sequence position transmission - adds
entropy.
5. Addition of "chaff" traffic - adds entropy.
INCREASED ENTROPY is the KEY.
More entropy, the less certainty of the adversary of finding a timing
attack solution.
At the moment Tor has the appearance of an ordered NETWORK/WEB/GRAPH -
low entropy (predictable system), the above would make it look more like
an amorphous CLOUD - high entropy (unpredictable system).
As for the rest you say below - as you are stuck with ever faster
networks you'd better get used to it and put some ENTROPY into the Tor
system.
Faster networks
should just make timing attacks more effective, and we know that we
were already unable to do anything useful when such attacks were less
effective.
People should continue to work on this hard research problem. (I
myself have a paper on it to be presented in the Privacy Enhancing
Technologies Symposium next week, "Preventing Active Timing Attacks in
Low-Latency Anonymous Communication ".) But as the blog post I pointed
at noted, nobody has yet made a suggestion that clearly improves the
situation (even in theory) and would clearly be feasible and practical
to deploy on the Tor network as it stands.
THE ABOVE 1..5 ALL THEORETICALLY INCREASE ENTROPY, which ACTUALLY makes
it more difficult to make timing attacks on Tor - as you need MORE and
MORE data on the MORE Tor nodes and users and the computational solution
grows by the power of the number of nodes/users that have to be included
in the timing attack solution. - why would you argue otherwise?
And just as there is no such thing as a secure system---only systems
secure against a given adversary conducting a given class of attack
provided that the implementation, deployment and environment satisfy
certain assumptions, so to there is no such thing as an anonymous
system. In that sense, the answer is no, "anonymous" should not mean
anonymous, or rather it depends what _you_ mean by anonymous and a
whole bunch of other things that must be stated.
Well if is your attitude, then why have Tor in the first place? Seems to
me you need to pull over and let those who are interested in making Tor
secure against Timing Attacks take the road. That way Tor will at least
be on the road to more being more secure than it is now.
Why get up in the morning?
HTH,
Paul
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk in the body. http://archives.seul.org/or/talk/