new perspektive for tor

[Anon Mus]

Michael Schmidt wrote:
> Hello Roger, hello List
>
> I read on another forum, that you are visiting us for the Congress in
Berlin
> http://events.ccc.de/congress/2007/Welcome%21
> and will  talk later with the people from the
> http://www.privacyfoundation.de/
> about a new extension to Tor
> http://wiki.freunde-der-freiheit.de/index.php/TOR-Campaign
>
> Due to data retention logg needs/law in the EU, there will be no
> outproxy and no forwarding-nodes in the EU anymore, if they do not
> logg all traffic. Though there might be a foreign Tor-node in the
> chain, e.g. from India or USA, mostley the german or EU Tor nodes are
> worthless, as you can follow the chain (if they logg).
>
> The Tor Campain has the idea, to bring Tor on routers, but this is
> still then ilegal and needs logging, nor would this use no one and
> third we are not FON.
>
> There has been another idea, to put an TOR-Outproxy into Firefox, so
> that opening the outproxy is a MUST and default. So tit-for-tat, you
> are allowed to surf anonymous, if you allow other to surf through
your
> IP/Tor-Firefox too.
>
> Third I thought about this idea:
>
> Developing a second communication layer (second virtual network) for
> tor, which is compatible with the peers, but running on a
> friend-to-friend private network, which is encrypted and would allow
> to support the network not by Outproxies in Germany/EU, but with a
lot
> of Forwarding-Nodes in germany on this virtual network.
>
> E.G. Dive in in the USA, 4 Hops in Germany, Back one Hop to India and
> then surfing to the website. the 4 Forwarding hops in Germany CAN
take
> place, if they are in a closed virtual private network, where the
> entry and last hop of this virtual network layer is outside Germany
> (so the 1-before- last hop of the tor-chain).
>
> See the graphic here:
> http://img248.imageshack.us/img248/5762/torretroshareqa5.png
>
> Alice is located in the USA, but it would be no problem to locate
> Alice in Germany.
> You only need to be sure, that you make the option "outproxy" in a
> country, which is outside the data-retention-law, e.g. india.
>
> In the countries, where you have data-retention-law and need to logg,
> there it is as well forbidden to use an forwarding-tor-node (except
> you logg, but then worthless).
>
> But: if you make the german forwarding nodes in a second layer (I
call
> it plugin-nodes), then you have encrypted tunnels to friends, this
> means you start the virtual forwarding network over an India node,
> SWITCH TO F2F-SECURE NETWORK - tiggle it a few hops in germany, and
> the last one is forwarding again to india and SO SWITCH BACK FROM
> F2F-SECURE NETWORK and make one hop to the website.
>
> This means the TIGGLING HOPS IN GERMANY can be 5 , 7, 10 hops... and
> no one knows the IPs of the Tor-Pugins, because it is not relaying on
> peers, but trusted friends which maintain a private secure channel
> network,
>
> Ok, it is a kind of web of trust with this messenger,
>
> http://sourceforge.net/forum/forum.php?forum_id=618174
>
> so got one participant by police, you can locally /physically see
> which other friends he has, either from the PGP-Certificate, but as
> well by the ISP connections. But: This is the same with Tor, and here
> you have peers, so it is even more insecure, if there is logging by
> the ISP. (and the isp loggs, yes, but in the F2F network you have
> streams, so you can deny to run a Tor-Plugin !!! no one can prove !,
> that´s the trick !!)
>
> It is a kind of hopping in F2F: the messenger F2F is the basis, and
we
> only need that for website-data-traffic beeing able to hop the
> friends, with the condition: the Outproxy is needed outside the law
of
> data retention. (if the law is all over the world to logg any
> outproxy, then tor is definately dead). See the powerpoint here for
> hopping friends.
> http://www.turtle4privacy.org/documents/en_what_is_turtle_f2f.ppt
>
> Then the Picture above shows plugin-nodes into a f2f messenger, which
> normally are only forwarding (over the secure f2f channel only to
> friends with tor-plugin, not to peers with tor). then you have
friends
> in countries without this data retention law, these friend then CAN
> LET THE TOR-PLUGIN connect to the normal TOR node network (forwarding
> or outproxing..)
>
> This would be a good way, the EU and Germany can support the network
> by forwarding nodes (the middle chain) - if the Outproxy nodes are in
> countries which have not this law.
>
> Maybe you can discuss this,
> As well I thought about TOR over i2p.net, but that would make TOR
> nodes in germany possible for forwarding, but them outproxing would
> relay the traffic to the one and only I2p-Surf-outproxy in Sweden,
> which could not handle this.
>
> So I think a F2F network allows to hop and forward the chain in the
> middle of the tor-chain for germany, if a friend or a friend of the
> friend is outside the law zone with as well such a
> f2f-messenger-tor-pugin, which then is directing to the normal tor
> network (or direct outproxying ).
>
> Think of this as a pinnball game, in the top you have these tiggle
the
> ball contacts, before they run down again on your flippers. This
> Tiggling and forwarding can take place in germany, if there is a
> second layer for plugins, which can both (outside the EU) or only
one:
> using the secure F2F layer.
>
> FOURTH IDEA:
>
> See this thread:
>
http://sourceforge.net/forum/forum.php?thread_id=1819729&forum_id=618174
>
> Two c++ classes are written to build an web-surf-proxy in the IP of a
> friend, so implemented into this messenger, you just pic up your
> friend from the messenger list, and start surfing with his IP adress.
> So if the friend is in India, any german can surf through his IP,
even
> groups can surf trough the IP of a friend node, installed on any
> server in india, so several friends on the messenger can use one
buddy
> in india,
>
> This way a chinese guy can surf with a friend-IP in the USA to the
BBC
> news site in England UK.
>
> The code is ready to implement, not done from the project by priority
> due to other basic things, but if one is able to implement it, please
> adress to the project team.
> Hope you see this direct proxying as an alternative and can support
> it, the more surf options, the better. So why not surfing through a
> buddy from the buddylist. Then you do not need an anonymizing chain,
> it is just a method to break firewalls protecting the BBC-news for
> chinese users e.g.
>
> Thanks for the interest, and I hope you get some ideas, though to
> quick written text with not correcting all the mistakes. Regards
Mike.
>
> http://img248.imageshack.us/img248/5762/torretroshareqa5.png
>
>
>   
There are 2 additions to this suggestion I should make (they have been 
suggested before no doubt)

1. Traffic Multiplexing. - Client chops packets up randomly and sends 
fragments via numerous routers to a single "hidden service - outside of

Germany" which reconstitutes the packet from all the routes it was sent

to it along, it then chops it up again (randomly) and sends it via 
numerous routers to the target exit node who reconstitute and does the 
business then reverses the process sending the traffic back. In the 
process the middle routers can multiplex the packet fragments from 
numerous sources into whole packets and so will defeat packet
monitoring 
by a global snoop. All of this can be achieved in an (albeit slightly 
modified) onion fashion.

The attraction of this is that clients will get a great deal of extra 
cover if they also become some sort of Tor router thus adding to the 
size of the Tor network. The client's own traffic being multiplexed 
itself! Now the traffic logger will have no possibility to trace a 
packet stream, timing attacks will fail and no one except the client, 
"hidden service in the middle" and the exit node will ever have the 
whole packet (encrypted or not)! d there is no need for the exoit node 
to have access to clients system ID, the "hidden service in the middle"

can proxy for that.

2. Random Tor routing length - to further seize up any packet based 
mapping by the  global snoop, require Tor traffic to move in random 
length circuits (say between 3 - 6 hops - user settable to a minimum of

3 and a maximum of 7or8 would be nice -  an algorithm to ensure a good 
spread without massive increases in traffic would work well).

Both will slow Tor down a little but the result would be packet 
monitoring would be totally useless, even if you have the logs.    





      ____________________________________________________________________________________
Be a better sports nut!  Let your teams follow you 
with Yahoo Mobile. Try it now.  http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ