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


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

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?

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/