Re: Some legal trouble with TOR in France +

[glymr <glymr_darkmoon@xxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
 

>
> 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!
maybe i am misinformed, but i was under the impression that middleman
mode only stops the circuit from ending at the node, all other 'exit'
nodes also carry middleman traffic
> 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.
yes but you completely missed my point, more exit nodes means less
chance that any one node is picked on by the law.
> My advice would be take advantage of their bandwidth, its free.
what am i paying my isp for if it's not bandwidth? i don't see your point
> 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.
segregating exit and middlemen nodes more distinctly - how is this
going to help... do you want to stand at the top of the tower with
only 100 other people or would you prefer there was 300 with you? I
think you could look to a simple natural phenomenon to give an example
of why we, the small people, need to see this as a 'all for one, one
for all' - herds of grazing animals. Sure, there may be some at the
edges who will get eaten by the lions more, but the size of the
group... what happens if a lion foolishly gets himself into a pocket
at the edge and then finds himself surrounded by a sea of horns?
> 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!
it is not a 'free service' at all, it is a group of people all
agreeing to do something for each other. your idea about segregating
makes it more dangerous for the end points than my idea of making all
nodes endpoints. the worse the ratio between exit nodes and client
only users gets, the more chance there is of exit nodes coming under fire.
> 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!
what if the software does not permit this? i think perhaps you are not
aware of how common it is for people to just install things and not
think about going into the source and modifying it. the sort of people
who would do this are the sort of people we DON'T want using tor, and
this should be something that should be incorporated into the default
configuration. Making it so all nodes are carrying traffic via the
verification mechanisms i described would help eliminate both free
riders and those wishing to exploit. Just like my metaphor of the herd
making pockets and luring the lions in, they can't win if they are
surrounded on all sides by the less powerful but organised and hostile
adversary. Lets face it, if you think tor is a good idea you are
hostile to something. And you are not powerful. It is only through
solidarity that tor even has a hope of surviving, let alone providing
a decent service to its members.
> 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". 
well, the problem here is that what you are suggesting is essentially
saying that you should permit some level of censorship. you are
talking about a slippery slope here. There is nothing stopping any tor
user from running software such as peerguardian with a custom
blocklist. This should not be encouraged, however it should not be
prohibited. what you are talking about doing is adding a blacklisting
system to tor. Do you want to put the freedom to choose at risk? Who
can you trust to implement such a blacklist? Surely it would make more
sense, to, for example in the case of our french friend who has been
frisked by the police, for THEM to implement a blacklist, in
co-operation with those police, not only to show that we are on their
side, but to make it clear that the server operator is not interested
in being complicit. This would be a good thing to encourage server
operators to do. The better we can make our group's relations to law
enforcement, the more likely a) that they won't help push for laws
outlawing the use of tor and the operating of servers, and b) that
they could be educated in the benefits of tor for law enforcement
purposes.
> 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. 
I think perhaps you are suffering from selective attention. In
parallel to this rise in totalitarianism there is also a rise in
libertarian and related 'isms'. Check out boingboing and slashdot
sometime.

And you should also remember that a p2p anonymity system like tor
permits detectives to infiltrate hives of hate groups, pornographers,
and other groups for which there is a real need to be able to do this.
Tor may enable the bad guys to get away with stuff for a little while,
but any bad guy lazy enough to use tor for this purpose is not going
to be hard to pin down by other people also using tor.
> 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?
This subject has already been covered and there is no practical way to
ensure that this system is not exploited by unscrupulous persons,
except perhaps via a system such as hashcash. The big ISP's are
talking up the idea of creating premiums for quality of service,
meaning they can be bought to give selective preference to websites
they like and grind other sites to a halt that they don't agree with.
If there is issues with congestion, then perhaps what is needed is not
to price the small people out, but to enable the small people to
contribute their small contributions. I don't think that tor should
become a 'for the rich only' for those who have got the resources to
run a big server. Tor should be a system of to each according to their
ability. I hate to sound all marxist here but if you didn't absorb the
import of the actions of such great historical figures as ghandi, who
proved that a large group of people with little power, in concert with
each other, can win against small groups with a lot of power. Besides
this, it is going against the intrinsic architecture of the internet
to exclude low bandwidth users from access at the level to which their
connection permits.If this were the default policy then what's the
value in a tiered system of access giving greater preference to server
operators - all users would be server operators. Ideally tor could, at
the user's request, upon installation query the user for how much
bandwidth they have available, and simply give preference *in the
server* to their own outgoing and returning traffic (and incoming in
the case of hidden services).
> 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?
what would help me is if i could run a server that only uses 3kb/s. I
am on a 256/64 connection which frequently ends up shaped to 64k
symmetric for half the month. I'd love to be able to put in what I
have, but it's not a trivial thing to set up selective bandwidth
limiting under linux, which has much greater responsiveness in its
tcp/ip stack than windows, for which shaping software is trivial to
set up. I'd rather to be able to specify 3kb/s on the server
configuration. This is a trivial change and I'm sure I'm not alone in
being a user who has only a limited bandwidth to offer, who needs to
be able to get usable latency while using tor and serving at the same
time. I'd be willing to bet at least 10% of clients are not running
servers simply because the architecture has an arbitrary bandwidth
limit which makes one's own use of the server impractical.

Also I should point out that even if you do shaping on your tor server
to bring its bandwidth usage down, the problem is then if you want to
use the same tor server to run your own traffic you are locked into
that shaping. Either way the pipe is clogged up and unusable for the
smaller bandwidth user.

Sure, I'd love to have 20kb/s symmetric to offer, but unfortunately on
standard ADSL version one, that would usually mean 2/3 of one's
outgoing is congested with tor server traffic which depletes overall
latency for the user themselves to such a degree it is unusable. If
you are lucky enough to have cable or adsl2+ or whatever, lucky you.
Don't go assuming that everyone else has. I think that tor would
benefit a lot from having a swarm of smaller bandwidth servers. It
would somewhat increase directory server traffic but if directory
mirroring were also turned on by default then that load would be shared.
>       
> 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.
Well, this is why I put forward the idea of having a number of
circuits running at the same time that alternately (or even randomly)
are selected for each new connection initiated. If one was browsing a
web page, and there is say 20 objects, and they are randomly
distributed through 5 different length circuits, the delays *are*
diffused stochastically to a degree without sacrificing latency to any
significant degree.
> 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).
Roger has already talked about the question of random packet delays,
and the problem is that it affects latency much more than any
measurable benefit gained.
> 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".
>       
You really should read the tor faq, it explains why all of these
things are not implemented.
> 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.
More middlemen only improves overall network capacity *in the middle*
the exit nodes carry just as much traffic as middlemen nodes. What you
are suggesting would increase congestion at the exit nodes. I think
possibly my own experience of excessive latency (oh and by the way,
when i first started using tor, latency was fine, and then, if I
installed fasterfox or similar pipelining tweaks, the network was
almost as low latency as without tor, this is definitely not the case
anymore) may be related to a lack of adequate growth in bandwidth
capacity of exit nodes. You can't make a pipe carry more by swelling
it in the centre, you will just end up with more turbulence in the
system. The pipe has to be of reasonably uniform width from one end to
the other.

Which is why I am saying, we need to have all installations of tor run
~2kb/s exit node servers by default, and have this as a hard coded
minimum setting, so that no person in the tor network is not
contributing to making the end of the pipe as fat as possible. And
this statistically decreases the chance of any single node coming
under attack from a legal entity. United we stand, divided we fall.
You are promoting more division, this is the road to hell.
> 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).
Assuming they have access to both ends. And if you'd read the tor FAQ
you'd know that tor DOES NOT defend against the well equipped global
adversary. It is not intended to. Hence this line of thought is
irrelevant. If you want an anonymising network which does defend
against this, there is a number of them. However, most of them are
impractical for web browsing.

I think a possible element of the problem may be in the RNG used by
tor to randomise circuit path selection. More entropy in circuit
generation would result in a more even distribution of circuits across
the network. The RNG will give the tor traffic a particular signature
which will decrease the natural entropy of the system and increase the
chances of correlating traffic in and out.

In lieu of a stronger randomness in the server's patterns, perhaps a
change in circuit selection could be made - when servers are not in
use, they flag this to the directories and the circuits will then
select these nodes in order to eliminate their 'empty' flag. This
would reduce the need for wasteful cover traffic, because the network
would agorically disperse traffic more widely. And one should also
note that sometimes this must be happening because of timezones and
the localisation of circuit exit points to the traffic. This sort of
load balancing system would naturally alter latency patterns and
reduce deadspots in server traffic patterns. All by itself doing this
would reduce the overall effectiveness of timing attacks because nodes
would be more evenly sending traffic, the network would breathe as one
rather than have hotspots and deadspots, both of which result in a
reduction of anonymity and an increase in latency.
> 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!
Exactly. And is that a bad thing? The point being that the global
adversary is not in the tor design. The global adversary can do
exactly what you say. However, there is many more adversaries with
much smaller capabilities who are worth defending against. The global
adversary is only confounded by the low latency mix/onion systems such
as what you mention below. Do you have any idea how many 'little cops'
would call on such a 'global timing solution'? It's not going to
happen. The global adversary does not want to be known. The global
adversary does not include tinpot dictator's gestapo gangs, it does
not include marketing organisations, it does not include small
country's intelligence services, and knowing how partisan those people
tend to be, one would be inclined to think that the 'global adversary'
probably does not even exist anyway. Or that there is at least 2 of
them and they don't like each other and thus rule themselves out of
the global adversary category by their intrinsic nature.
> 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"?
>   
and what you are suggesting will exactly cause tor to become that.
>
> 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!]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (MingW32)
 
iD8DBQFEaISkGkOzwaes7JsRA5twAJwInsFdz2Z7xZGDsBdi8QMBHFxYBQCbBVh3
WV5BHMi63vgaQcObeozQX6k=
=lLGo
-----END PGP SIGNATURE-----