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

[Paul Syverson <paul.syverson@xxxxxxxxxxxx>]

On Mon, Jun 20, 2016 at 09:19:27PM -0300, juan wrote:
> On Mon, 20 Jun 2016 18:50:10 -0500
> Anthony Papillion <anthony@xxxxxxxxxxxxxxx> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > On 6/20/2016 6:35 PM, juan wrote:
> > > On Mon, 20 Jun 2016 18:07:12 -0500 Anthony Papillion
> > > <anthony@xxxxxxxxxxxxxxx> wrote:
> > > 
> > > I see a lot of people talking about how Tor is pwned by the US 
> > > Government and is insecure 'by design'. I'm assuming that they
> > > know this from a thorough analysis of the source code,
> > > 
> > > 
> > >> No. You don't need to look at the source code to know that 
> > >> 'people'(the US gov't) who can monitor traffic going into the tor
> > >> network and out of it can correlate the traffic and 'deanonymize'
> > >> users.
> > > 
> > >> It should also be obvious, for instance, that if an attacker 
> > >> happens to control the 3 nodes used to build a circuit, he can 
> > >> also 'deanonymize' the user.
> > 
> > True. However, I'm not sure how that's a 'pwned by design' thing
> > (which ascribes malicious intent to the Tor Project). ]
> 
> 
> 	That was an example of stuff you can know about tor without
> 	looking at the source code, not necessarily an example of
> 	malicious intent.
> 
> 	What tor designers knew from day zero is that a 'global passive
> 	adversary' - that is their boss the US gov't - can simply ignore
> 	the routing inside the network and look at the network's edges.


I know I'm feeding the troll, but this is just crap. I invented onion
routing (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. We designed it to separate identification from routing. Nobody
told or requested us to make anything weak or less secure. The three
of us came up with the motivations and idea for onion routing ourselves
and argued for the usefulness of pursuing it further. And we designed
it to be as secure as we could and still functional. And, as many have
argued, usability and performance are security properties for traffic
and routing security systems. Indeed perceived usability and
performance are important, as are network and operator
incentives. David, Michael and I designed the thing to be secure. We
also explained that it needed to carry traffic for others, let others
run part of the infrastructure, and be open source for it to provide
security to any distinct enterprise or general class wanting to use it
to protect their communications. This is part of the security design
regardless of who builds, deploys, or uses it. There were onion
routing networks, e.g., the Freedom network from Zero Knowledge
Systems Inc., that, to the best of my knowledge, had nobody from the
U.S. govt. involved in its deployment or design (other than that it
was an instance of onion routing). It was designed and built by other
people who are wicked smart (smarter than me) and free to create and
build whatever they wanted.  Somehow, this is what they chose to make.

Some people early on when we were first publicizing and announcing
onion routing (e.g. I remember getting such a question at FC'97) asked
us why we weren't building pipenet. Such a network is theoretically
way more secure for some properties in idealized environments, but
even a single user can shut down the network by simply not sending.
That's not secure.  In fact the first onion routing design in 95-96
was not subject to ready observation at the edges.  (although somebody
watching all the links from every onion router to every other could
still learn much).  The default configuration assumed onion routers
running on enclave firewalls with no separate clients. We explored
various padding and similar schemes to complicate observation of
traffic patterns, but I have yet to this day to see one that is adequately
practical to deploy and effective. These were things to try to add to
make the basic design more secure, but we could not find anything to
appreciably help here so did not incorporate it into the Tor design.

If you ever find such a design, describe it. No credible researcher in
any scientific venue has ever claimed to have a system to be more
secure that essentially covers the general use case and userbase of
Tor.  Mix systems, DC nets, buses, PIR, etc. are all very cool. And
subject to some strong environment and other assumptions can be more
secure than Tor against some classes of adversaries.  I have worked on
and designed some of these cool systems myself. But compared to Tor,
each one of these has limitations that, as explored and designed so
far, would restrict to a small (hence more easily targeted) anonymity
set, or has untenable usability or performance problems, or generally
all of the above.  It's funny that there's supposed to be this
intentional built in design weakness, and yet no scientist, engineer,
or mathematician in any country seems to have published a stronger
fundamental design. Hmm, perhaps you mean to imply that we who created
onion routing not only intentionally designed our systems to be weaker
than we could have but that we also have controlled all of the
scientific research and publication on secure system design by every
researcher in every country everywhere on the planet for the last
twenty years.

Onion routing design has evolved. Tor has forward secrecy, which the
two main onion routing designs we introduced before it did not. (Nor
did the Freedom network.) But we did not come up with including
forward secrecy, that was first introduced in Zack Brown's
Cebolla. And we adopted it when we designed Tor. Tor added a directory
system after its first design, then evolved and improved design,
robustness, and trust diffusion of the directory system over time. Tor
added deterministic builds to further reduce the trust in Tor-built
binaries, and work to improve continues through this day.

We have been completely forthcoming about our designs and any
limitations found by ourselves or others, including everything we can
empirically discern about end-to-end correlation risks from ASes,
IXPs, MLATs, etc.  And we have always designed to be as secure as we
practically could. I'm not going to engage further. I do invite those
who might so engage to find any valid technical, empirically justified
stronger design that does not make significant compromises to
performance, cut off large chunks of the existing userbase, etc. I'm
dubious you will find any. But if you do, I'd be happy to pursue its
development.

aloha,
Paul

[snip]
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk