[tor-talk] Design of next-generation Tor systems

[Paul Syverson]

On Wed, Jun 22, 2016 at 02:09:30PM +0200, carlo von lynX wrote:
> Paul, I thank you for the honor of "proofreading" that page.
> 
> On Wed, Jun 22, 2016 at 07:16:21AM -0400, Paul Syverson wrote:
> > On Tue, Jun 21, 2016 at 07:39:22PM +0200, carlo von lynX wrote:
> > > On Tue, Jun 21, 2016 at 12:48:38PM -0400, Paul Syverson wrote:
> > > > Well there's things like alpha-mixing (better tau-mixing) as that
> > > 
> > > Yes, alpha-mixing would be a great step forward I guess.
> > > Would you say the things I wrote on http://secushare.org/anonymity
> > > regarding not building future work on Tor are accurate?
> > > I wouldn't like to be stating anything stupid in there.
> > 
> > Not sure if accurate is an applicable notion here. I remain hopeful
> > but dubious about anything that just assumes p2p automatically must be
> > better for safety and privacy vs. client/server in the long run.
> 
> So you mean "p2p" in a very broad sense of anything that isn't
> client/server? I avoid using "P2P" as many people still assume
> that means that no Tor-like agnostic relays and back-end systems
> are involved. This would certainly not be the case with secushare,
> we want to learn that usability lesson from Tor.

Everything's a technical term to somebody. Roughly yes I was
contrasting client/server with anything where every entity is both a
participant and part of the routing infrastructure (in that sense the
first published and deployed onion routing system in 1996 was p2p in
that there was no separation of clients and relays (that was changed
in 1997), although we assumed most end users would be connecting to
onion routers rather than running them locally). The reality is
of course more complex with a variety of centralization/decentralization
features to routing, to directory systems, etc. (The 1997-98 design
separated clients from relays, but planned for a flat distribution
of directory information---which was never fully completed.)
You want to be as decentralized as you can, but not more than that. ;>)


> 
> > One reason is discussed in section 2.4 of
> > "Bridging and Fingerprinting: Epistemic Attacks on Route Selection"
> > http://www.freehaven.net/anonbib/cache/danezis-pet2008.pdf
> > For me this remains an open hard area that I continue to focus on.
> 
> Then you should find GNUnet's network size estimation (nse) module
> quite interesting as it empowers cadet (the routing backend that
> Bart describes in the video I linked in the previous mail) to know
> when it is being attacked. So from my point of knowledge this issue
> has been solved, but you may want to dig deeper with the designers
> of this solution: Bart Polot and Christian Grothoff.

I'll try to watch it when I get a chance.

> 
> This also explains why George was so harsh on me when I defended
> the idea of a clean-slate approach to dealing with the broken
> Internet at the STRINT workshop. He simply doesn't know of this
> progress that hasn't only been made on paper - it exists in running
> code. He claimed there were unresolved issues in distributed routing
> whereas to my knowledge this stuff is settled. Only in gnunet, but
> that's enough for me now. Would love if you could check their work
> and possibly come back to us with half a thumbs up. I think this is
> the main reason why GNUnet has been seeing so much scientific and
> financial attention over the years. It's not an amateur tool.

Sorry I couldn't make it to STRINT. As ever, I'm way behind (probably
shouldn't be taking time for this exchange), but I hope to look at
it more closely as soon as I get a chance.

aloha,
Paul