[messaging] Ronion anonymous routing protocol framework
carlo von lynX
lynX at i.know.you.are.psyced.org
Sat Nov 11 13:37:55 PST 2017
On Fri, Nov 03, 2017 at 03:48:23PM +0000, James McGlasan wrote:
> > If GNUnet implemented SOCKS-UDP below its circuit emulation layer
> > (called CADET), it can have that UDP type of semantics. In GNUnet,
> > routing is non-deterministic. It's part of the design to resist
> > sybil attacks, but also protects against phoneme detection.
>
> I.. really need to read up on GNUnet because that sounds odd. :)
There's a talk specifically on this aspect of the architecture.
You can fetch the video from youbroketheinternet.org. It's the
one on the topic of gnunet mesh routing.
> > So GNUnet can do UDP-like, TCP-like but also reliable datagrams
> > which is the right choice to pick for private text messaging etc.
> > We have a pubsub API which provides both a history of messages
> > as a distributed storage facility, so it's a bit like low-level git.
>
> So https://ipfs.io or https://matrix.org for storage and events
> respectively. (Or along similar intent)
Matrix drew inspiration from the PSYC design which is at the
foundation of gnunet's pubsub, actually. IPFS probably came to
the same conclusions, because great minds think alike. ;)
secushare's pubsub however is designed to protect the metadata
of the subscribers, which is unlike the other two projects.
Also, Matrix has no scalability strategy as yet.
> > Someday we may even have a working multicast layer over the
> > mesh network, that would enable to do distributed privacy apps
> > with cloud-like scalability properties: la quadrature du net.
>
> Or just use a simple federated solution like Matrix.
Nope. Federation, too, needs some multicast strategy to scale.
I talked to Matthew on the subject just a couple of weeks ago.
Those ~3000 servers are throwing HTTP packets at each other à
gogo. This works until somebody like Justin Bieber starts
streaming over a pubsub and people from all servers want to
have it. If cloud services can do distribution trees, why
shouldn't distributed and federated systems do the same to
achieve true Faceboogle-like scalability? Of course there are
other reasons not to insist on the federation paradigm, like
servers being utterly unsafe for privacy etc.
See http://about.psyc.eu/Federation on that subject. Or the
paper on the secushare.org homepage, "Scalability and Paranoia
in the Federated Social Web". Things that are common thinking
today, but we're considered highly controversial in 2011.
> > Blocking reliable packets would still be useful, even if they
> > are disguised as UDP. ;) In fact it's an interesting plan to
> > allow for dedicated Tor apps that resist fingerprinting.
>
> I do not see the defence here?
If there is no TCP stream from the app to the SOCKS proxy
or exit node, then there is no traffic to shape.. no? OTOH
this doesn't solve the websurfing problem and dedicated Tor
apps using hidden services do not suffer from the problem
anyhow. So adding UDP as a way to package Tor traffic wouldn't
solve that problem.
> I guess that GNUnet does a handshake for forward secrecy? HIPv2 too.
GNUnet has an Axolotl implementation built-in.
> > Same with gnunet. I think gnunet also offers access to lower layers
> > like neighbors-only gossip, but that's not as interesting. ;)
>
> Is that safe? Sounds like a de-anonymization "feature".
Sure, you can implement non-anonymous applications that way.
GNUnet is a swiss army knife of distributed networking. Of
course you can hurt yourself with it. You might even be able
to blockchain yourself to it. The lower layers are not
intended for average app developers... ;)
> Tor is out there. GNUnet AFAIK is out there. HORNET is not yet.
Oh okay, then keep up the good work!
But.. should the anonymity strategy for GNUnet work out well,
are we sure we will still have a use case for HORNET?
--
E-mail is public! Talk to me in private using encryption:
http://loupsycedyglgamf.onion/LynX/
irc://loupsycedyglgamf.onion:67/lynX
https://psyced.org:34443/LynX/
More information about the Messaging
mailing list