[tor-project] Future of Tor Messenger

[teor]

On 27 Oct 2017, at 07:46, Paul Syverson <paul.syverson at nrl.navy.mil> wrote:

>> 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?

 Tor's internal event loop runs some callbacks every second. So the
network traffic triggered by these callbacks already implements a
hold-and-release design, with N = 1 second.

In particular, bandwidth token buckets are refilled every second, and
some pending connection events are triggered by these callbacks.

I'm sure someone did a graph or a paper where they demonstrated
the 1-second pattern in Tor's traffic. But I'm not sure how to track it
down.

T