[tor-project] "Capture the onion" + Tor village at next Defcon

[Roger Dingledine]

tl;dr I would like to (A) design a "capture the onion" contest to get
people trying to break the next-gen onion service protocol and code,
and run the contest at the next Defcon; (B) craft a funding proposal to
help us do A well; and (C) run a Tor village at the next Defcon too.

Part A:

We have this new onion service design, and one of its features is that we
hope it is now impossible to discover onion addresses through in-protocol
flaws. How do we know that we designed it right? How do we know that we
implemented it right?

Imagine if we deploy a local Tor network on the Defcon network, where
random Defcon attendees can run relays. The anonymity properties would
be terrible, because the trust isn't distributed over a large area and
because Sybil attacks and other shenanigans are likely. But new-style
onion services should be able to advertise themselves, and have their
onion address remain private, even in this terrible environment.

The goals of the contest would be getting people to (1) beat on our new
onion service design, and (2) learn more about the Tor design and code.

A proper contest has a variety of puzzles at a variety of difficulty
levels. (If the only challenge were to uncover our private new-style onion
addresses, most people would fail, and they would quickly become bored.)
So we would want to include intermediate challenges. One example would
be to run old-style onion services too, since there are known attacks
against the old design. In an ideal world we'd brainstorm 15 or 20
puzzles, not all onion service related, to keep the attention of a
variety of skill levels, and more importantly to raise the amount of
Tor clue for people at each level.

(The way you actually "capture" an onion could be by visiting the website
behind it, and being given a token that proves you went to it.)

Many fun contest designs include both offense and defense, i.e. they pit
teams against each other rather than against the game itself. I don't
know how to make use of this point, but maybe we will come up with ideas.

I also pondered whether we could team up with an existing contest, e.g.
ask the capture-the-flag people to be a module in their bigger plans.  But
capture-the-flag has been going through contortions to keep the offense
from being too easy -- for example, this year they surprised people with
a 27-bit architecture that uses 9-bit bytes and is middle-endian. Sounds
fun if you're into that, but maybe not so useful for our needs. :)

Part B:

Our SponsorR program manager has expressed interest in helping to make
this idea happen. In fact, it started out as his idea. He's asked us to
put together proposals for the low end, the medium end, and the high
end of what it would cost. (I asked him for hints on what he meant
by each category, and he wouldn't commit, saying instead "whatever it
would cost".)

Piece one that would want attention is contest design, i.e. coming up
with the puzzles, and figuring out how one would implement them, and
also balancing the game so it's fun -- everybody can make progress at
something, there aren't any puzzles that will destabilize the whole
thing, it's clear who made the most progress, etc.

Piece two would be sorting through how to harden a Tor network to survive
being run in this terrible environment. We'd probably want to make the
directory authorities more robust, like by making them onion services
themselves, and/or making them "push" the consensus to the fallbackdirs
rather than being able for pulls. This piece could involve large amounts
of design and coding, so we'd want to make a roadmap and prioritize items.

(We will want to declare certain types of attack out of scope for the
contest, and frowned upon if people do them, but also we will want to
show up with a robust network.)

Piece three would be the actual operations of the contest, including
deploying the network and sandboxing the components, but also including
running everything during the weekend. The first year will be a learning
experience all around, but the more we can learn surprising things rather
than expected things, the better. :)

We might also be wise to deploy the network, and parts or all of the
game, beforehand for playtesting. And I bet some of the puzzles will
work better if people know about them, and prepare for them, beforehand.

Part B2:

Now, there is a strong argument that if what we want most is an exploit
on the new code, we should sign up for Pwn2Own or the like, and offer
a $10k+ prize.

After all, weekend contests are fun for raising interest and getting
people to learn more, but in isolation they may not be an efficient way
of getting people to discover complicated bugs.

I think it's worth exploring both approaches, and maybe combining them
in some cool way if we can think of how best to do it.

Note that we already have our bug bounty program in place, and it would
be very straightforward to highlight and advertise this category of bug
for the top tier $3k payout, or even a higher payout if we wanted. But
coordinating with a higher profile zero-day event could still bring more
attention to the topic.

Part C:

A bunch of people I ran into at Defcon expressed interest in a Tor village
next year. Rather than taking on all the logistics issues ourselves, I've
instead been coordinating with organizers from two existing villages,
who each have no plans to use their village space from 5pm onward each
evening.

This way we could have a designated "hang out and answer Tor questions"
spot, with quite low logistics costs. And if we wanted to make it into
something more we could.

Eight years ago, when I was last at Defcon, I saw many many Tor shirts.
This year I saw almost none. We have definitely been paying less attention
to the American hacker scene lately than we should have been. I think it
would be really great to get a huge pile of Tor shirts there next year,
perhaps with a table in the Tor village, and perhaps also at already
established booths like EFF and Calyx.

--Roger