On Fri, Jun 12, 2015 at 12:02 PM, Zenaan Harkness <zen@freedbms.net> wrote:
On 6/12/15, Natanael <natanael.l@gmail.com> wrote:
Den 12 jun 2015 10:19 skrev "Zenaan Harkness" <zen@freedbms.net>: Don't do F2F at the lowest network layer. Don't give away sociograms, don't allow timing attacks, and avoid the whole NAT issue.
Sorry, I'm thinking about it differently - like a physical layer.
Let's name it differently: H2H - HUG node to HUG node, which might be overlayed over existing ISP/ centralized net, or might be your own PHY layer (e.g. local street-level wireless).
So, treat this is a PHY layer, where everyone is expected to connect, relatively speaking, to their neighbours.
A F2F (by terminology/meaning) would overlay on top of that.
So like what CJDNS does? https://en.wikipedia.org/wiki/Cjdns It can be compared to a kind of VPN, it creates an IPv6 addressed network in the private fc:: range where the addresses are based on hashes of public keys. The connections can go over the internet, or over meshnets, or over your local LAN, or over a RONJA link (http://ronja.twibright.com/about.php). Then on top of that you could run anonymization like I2P and any other services you might want.
The key that I2P (and Tor for that matter) are missing is fill packets - i.e., the nodes you talk to, promise to backfill their link to you (likewise you to them) any empty packet slots, so that the link maintains a continuous throughput (to hide all real traffic within) - the only thing a state-level adversary (or ISP-level for that matter) can do to analyse things is kill the link entirely (shock testing), which can correlate your traffic with "exit node" traffic, but is much harder to see anything when you are only operating within the dark net.
This is now a very important feature which our anonymizing network software needs in order to provide any meaningful protection.
Local PHY is now also very very useful to increasing network access anonymity. This urgently needs some research study/papers to analyse/ determine the best ways (within eg onion routing context) to maximise advantage of off-net (private PHY layers).
IIRC support for that already exists in I2P, although not yet implemented. The protocol already have support for a number of things like fake filler traffic. Anonymizing routing in local networks can be hard to achieve against timing attacks and other correlation attacks, in particular when assisted by DoS. The problem is that there's typically a limited number of local routes going outwards, poor interconnction and not many long-range links, and node-to-node links reflect human sociograms very well. Having I2P being able to support connections over both types of networks simultaneously would be an advantage.
"Just use..." is very problematic! Please do not be so cavalier with your languaging as those without understanding might mistake your absolutist languaging for relevant fact (as opposed to intuitive sense or reasonable avenue for consideration depending on various factors .... etc etc)!
I'm using "just" as a synonym for "doesn't need novel research, can be implemented by a any experienced programmer". As compared to requiring experts in the field to create new algorithms to make it possible, practical and secure. The difference between "needs time" and "needs brainpower".
I've done a lot of thinking on P2P social networks, I'll share later,
Great. Looking forward to your thoughts. Please don't portend that there are easy conclusive "solutions". There are not!
I'm aware there's a very significant amount of work required, see my comment above. I'm trying to gather the various things I've written about it now. There's a lot to write down. There's a lot of questions about how to make it work without massive overhead. I'm trying to figure out how it should work on each level of abstraction, from data encoding to routing to key management, etc... I want to see a mainly P2P oriented system that allows for server assistance (for distribution of signed data, storage, receiving messages on your behald when you're offline, synchronization / coordination, etc...). And I keep finding edge cases that would be messy with most of the potential solutions I'm considering, which is another reason for why I don't have a complete sketch written down yet.