[messaging] Ronion anonymous routing protocol framework

[James McGlasan]

On Wed, Oct 18, 2017 at 04:39:00PM +0200, carlo von lynX wrote:
> On Fri, Oct 13, 2017 at 12:50:34PM +0200, Jeff Burdges wrote: The
> trick is to make the cover traffic actually useful for end-users..
> ideally by making *all* of their everyday operations a part of the
> cover traffic. That also implies that it makes sense to aim for one
> and only one anonymizing protocol stack that should integrate all
> future and past internet applications, and to make properties like
> latency and depth of anonymization configurable by the applications,
> so that the routing layer can treat a secret conversation differently
> from a bulk video stream. Still, the video stream you watch while you
> chat can be enough to protect your metadata better. GNUnet provides
> file sharing for that purpose. secushare is working to add multicast
> pubsubs and social networking, so you can indeed be watching a stream
> or have chitchat about the weather be going on in the background that
> produces cover for the actual private stuff.

More traffic may help by overloading your adversaries' storage and
processing, but you could be giving them more reference points to work
with.

I do expect that sending all traffic through anonymity networks is the
way forward, but you'll want to be careful with who you trust with what.
If your non-private video streaming service and ISP are colluding, they
may still learn how much data you send privately and at which
approximate times.

On Wed, Oct 18, 2017 at 10:30:02PM +0200, Natanael wrote:
> This could be easily be achieved with something like having a custom
> smart security camera and a NAS locally plus one remote, that all
> coordinates with your other hardware to adjust their bitrate in/out,
> such that ypur total bitrate over the anonymizing network is close to
> constant.

Er. You mean that your constant video recording doesn't do any
compression or ignore disinteresting motion like trees or grass or focus
on cars and people?

If not, then sure replicating excessively redundant information could
work as cover traffic. You and your friends do have "unlimited"
contracts with your ISPs, right? Even so, the ISPs may be unhappy with
the constant relatively high load and may opt to cancel your contracts.

As for data synchronisation I agree that something like IPFS where the
network load is dynamic to *other* people's usage of data you're
mutually interested in would be much more useful. But if those other
people are your adversaries, then they'll get an oracle to mess with
(like any public (or leaked private) interactive hidden service).

On Wed, Oct 18, 2017 at 04:39:00PM +0200, carlo von lynX wrote:
> It's the POSIX socket that most Internet applications expect that is
> by design subjectible to traffic shaping.  If we redesign applications
> to only submit complete packets, we're a step closer.

If we're redesigning applications then we may as well reduce their
networking to capabilities and channels and use efficient protocols that
may evolve, reduce round trips and remove indirections. I.e.
https://capnproto.org/

> One more reason it makes sense to redo apps on top of GNUnet. In
> theory, Tor could offer a packet-oriented API instead of SOCKS5, but
> the safety of it would still suffer from the fact that almost everyone
> uses Tor for HTTP and other TCP stuff. Those protocols are no longer
> fit for future.

What's wrong with SOCKS5? It supports UDP and can queue incomplete
segments. Tor, unlike HORNET, is not suitable for UDP anyway.

Alternatively you may use https://onioncat.org/ for a simple TUN/TAP VPN
over Tor that suffers from Tor's TCP design. But TUN/TAP is much more
expensive than SOCKS5 to implement, for little if any benefit.


James.