Three things everyone can do now:

1. Please consider running a relay to help the Tor network grow.
2. Tell your friends! Get them to run relays. Get them to run hidden services. Get them to tell their friends.
3. We are looking for funding and sponsors. If you like Tor's goals, please take a moment to donate to support further Tor development. Also, if you know any companies, NGOs, agencies, or other organizations that want communications security, let them know about us.

Supporting Applications

1. We need good ways to intercept DNS requests so they don't "leak" their request to a local observer while we're trying to be anonymous. (This happens because the application does the DNS resolve before going to the SOCKS proxy.)
2. Tsocks/dsocks items:
   • We need to apply all our tsocks patches and maintain a new fork. We'll host it if you want.
   • We should patch Dug Song's "dsocks" program to use Tor's mapaddress commands from the controller interface, so we don't waste a whole round-trip inside Tor doing the resolve before connecting.
   • We need to make our torify script detect which of tsocks or dsocks is installed, and call them appropriately. This probably means unifying their interfaces, and might involve sharing code between them or discarding one entirely.
3. People running relays tell us they want to have one BandwidthRate during some part of the day, and a different BandwidthRate at other parts of the day. Rather than coding this inside Tor, we should have a little script that speaks via the Tor Controller Interface, and does a setconf to change the bandwidth rate. There is one for Unix and Mac already (it uses bash and cron), but Windows users still need a solution.
4. Tor can exit the Tor network from a particular exit node, but we should be able to specify just a country and have something automatically pick. The best bet is to fetch Blossom's directory also, and run a local Blossom client that fetches this directory securely (via Tor and checking its signature), intercepts .country.blossom hostnames, and does the right thing.
5. Speaking of geolocation data, somebody should draw a map of the Earth with a pin-point for each Tor relay. Bonus points if it updates as the network grows and changes. Unfortunately, the easy ways to do this involve sending all the data to Google and having them draw the map for you. How much does this impact privacy, and do we have any other good options?

Documentation

1. We hear that Tor users can fall victim to anonymity-breaking attacks from javascript, java, activex, flash, etc, if they don't disable them. Are there plugins out there (like NoScript for Firefox) that make it easier for users to manage this risk? What is the risk exactly?
2. Is there a full suite of plugins that will replace all of Privoxy's functionality for Firefox 1.5+? We hear Tor is much faster when you take Privoxy out of the loop.
3. Please help Matt Edman with the documentation and how-tos for his Tor controller, Vidalia.
4. Evaluate and document our list of programs that can be configured to use Tor.
5. We need better documentation for dynamically intercepting connections and sending them through Tor. tsocks (Linux), dsocks (BSD), and freecap (Windows) seem to be good candidates, as would better use of our new TransPort feature.
6. We have a huge list of potentially useful programs that interface to Tor. Which ones are useful in which situations? Please help us test them out and document your results.
7. Help translate the web page and documentation into other languages. See the translation guidelines if you want to help out. We especially need Arabic or Farsi translations, for the many Tor users in censored areas.

Coding and Design

1. Tor relays don't work well on Windows XP. On Windows, Tor uses the standard select() system call, which uses space in the non-page pool. This means that a medium sized Tor relay will empty the non-page pool, causing havoc and system crashes. We should probably be using overlapped IO instead. One solution would be to teach libevent how to use overlapped IO rather than select() on Windows, and then adapt Tor to the new libevent interface.
2. Because Tor relays need to store-and-forward each cell they handle, high-bandwidth Tor relays end up using dozens of megabytes of memory just for buffers. We need better heuristics for when to shrink/expand buffers. Maybe this should be modelled after the Linux kernel buffer design, where we have many smaller buffers that link to each other, rather than monolithic buffers?
3. We need an official central site to answer "Is this IP address a Tor exit relay?" questions. This should provide several interfaces, including a web interface and a DNSBL-style interface. It can provide the most up-to-date answers by keeping a local mirror of the Tor directory information. The tricky point is that being an exit relay is not a boolean: so the question is actually "Is this IP address a Tor exit relay that can exit to my IP address:port?" The DNSBL interface will probably receive hundreds of queries a minute, so some smart algorithms are in order. Bonus points if it does active testing through each exit node to find out what IP address it's really exiting from. Read more here.
4. Sometimes Tor relays crash, or the computers they're on fall off the network, or other accidents happen. Some Tor operators have expressed an interest in signing up to a "notifying" service that periodically checks whether their Tor relay is healthy and sends them a reminder mail when it's not. Anybody want to write a few cgi scripts, a few web pages, and set up some sort of wget hack and/or something more complex like Nagios to do the monitoring? The first version could check just the directory port, e.g. looking through the cached network-status page for the right IP address and port and then asking for the "/tor/server/authority" page.
5. It would be great to have a LiveCD that includes the latest versions of Tor, Polipo or Privoxy, Firefox, Gaim+OTR, etc. There are two challenges here: first is documenting the system and choices well enough that security people can form an opinion on whether it should be secure, and the second is figuring out how to make it easily maintainable, so it doesn't become quickly obsolete like AnonymOS. Bonus points if the CD image fits on one of those small-form-factor CDs.
6. Related to the LiveCD image, we should work on an intuitively secure and well-documented USB image for Tor and supporting applications. A lot of the hard part here is deciding what configurations are secure, documentating these decisions, and making something that is easy to maintain going forward.
7. Our preferred graphical front-end for Tor, named Vidalia, needs all sorts of development work.
8. We need to actually start building our blocking-resistance design. This involves fleshing out the design, modifying many different pieces of Tor, adapting Vidalia so it supports the new features, and planning for deployment.
9. We need a flexible simulator framework for studying end-to-end traffic confirmation attacks. Many researchers have whipped up ad hoc simulators to support their intuition either that the attacks work really well or that some defense works great. Can we build a simulator that's clearly documented and open enough that everybody knows it's giving a reasonable answer? This will spur a lot of new research. See the entry below on confirmation attacks for details on the research side of this task — who knows, when it's done maybe you can help write a paper or three also.
10. We need a measurement study of Polipo vs Privoxy. Is Polipo in fact significantly faster, once you factor in the slow-down from Tor? Are the results the same on both Linux and Windows? Related, does Polipo handle more web sites correctly than Privoxy, or vice versa? Are there stability issues on any common platforms, e.g. Windows?
11. Related on the above, would you like to help port Polipo so it runs stably and efficiently on Windows?
12. We need a distributed testing framework. We have unit tests, but it would be great to have a script that starts up a Tor network, uses it for a while, and verifies that at least parts of it are working.
13. Help Mike Perry on his TorFlow library (TODO): it's a python library that uses the Tor controller protocol to instruct Tor to build circuits in a variety of ways, and then it measures performance and tries to detect anomalies.
14. Tor 0.1.1.x and later include support for hardware crypto accelerators via OpenSSL. Nobody has ever tested it, though. Does somebody want to get a card and let us know how it goes?
15. Perform a security analysis of Tor with "fuzz". Determine if there are good fuzzing libraries out there for what we want. Win fame by getting credit when we put out a new release because of you!
16. Tor uses TCP for transport and TLS for link encryption. This is nice and simple, but it means all cells on a link are delayed when a single packet gets dropped, and it means we can only reasonably support TCP streams. We have a list of reasons why we haven't shifted to UDP transport, but it would be great to see that list get shorter. We also have a proposed specification for Tor and UDP — please let us know what's wrong with it.
17. We're not that far from having IPv6 support for destination addresses (at exit nodes). If you care strongly about IPv6, that's probably the first place to start.
18. Don't like any of these? Look at the Tor development roadmap for more ideas.
19. Don't see your idea here? We probably need it anyway! Contact us and find out.

Research

1. The "website fingerprinting attack": make a list of a few hundred popular websites, download their pages, and make a set of "signatures" for each site. Then observe a Tor client's traffic. As you watch him receive data, you quickly approach a guess about which (if any) of those sites he is visiting. First, how effective is this attack on the deployed Tor codebase? Then start exploring defenses: for example, we could change Tor's cell size from 512 bytes to 1024 bytes, we could employ padding techniques like defensive dropping, or we could add traffic delays. How much of an impact do these have, and how much usability impact (using some suitable metric) is there from a successful defense in each case?
2. The "end-to-end traffic confirmation attack": by watching traffic at Alice and at Bob, we can compare traffic signatures and become convinced that we're watching the same stream. So far Tor accepts this as a fact of life and assumes this attack is trivial in all cases. First of all, is that actually true? How much traffic of what sort of distribution is needed before the adversary is confident he has won? Are there scenarios (e.g. not transmitting much) that slow down the attack? Do some traffic padding or traffic shaping schemes work better than others?
3. The "routing zones attack": most of the literature thinks of the network path between Alice and her entry node (and between the exit node and Bob) as a single link on some graph. In practice, though, the path traverses many autonomous systems (ASes), and it's not uncommon that the same AS appears on both the entry path and the exit path. Unfortunately, to accurately predict whether a given Alice, entry, exit, Bob quad will be dangerous, we need to download an entire Internet routing zone and perform expensive operations on it. Are there practical approximations, such as avoiding IP addresses in the same /8 network?
4. Other research questions regarding geographic diversity consider the tradeoff between choosing an efficient circuit and choosing a random circuit. Look at Stephen Rollyson's position paper on how to discard particularly slow choices without hurting anonymity "too much". This line of reasoning needs more work and more thinking, but it looks very promising.
5. Tor doesn't work very well when relays have asymmetric bandwidth (e.g. cable or DSL). Because Tor has separate TCP connections between each hop, if the incoming bytes are arriving just fine and the outgoing bytes are all getting dropped on the floor, the TCP push-back mechanisms don't really transmit this information back to the incoming streams. Perhaps Tor should detect when it's dropping a lot of outgoing packets, and rate-limit incoming streams to regulate this itself? I can imagine a build-up and drop-off scheme where we pick a conservative rate-limit, slowly increase it until we get lost packets, back off, repeat. We need somebody who's good with networks to simulate this and help design solutions; and/or we need to understand the extent of the performance degradation, and use this as motivation to reconsider UDP transport.
6. A related topic is congestion control. Is our current design sufficient once we have heavy use? Maybe we should experiment with variable-sized windows rather than fixed-size windows? That seemed to go well in an ssh throughput experiment. We'll need to measure and tweak, and maybe overhaul if the results are good.
7. To let dissidents in remote countries use Tor without being blocked at their country's firewall, we need a way to get tens of thousands of relays, not just a few hundred. We can imagine a Tor client GUI that has a "Tor for Freedom" button at the top that opens a port and relays a few KB/s of traffic into the Tor network. (A few KB/s shouldn't be too much hassle, and there are few abuse issues since they're not being exit nodes.) But how do we distribute a list of these volunteer clients to the good dissidents in an automated way that doesn't let the country-level firewalls intercept and enumerate them? Probably needs to work on a human-trust level. See our early blocking-resistance design document and our FAQ entry on this, and then read the censorship resistance section of anonbib.
8. Tor circuits are built one hop at a time, so in theory we have the ability to make some streams exit from the second hop, some from the third, and so on. This seems nice because it breaks up the set of exiting streams that a given relay can see. But if we want each stream to be safe, the "shortest" path should be at least 3 hops long by our current logic, so the rest will be even longer. We need to examine this performance / security tradeoff.
9. It's not that hard to DoS Tor relays or directory authorities. Are client puzzles the right answer? What other practical approaches are there? Bonus if they're backward-compatible with the current Tor protocol.

Let us know if you've made progress on any of these!