[tor-talk] Question for those who say "Tor is pwned"

[Paul Syverson]

On Mon, Jun 20, 2016 at 11:52:47PM -0300, juan wrote:
> On Mon, 20 Jun 2016 21:25:53 -0400
> Paul Syverson <paul.syverson at nrl.navy.mil> wrote:
> 
> 
> > 
> > I know I'm feeding the troll, but this is just crap. I invented onion
> > routing 
> 
> 	You mean, you invented the name? Or are you claiming you
> 	were the very first who came up with the idea of nesting
> 	encrypted packets, tunnels, what?
> 
> 	A look at the archives of the cypherpunks mailing list, years
> 	94, 95 shows that term "onion" was being used to describe
> 	systems in which remailers used nested, encrypted 'envelopes'...
> 

The idea of layered encryption for anonymous communication was
introduced by David Chaum in the 1980s. AFAICT the term "onion" to
describe mixing was first used in a published work by Gulcu and Tsudik
in early 1996, just before our first onion routing publication a few
months later, but after we had submitted our work. Nihil sub sole
novum, but I believe we invented the design of a network that utilizes
layers of public-key crypto to lay a cryptographic circuit over which
data can be passed bidirectionally. We did get a patent on that, for
whatever that's worth.  In any case, Cecki and Gene used "onion" to
refer to layering around a message in a remailer mix network. We
called it "onion routing" not just because it was layered, but because
the data structure for circuit construction we used in the first few
generations (pre-Tor) was essentially comprised _only_ of layers, like
an onion: no message in the middle. These are two different things. I
describe it in some detail in "A Peel of Onion".  Here's an excerpt:


  Mix networks get their security from the mixing done by their
  component mixes, and may or may not use route unpredictability to
  enhance security. Onion routing networks primarily get their
  security from choosing unpredictable routes through a network, and
  onion routers typically employ no mixing at all. This gets at the
  essence of the two even if it is a bit too quick on both
  sides. Other typical and highly salient distinctions include that
  all existing onion routing network designs are for carrying
  bidirectional low-latency traffic over cryptographic circuits while
  public mixnets are designed for carrying unidirectional high-latency
  traffic in connectionless messages*. Mixes are also usually intended
  to resist an adversary that can observe all traffic everywhere and,
  in some threat models, to actively change traffic. Onion routing
  networks are generally completely broken against an adversary who
  observes both ends of a communication path. Thus, onion routing
  networks are designed to resist a local adversary, one that can only
  see a subset of the network and the traffic on it.

  * An exception is Web MIXes [6], which creates bidirectional
    circuits through mix cascades to carry public web traffic.

> 
> 
> > (with David and Michael) and designed Tor (with Roger and
> > Nick).  We did not design it so that an adversary can just watch the
> > edges. 
> 
> 	But the adversary can do that, and that's the end of your
> 	'anonimity' network.
> 
> 	You even were honest enough to publish a paper admiting what
> 	kind of failure your network is...
> 
> 
> > We designed it to separate identification from routing. Nobody
> > told or requested us to make anything weak or less secure. 
> 
> 	Yeah. Quoting :
> 
> 	“Our motivation here is **not to provide anonymous
> 	communication***, but to separate identification from routing.”
> 

Right. I actually think calling the traffic and routing security Tor
primarily provides "anonymity" is a bit misleading and gets people to
confuse the primary security properties mix networks provide with the
primary security properties that onion routing networks
provide. Cf. more about this in my "Why I'm not an Entropist". But I
accept that this usage is now ingrained and not subject to correcting
even if the theory supports it.

[snip]
> 
> 
> 	I didn't say that. What I say is that you know the design is
> 	limited and flawed and yet you promote it. Saying that there
> 	isn't  anything better is not a valid excuse.

D'accord. I'll agree with you that this design is limited and flawed
in that it is merely the best thing of its type available or that
anyone, anywhere has thought of. And I apologize and make no excuse
for my inability to come up with something better than the secure
system designs of the best minds in this area on the planet---minds
which I readily state totally kick my ass.

> 
> 	Furthermore, tor may be 'optimal' given certain assumptions or
> 	objectives, but that doesn't mean it is the only solution for
> 	all kind of users.

Nobody said it was. Anything for real use always involves many
compromises.  The best we can do is be as explicit as we can about our
choices, the reasons for making them, and the consequences we can
discern. People can then make an informed decision to use our systems
or not. I hope that people continue to analyze Tor to better
understand its properties and its advantages and disadvantages in
different environments and subject to different constraints. I also
hope people continue to explore other designs and would be happy if
someone supplants Tor with a system that provides comparable usability
and performance to Tor with better security.


[snip]
> 
> 	
> 	Have padding, mixing and using fill-traffic all ruled out, why? 

Too briefly: these add huge overhead to the network, break underlying
protocols and/or hurt performance (which has been shown time-and-again
to drive real users of real systems to insecure alternatives, hence
hurting security overall), and none have been shown to provide strong
security against an active adversary for low-latency (i.e., practical)
systems. We published a design in 2010 that essentially turns a
solution against a passive adversary into a solution against an active
adversary. It had some nice theoretical properties, but I don't think
it was practical. These haven't been ruled out. There is ongoing
research, but so far none of it has looked adequately useful in practice.

I think there are some things we maybe could do with mixing and
synchronization to raise the bar at least a little against a _passive_
adversary. I have told many researchers my thoughts about this, but so
far nobody has taken it up that I know of. I would like to look into
it myself, but I already have a many-years backlog of more important
(more likely to make a real difference IMO) research questions to
answer.

Disengaging.

aloha,
Paul

[snip]