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