Torbutton Documentation - Adversary Capabilities. - fork: Normalization of XHR requests

[Anon Mus]

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 at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
>
>   

***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/