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.

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.

...

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.

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 31/05/14 at 02:14pm, Christian Mayer wrote:

On Sat, May 31, 2014 at 1:24 PM, davidroman96 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.