I want to present an idea to improve anonymity and privacy on the intrernet that me and my companion are building. How it works: To improve anonymity, the diferent hosts are connected with groups of multiple hosts that comunicate each other spoofing the source ip and broadcasting the messages that have to be sent to some host. With this method the reciever don't know who want to download X file and if the NSA or FBI get the logs of the reciever they can not use it for trace the origin. The sender don't know who have X file because they have sent a broadcast request for download a file and will recieve the file with spoofed ip, is 99% anonnymous, the only problem is that the ISP can always know if you are using this program. For the cryptography we use SHA-3 (keccak) for hashing, AES, ECDSA and the better algorithms and methods that we know (we are only amateur cryptologists). With cryptography is easy to protect data against the ISP MitM but it's more dificult to send private messages to a single person. For this reason the topology for the network is of isolated groups with their own private key for the members, obviously a group can be public. Of course a group of 2 people is useless because there are not anonymity xD Bigger groups, more entropy, more anonimity. For the "POC" we are using UDP. UDP only can send small packets of ~64kb, therefore, it can be used for a chat but is too slow to download big files. We have sacrified speed to increase anonymity and privacity. We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works! And that is the idea :) , what do you think? PD:Sorry for my english :P
On 31/05/14 at 01:24pm, davidroman96 wrote:
And that is the idea :) , what do you think?
PD:Sorry for my english :P
Apart from english (I'm using aspell as spellchecker, and it works well.. give it a try), do you have read some literature about this field? Are you on the "state of art" ? What are the differences (and why they are better) among your proposal and, say, DC nets or onion nets ? Thank you
You seem to forget timing attacks completely. This sounds like a restart of the TOR project, but without learning lessons from the TOR project.
On 31/05/14 13:42, danimoth wrote:
And that is the idea :) , what do you think?
PD:Sorry for my english :P Apart from english (I'm using aspell as spellchecker, and it works well.. give it a try), do you have read some literature about this field? Are you on the "state of art" ? What are the differences (and why
On 31/05/14 at 01:24pm, davidroman96 wrote: they are better) among your proposal and, say, DC nets or onion nets ?
Thank you
In the Onion network if the first node is fake, they can get your real ip and catch you, in our network all the source ips are fake (spoofed ips), therefore, if they read the logs they don't know who are you really. onion nets obfuscate your ip with proxy, our project delete your real ip and put a one fake. For this reason all communications are with groups and broadcastings.
hosts that comunicate each other spoofing the source ip
will recieve the file with spoofed ip
in our network all the source ips are fake (spoofed ips)
our project delete your real ip and put a one fake.
This may work in your test lan, but on the real internet, packets with bogus src ip's are generally dropped at the customer interface with rpf and other filters, thus breaking your app.
With this method the reciever don't know who want to download X file and if the NSA or FBI get the logs of the reciever they can not use it for trace the origin.
They will become a receiver and trace them back with netflow.
On 31/05/14 17:54, grarpamp wrote:
hosts that comunicate each other spoofing the source ip will recieve the file with spoofed ip in our network all the source ips are fake (spoofed ips) our project delete your real ip and put a one fake. This may work in your test lan, but on the real internet, packets with bogus src ip's are generally dropped at the customer interface with rpf and other filters, thus breaking your app.
With this method the reciever don't know who want to download X file and if the NSA or FBI get the logs of the reciever they can not use it for trace the origin. They will become a receiver and trace them back with netflow.
We know that the sources ips generally are dropped, this is the only problem that we have. But if multiple hosts can use the same ip how the connection can be traced? Only the ISP have the information, the receiver don't know anything a part from the content of the packet.
On Sat, 2014-05-31 at 19:15 +0200, davidroman96 wrote:
On 31/05/14 17:54, grarpamp wrote:
hosts that comunicate each other spoofing the source ip will recieve the file with spoofed ip in our network all the source ips are fake (spoofed ips) our project delete your real ip and put a one fake. This may work in your test lan, but on the real internet, packets with bogus src ip's are generally dropped at the customer interface with rpf and other filters, thus breaking your app.
With this method the reciever don't know who want to download X file and if the NSA or FBI get the logs of the reciever they can not use it for trace the origin. They will become a receiver and trace them back with netflow.
We know that the sources ips generally are dropped, this is the only problem that we have. But if multiple hosts can use the same ip how the connection can be traced? Only the ISP have the information, the receiver don't know anything a part from the content of the packet.
Except that packets will be dropped if they look like they're coming from somewhere they shouldn't: https://en.wikipedia.org/wiki/BCP_38 I would, instead of taking the IP spoofing approach, I would have designed the network with the intention of making it appear that a message could be destined for anyone using public key encryption: if A sends a message to B and B can't decrypt it, it wasn't intended for B, so it gets forwarded to other nodes in the network. Traffic analysis is defeated by layering encryption and constantly sending lots of flak: nonsense messages. If you can maintain the throughput at each node as a constant and make one message look different between entering and exiting a node, I believe it would be theoretically impossible to conduct traffic analysis.
what do you think?
Try expanding the idea to a more formal or longer paper with diagrams.
But if multiple hosts can use the same ip how the connection can be traced? Only the ISP have the information, the receiver don't know anything a part from the content of the packet.
Your suggested adversaries can and will run a 'receiver' to get the contents. They are in the 'receiver's ISP and use netflow or other means to trace back the spoofed packets. It's basic network administration.
message could be destined for anyone using public key encryption: if A sends a message to B and B can't decrypt it, it wasn't intended for B, so it gets forwarded to other nodes in the network.
Unless sender A is aware that final delivery was made to Z (or knows the net is reliable), broadcast models will fail to deliver reliably due to being clogged out of the links or aging. To be reliable, broadcast needs control, knowledge, or maybe unavailably large time/space.
Traffic analysis is defeated by layering encryption and constantly sending lots of flak: nonsense messages. If you can maintain the throughput at each node as a constant and make one message look different between entering and exiting a node, I believe it would be theoretically impossible to conduct traffic analysis.
Packet sizes must also be the same throughout the network. And must be detectably immutable at each layer of link and onion-ish path encapsulation, or be dropped. ~1500 mtu minus layers = data capacity. Related... redundancy to the destination could serve as chaff. Yet with underlying privacy, unclear on the need for redundancy (as chaff), unless the redundancy solves full path (or node) reliability issues. Otherwise 'control as chaff' seems more valuable.
On Sat, May 31, 2014 at 01:24:14PM +0200, davidroman96 wrote:
I want to present an idea to improve anonymity and privacy on the intrernet that me and my companion are building.
[...]
We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works!
No, in proof of concept it moves data around. You've given us a back-of-the-napkin sketch without enough information to actually model your system. You can say all kinds of nice things about a data transmission system with various crypto primitives mixed in, but you cannot truthfully say that your system advances the state of either anonymity or privacy unless you can show that the properties you wish to preserve hold throughout the system. *Then* you can say it works in theory. In order to say that it works in practice, there's a whole different set of hurdles. </curmudgeon> --mlp
El 31/05/14 13:57, Meredith L. Patterson escribió:
On Sat, May 31, 2014 at 01:24:14PM +0200, davidroman96 wrote:
I want to present an idea to improve anonymity and privacy on the intrernet that me and my companion are building. [...]
We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works! No, in proof of concept it moves data around. You've given us a back-of-the-napkin sketch without enough information to actually model your system. You can say all kinds of nice things about a data transmission system with various crypto primitives mixed in, but you cannot truthfully say that your system advances the state of either anonymity or privacy unless you can show that the properties you wish to preserve hold throughout the system. *Then* you can say it works in theory.
In order to say that it works in practice, there's a whole different set of hurdles.
</curmudgeon>
--mlp
We wanted to listen the opinions before build a formal model. Our project still starts and we don't know how it will finish but I think that can be interesting.
On Sat, May 31, 2014 at 1:24 PM, davidroman96 <davidroman96@gmail.com> wrote:
For the "POC" we are using UDP. UDP only can send small packets of ~64kb, therefore, it can be used for a chat but is too slow to download big files. We have sacrified speed to increase anonymity and privacity. We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works!
"tested"? Any source code to show?
On 31/05/14 at 02:14pm, Christian Mayer wrote:
On Sat, May 31, 2014 at 1:24 PM, davidroman96 <davidroman96@gmail.com> wrote:
For the "POC" we are using UDP. UDP only can send small packets of ~64kb, therefore, it can be used for a chat but is too slow to download big files. We have sacrified speed to increase anonymity and privacity. We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works!
"tested"? Any source code to show?
I missed that part completely. What does it mean that "UDP is too slow because of packet size of 64 kb" ? To me, it seems an ugly claim. Do you know that ethernet will fragment it in pieces of ~1 kb, and the most common segment size on the Internet is around 500 bytes ? TCP maximum segment size is also 16 bit long.. Your proposal requires a modification of the most transport protocols of the internet, and IPv6 with jumbo frames? Really, take a look onto DC nets, they are quite old but far superior to your proposal (but they have some drawbacks). I see too much approximation, I'm sorry.
El 31/05/14 14:43, danimoth escribió:
On 31/05/14 at 02:14pm, Christian Mayer wrote:
On Sat, May 31, 2014 at 1:24 PM, davidroman96 <davidroman96@gmail.com> wrote:
For the "POC" we are using UDP. UDP only can send small packets of ~64kb, therefore, it can be used for a chat but is too slow to download big files. We have sacrified speed to increase anonymity and privacity. We have "tested" it in a small group of people and for this reason we can not say if it works or not, but in theory it works!
"tested"? Any source code to show? I missed that part completely. What does it mean that "UDP is too slow because of packet size of 64 kb" ? To me, it seems an ugly claim. Do you know that ethernet will fragment it in pieces of ~1 kb, and the most common segment size on the Internet is around 500 bytes ? TCP maximum segment size is also 16 bit long.. Your proposal requires a modification of the most transport protocols of the internet, and IPv6 with jumbo frames?
Really, take a look onto DC nets, they are quite old but far superior to your proposal (but they have some drawbacks).
I see too much approximation, I'm sorry.
I say that UDP is slow not because of the size, because of send a file of 8GB with broadcast packets that maybe take some minutes to reach the destination. I know that the are a lot of problems... PD: Thank you for the responses
participants (7)
-
Christian Mayer -
danimoth -
davidroman96 -
grarpamp -
John Preston -
Lodewijk andré de la porte -
Meredith L. Patterson