[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] The Mindware Satalite Network



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Tor2web
=======
And for the Tor2web idea, what about cloaking? changing the output
depending on who connects, if Tor users connect show the Tor hidden
services, if normal users connect show them only the normal web, Google
might also be able to do this filtering when it reads the X_Tor2Web
header. Lets assume Tor users by using the Tor network have agreed
they might see censored and possibly *bad* content now they cannot
complain. But it occurs to me:-
A) You would need a way to tell Tor user requests from normal user
request and Tor intentionally prevents this (you could send a HTTP
header with the request for example X-AllowHidden to access the proxy's
extra functionality).
B) If this was the case you wouldn't need it because Tor users would
already be using Tor to access the internet anyway.
C) The government would always use the X-AllowHidden request header to
see censored content so it wouldn't help with that.

The Mindware Satalite Network
=============================
I am currently working on the Mindware Satellite Network, I don't have a
web site and very few people know of the existence of this project.

Current weaknesses
==================
It occurred to me currently the greatest weakness of Tor, I2P (and many
others although very good designs) are vulnerable to end to end
analysis, which ever way you cut it because of the way real time
protocols work you can detect hosts by whether they are online or not.

The UK government wants to log "Who talks to who, when and for how
long". Usually when Alice and Bob communicate they can see *who* is
communicating but because of encryption cannot read *what* is said, I
reckon we can do better than this, I recon we can deny them who is
talking to who aswell.

What makes a good network
=========================
o Encryption (without question) *hides what is sent*.

o Protocal obfuscation, this actually proves to be quite difficult in
practice and now it appears they are also copying our protocals to
trick and probe our software aswell. *hides protocal /software used*

o Connection redundancy, multiple hops to hide the real source. *hides
who is sending and where data is going*

o Traffic redundancy, cover data to hide when or even if actual data
is sent. *hides when, size and how long or even if data is sent*

o File/resource redundancy and caching, files stored in multiple
places to make it more resistant to churn, attack and failure (note:
DHTs are good, direct and scalable for storing stuff but it appears to
be quite difficult to hide stuff in DHTs, although I will encrypt
files with a key, im working to see if theres a solution to this). The
ideal here is that you are able to "hide" files in the DHT.

o Capacitance, ability of the network to store and time shift data.
An often lacking property, which could potentially destroy end to end
analysis. Like email systems store emails on a server until your
online to collect them, in this case data is stored in the network
itself, this disconnects the time the sender and reciever is online.
With the hypothetical network you can send to a person and make
requests *even* when the other person is offline unlike TCP/UDP which
only works when the host is online, the network stores the messages,
either you send the messages and they float in the network until the
other person comes online, they float in transit (may avoid legal
issues), or you upload files to the network, which the other person
can later download. This is totally different to how normal instant
TCP/UDP networks work and will require totally new and very careful
software design. Files are no longer stored on hosts, which protects
the uploading client. *careful time shifting and DHT use hides when a
user/host is online*.

Current designs
===============
Tor provides Encryption, Protocal obfuscation, onion routing
 but no cover data. And because it uses the normal web and client/host
paradigm has no capacitance, file redundancy and is susceptible to the
client/host correlation attacks mentioned above. But it works great
for what it was designed for as an encrypted tunnel.

I2p has the same problems because it access's the client/host real
time web but I2P does additionally have the ability to use cover data
which is probably not implemented. Its probably only weakness is
clients/host could be correlated by if they are online or not.

Freenet does file redundancy and capacitance but only has weak side
effect onion routing. It occurs to me if Freenet had a HTTP proxy, and
a Tor exit was tunneled straight into Freenet it will solve all
problems at once as long as the junction was not logged/monitored.

Abstract
========
I thought what if you connect to 5 peers, they connect to 5 excetera,
you transmit to all 5 once a second like a beacon, every packet is 2K
encrypted, every send the packets changes, every hop the packet changes,
it always looks different *even* if its the same data (I may also make
an option to wrap it all up to look like HTTP requests so it goes
through firewalls and DPI filters), in effect you are connected to
*everyone* on the network at once, they can see you talking to 5
peers, but they have no idea where the packets are really going,
traffic analysis is *impossible* (peer-peer comms can be monitored and
peers discovered by they know nothing about the real data
transmitted). Packets are encrypted peer to peer, between links, they
are also encrypted end to end. I will need to do prioritization so
communication data is sent first, and file transfers are less
important and queued. This has several advantageous and disadvantages,
low data transmission means it will be slow, it limits the data sent
but it also limits the data lost. It might also be possible to find
out where things are by how long (how many hops) it takes data to come
back, but with all the other data transmitted this may not be a problem.

The web is to much a client-server fixed location system (including
all its old TCP protocals HTTP, email, etc) in my opinion instead of
trying to send an encrypted tunnel through mud into mud, it needs to
be re-written from the ground up as an efficient peer-peer (probably
DHT) system. But at this time I cannot envision how Socks could be
re-written to accommodate such a better system or what the addressing
system would look like.

Where as the normal internet is direct and real time more like a TV
get it instantly, but is easy to track, the Mindware Satellite Network
is more like a mail order catalog send a request now pick it up later.

The Mindware Satellite Network will be more for communication than
file sharing, but the DHT could be used for both.

You will notice that my design does Encryption and cover traffic by
design and Protocal obfuscation and weak onion routing as a side effect.
I will also likely do onion routing by bouncing packets within the
network also.

Note: If we all used 2K random looking packets sent at a regular rate,
we could all be obfuscated just by all looking the same. Only problem
with this method is if they see 2K packets it would be a fair guess it
was peer to peer traffic they where looking at.

Completed work
==============
I have completed my last project Lockbox2.0.0 Alpha which provides
transport independant, node to node encryption, a little like PGP but
uses symetric keys. and is now ready for testing.

I have a bunch of code already for my Satalite system:- encryption,
hashes, compression. And some modules that are nearly finished:-
coolcomm, http module, http programs.

Ive already coded Cool comm which I use as my Base layer, it provides
TCP or UDP peer to peer communication, packet sequencing and automatic
resending, attack protection (ignores everyone until they're
authenticated), authentication, link encryption (does not have diffie
yet or scalable authentication), IP and user blocking lists. I need to
add in a few new connection types, my new 2K encrypted packet object,
and I will make a connection type that first send a http header so it
looks like a http stream. It can do either UDP or TCP so TCP can
easily be turned off in case it turns out TCP is too vulnerable.
Needs finishing.

Not sure whether to have Cool comm running as a service, use DDE to
communicate with it and have a DLL api so other programs can create
and use comm connections directly, only problem is this might allow
attackers to attack the system more directly so not sure if this is a
good idea.

Done some socks code because I will likely do a Socks interface input
but it is not really designed for real time TCP/UDP.

I have working but incomplete http module works but need finishing, I
will need to finish it so I can finish my http client and server to
run over it (the server and client have no script functionality to
reduce attack vectors).

I have working but incomplete http client and server.

Current work
============
Im now working on designing and implementing the routing layer.

I plan on making the routing system accessible so other programs can
use the routing system. I would rather use a simple input like Socks
for programs to use, so normal programs can be easily interfaced with
it, however the system isn't really compatible end-end TCP, an onion
address variation is possible, so is UDP socks or I may use DLL access
instead (again not sure if this is a good idea due to attacks).

I am doing a test Kademilia program to do DHT routing and "object"
storage, I will probably store files, user identity's and domains
names (as in web site start pages) in the final DHT structure. So you
can request files and web pages and send to a users inbox at any time,
no single person is responsible for the DHT storage. DHT routing will
be a fast, efficient and a more or less direct way of getting packets
to destinations and I wont need to know where the destination is to
send, this is the faster method, but with this network structure it
will be "open" requiring at least one seedpeer in a fixed location and
*might* allow the adversary to easily find peers, this will be faster
but may not be most ideal way for hiding network nodes.
In progress.

I also plan on being able to use it in darknet mode, only connecting
to known trusted friends, I am currently working on how to do
efficient packet routing for darknet connections. I will also need the
algorithm to be adaptive if nodes are slow, or malicious nodes
deliberate drop packets such as byzantine attacks. I am currently
working on how this would be done so I can operate with both. It will
likely be something like Kademelia, adaptive darknet routing, and when
no other options available flooding. I thought packets once sent could
float in the network until the destination comes online, packets could
even be "intelligent" in that once sent they find there own way to the
destination.

Planned work
============
Once routing is coded upto a certain standard and I have an API I can
write apps on top of it. Not sure if I will do DHT storage as a
seperate app (maybe a piece by piece upload/downloader like bit
torrent, I wrote one just need to finish it but we'll see) or
integrated the DHT storage into the Satalite code see how it turns out.

I will need to make the system so it will still work for Low-ID users
and run on slow connections (I connect from a tethered mobile and
apparently can only connect out). The good thing about Tor is it still
works for me and in fact probably makes my connection faster and more
reliable most of the time.

I may make an entry socks server and exit node for it but its not
really meant for that and I dont how to do SSL at the moment.

I will also likely use UDP IP spoofing to hide the source of UDP
packets, good for hiding Dos attacks but I thought it could also be
used to hide communications aswell, but I assume this will likely not
be an option in the future when firewalls get better at stopping them.

Im aiming to have written as much of the code myself as possible, its
all written in Delphi2 Im currently using Dave Burtons encryption and
hashing code and Rudy an encryption I wrote. right now I cannot do and
will need these for the final project (mainly cos I write my own code
and I cant figure out how they work or I cant find any code for it on
the net):-
o Diffie-hellman.
o RSA/El gamel public key encryption. (these will be pretty essential)
o I can do Http but not SSL at the moment.
o I dont have land line internet Once I got something that works I
will also need someone on a fixed IP/domain to host a seednode for me
so I can test it and people can boot into my network.

Its just me working on this, not sure if I will finish this project
but I will just keep working on it til I have something that works.

Anyone interested email me.

Comments/Feedback welcome.

~Shadowman.

~TheMindwareGroup
TheMindwareGroup@xxxxxxxxx PGP: 0xf4b6586f
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJS1yhbAAoJEKcLVST0tlhv90kIAKNWLX1lxwf3vhYrLRo0wpU+
duV4s0fA3zJoywLlAeyBPLC5KVD3cqpXlzaw2G+hItklNzYgrBtpPT11Zs86Mjnt
jRExjdhg6w7a/DvOJRJBK4frBYIJTxcp1JtVyloja1f/EGZJ/DdGyuvMekCHWMhY
5pevBXbxPkY4VFNSMJ6cFIK3LgS5ZyFC9RlPXpJhkW2kPd2boR0QH97bri07muz9
CTtgLjaJeTCaJs3QYWsSNDG2kHx5OfdKpwO0Z/jvknNrCJCuA+xLXCHGtAnHho+9
gHxesRiH8B2vqeAVbiLx5lnorVJdYwqbuqHWwjUwb9bE1bk6OVMW3VGqisVjv6g=
=R8f5
-----END PGP SIGNATURE-----
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk