Re: Some legal trouble with TOR in France +

[crackedactor@xxxxxxxxxxx]

glymr wrote...

1.
>"I personally have stopped trying to use tor because latency has gone far
>beyond my patience. Something needs to be done about tor's bandwidth
>capability. Of course more bandwidth will mean more users...

2.
> and I have
>said this before and I will say it again - Tor needs to run a minimal
>server capability by default, even a 2kb/s, and no more of this
>middleman only business, the more people doing it, the less isolated
>those who get targeted become, and the greater the pool of possible
>'suspects'...


3.
>I think it's a classic example of an opportunity for 'free riders' that
>tor not being a pure p2p application that there is this bandwidth
>problem, and this also makes those who have the intestinal fortitude to
>run servers, especially exit nodes, have a much greater risk of getting
>caught up in a legal problem. IMHO, the concept of middlemen nodes and
>client-only connections needs to be done away with because it decreases
>the 'lost in the crowd' solidarity that really SHOULD be a part of the
>tor philosophy, I think there is a little too much pandering to the
>lowest common denominator.


4.
>If those bad guys, eg terrorists and child pornographers, were not able
>to use the tor network for risk of being caught in a legal problem
>originating from an entirely different bad guy that would be better for
>everyone. This would be simple to implement too, as a peer verification.
>Before a node would accept traffic from another node, it would look up
>the node's ip address in the directory, if it didn't find it, it would
>refuse to carry traffic for it, and as a second test, it would attempt
>to push a test packet through the node in a double-back loop (onion
>route via a second known good node back to itself)... And to add more to
>this, a peer-bandwidth reporting system, where nodes measure the traffic
>they send through each different node, and report this back to the
>servers (as opposed to self-reporting) and this would further make the
>process of using tor without exposing yourself to some other bad guy's
>traffic.


5.
>Now I know that this would probably rattle a lot of people but we must
>be serious about this. If you really care about your legal safety and
>the anonymity of the network, you should be contributing, even if only
>enough to permit half of a 56k dialup connection (ie 1-2kb/s) to relay
>traffic. The random hop length is also a very good idea,

6.
>I don't think
>that random delays are neccessary, this is naturally introduced by
>random hop lengths.

7.
>Having the nodes construct a big number of circuit
>paths would be good too, every http object request, for example, could
>be sent out on a different circuit which may or may not be a different
>length, it would certainly make the global adversary much more work to
>try and track the endpoints. Another side point is that this reinforces
>the value of such detachable persisting stream protocols as silc, which
>allow the user to close the stream and reestablish it transparently.




>my 2c"


By the numbers..

1.

I have no problems with latency of Tor for obtaining a web page via IE.
But for Firefox, all I ever get is time-outs, even though I increased the available time-out settings to huge values.
Maybe the problem is the brower you are using. I use privoxy with IE and it seems to do a good job.

Ocassionally, I have a slow link (usually on Fridays +22:00GMT etc), when this happens I often change my IE settings to stop downloading images. That works a treat.

As a middleman server I see huge periods (3-4 hours) of NO traffic (even when I'm not running other stuff), so overall there is little "COVER" for me in running this service.   

More on this later...

2.

Well most people using Tor, aint running a server at ALL. They are just the users, running Tor in Client only mode. 

And the "middlemen" are gonna be needed, if you want to have more hops!

Not everyone can run an EXIT server, but there are lots who can run a middleman server, not everyone can find, nor afford an ISP willing to allow them to run an EXIt server.
But most ISP's "dont grieve about what the eye dont see" so running a "middleman" is no problem.

My advice would be take advantage of their bandwidth, its free. 
And get EXIT servers to only run limited "middleman" capability and stop trying to make them "Do-It-All".

If "EXIT servers" gave, at maximum, 20% of currently "spare" bandwidth to "middleman" traffic, and get in as many middlemen as possible, then that might speed the whole Tor system up.
 
3.

The only "Free-Riders" would appear to be ordinary Tor users who dont run in server mode, but thats why we have Tor!
Yes, Tor is a FREE SERVICE! 
 
What about a system of service classes - different classes of service for different classes of Tor user/service provider!

More on that later... 
    
4.

No... they'll just run Tor in client mode only!

Child porn is a different matter, it threatens the Tor network!
It is best handled easier by a url/site/ip block list on the EXIT nodes. to protect itself Torland should put a site uo tp create this block list and Tor EXIt servers use it if they wish.
Eg <16+,<18+,<21+ lists, then EXIT servers put on the lists approprate tio theuir region.
Also the client side of Tor could be have a user configuration to NOT "obtain" pages/images/etc from URL/IP on these list according ot the confugration they set. This protects them from that.
Police could even add to this list and child protection/free speech groups could double check to stop speech "censorship".  

As for terrorists, potentially we are ALL terrorists, and one mans terrorist is another mans freedom fighter.

Is "free speech" terrorism ? Currently, under UK regulations it is! Supporting (sympathising/empathising) by the written or spoken word the actions of "terrorists" is enough! 

How long will it be before any form of "anti-establishment" speech will be classified as supportive of terrorist activities. not long, I'll bet.

Orwell's "Big Brother" is here in 2006 and Orwell's "1984" is a reality of today. The TV show "Big Brother" is a sign of the "confidence" they feel in their ability, there they flaunt and "dry run" it right before your very eyes.  

5.

Ok, I've said enough on the subject of the Tor FREE SERVICE.

Glad you liked the idea of random hops and hope you understand we need middlemen servers for that.

As a suggestion, and in way of appreciation to Tor EXIT/Server nodes, what about a 2 or 3 tier quality of service provision?

EXIT servers (according to their tested EXIT bandwidth) get First Class, ENTRY & Middleman servers get Second Class and Non-server Clients ONLY get Third class.

Its an incentive!

Would that help you glymr?
       
6.

No, random delays are not inserted by the extra hops (though some timing differences are inserted - mainly predictable/repetitive tho') but it does increase the complexity of an attack solution and so the certainty of its successful computation.

What really gives the whole stategy the EDGE, is the random delays, in individual packets.
Just think of your http page request reply from the EXIT node as a train.
Back it comes from the EXIT node with its carriages (packets) right behind it. You can time them arriving and leaving each station (hode or hop).

Sure each station might have delays (latency), but this is often non-transient and so predictable. Thats the whole point of a "timing" attack.   
And by allowing the individual setting Client side setting you can always opt out (or reduce you delays to only a little) of this "random delay" if you want!     
But "random" packet delay screws up the GLOBAL timing attack completely and with the random circuit lengths (no. of hops) I doubt anyone, even a GLOBAL adversary, would stand a cat in hells chance of a successful attack.
Unless, the nodes have little or no traffic on them. Which as I said in 1. happens now!
Hopefully, more hops means more traffic.
If not, then there is only one other item needed to complete the perfect defence against the "Global Adversary".
That is "Random Cover Traffic". Just for where traffic is low.
Sent all the way along (on a request and respond basis) the circuits.

The only other thing that I can think of is random cutting up of packets and reforming, particulary if separate (request) streams can be mixed into the same packets. Then the Tor system would look more like a "gunge" liquid flow from TOR node to TOR node, instead of "separated stream packets". Just an idea! Sure the same principle of "onion" encryption could be used but on top of this a node to node stream mixing and a futher layer encryption to encapsulate the "flow".
       

7.
      
ummm...

With "Random Packet Delay" and "Random Cover Traffic" then the attacker has to move to a probablistic solution!

At that point the "Random Hop Length Circuit" really begins to bite.

Only a FULL search of the solution space will return the best solution because sometimes they dont know for certain (as any global adversary can today) where the packets went from one node to the next.

And you ALL know how "probability" dont crry much weight in courts today. They want proof!  

This is a n**h problem solution! (where n = total number of [middleman] nodes and h = the maximum no. of hops!

For Tor where n = 500 and h = 6 then the solution is nearly 2*10**16 in size. A significant solution only solvable on supercomputers. 

Addition of even MORE "middlemen" would greatly improve the situation for us, so come ion lets have MORE middlemen.

For Tor where n = 10000 and h = 6 then the solution is 10**24 in size. This would be impossible to solve, even with teraflop/s supercomputers, in as reasonable amount of time (years). 

But today the solution is trivial, just follow the returning train one station at a time to the next station on the return journey right back to the CLIENT 3 hops back from the "EXIT" station!

Today there is no huge space search! Today given only the EXIT node and the ENTRY node data we can solve on a PII in under 5 minutes (& probably under 5 seconds).

They dont even have to consider the possiblity that there might be more than 3 hops from the EXIt node back to the Client.

What we rely on today, is one of the nodes being in a country which will not divulge their network logs. But as I've already shown this is really irrelevant against an adversary with the logs of the IN and OUT nodes! 

Maybe that is why the someone recently reckoned the German authorities have a "matter of fact" attitude about TOR EXIT nodes.

Coz once they know that if its a Tor EXIT node they just call up the "Global Timing Solution" program and presto... we have the culprit!

If you really wanna know what a slow "P2P" anonymous network client is like, have a go at I2P. Have you heard of the phrase "paint drying"? 
   
 

Dave Page asked,

"I could definitely offer 10k, perhaps 15k. I think it'd be useful if Tor
would be happy with 5k, since that will make running Tor servers on the
increasingly popular (in the UK) 128kbit upstreams feasible."


Most of the traffic I see consumes about 5-10KB/sec thats less than half the stated minimum.
I reckon your contribution would be useful, if not least to TOR's anonymity as a whole.

What is needed in Tor is (and Im not sure how much is already done) is some sort throughput estimation (perhaps this could be done with the "Random Cover Traffic" - each node only has to attach its timings into the packets to get a good picture of the current latencies of each node in the circuit) by the client of the nodes and then choice of approriate nodes in its circuit.

    
Thats free.

[Hey Cat, break the cycle - eat chicken!] 
-- 
Message sent with Supanet E-mail

Signup to supanet at https://signup.supanet.com/cgi-bin/signup?_origin=sigwebmail