[tor-project] Future of Tor Messenger

[Paul Syverson]

On Thu, Oct 26, 2017 at 12:01:22PM -0400, Nathan Freitas wrote:
> 
> 
> On 10/26/2017 03:47 AM, Georg Koppen wrote:
> >
> > 2) It should support onion service-based chat protocols. Those are a
> > good showcase for metadata-free chat/messaging and we should support
> > that + convince users to switch to them.
> >
> What if took a step back, and actually design and implemented a native
> Tor protocol reliable messaging layer, within the Onion Service
> protocol? There a lot of issues related to presence, offline delivery,
> asynchronous nature of messaging, and encryption that Ricochet ran into
> as part of their work.
> 
> I know there was talk of mix networks on top of Tor, and other
> DHT/blockchain style efforts like BitMessage can work well over Tor, too.
> 
This could maybe dovetail with a suggestion I made long ago to many
Tor developers and researchers, but neither myself nor anybody else
has had enough time/inclination to explore: Tor mostly builds circuits
pre-emptively rather than on-demand.  Tor circuits could be built in a
simple timed-mix style. Every relay holds circuit extension requests
for N seconds (order tens of milliseconds?) and then forwards all
extend cells from the last N seconds.

Questions include: what should N be? How much would this actually
raise the load on a approximately GPA (adversary that is trying to
just hoover up all (non-relay) timing info to associate circuits from
network observations?  Would it in fact raise the load for relevant
adversaries any significant amount at all or is it pointless?  What
fraction of circuits must be on-demand (or on-demand for all hops)?
What are the usability trade-offs of making all/some circuit builds
conform to this? What are the security trade-offs of making all/some
circuit builds conform to this? Is the simple timed-mix the best we
can practically do here?

If messaging errr? cells could conform to the same (or compatible a
la tau-mixing) mixing constraints this could help with anonymity sets
on both sides. Now do lots of research and/or wave hand as needed.

> Ultimately, just moving to HTTP over Onion peer-to-peer messaging,
> doesn't seem like enough, and definitely would expose a lot of issues on
> mobile, where expecting a user to be online all of the time is just not
> a reality.

This might also help with that issue, or maybe make it harder ;>)

aloha,
Paul