On 27 Oct 2017, at 07:46, Paul Syverson paul.syverson@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