Greetings!

Today I'm happy to announce a new era in Tor implementation.

Over the past year or so, we've been working on "Arti", a project to rewrite Tor in Rust. Thanks to funding from Zcash Open Major Grants (ZOMG), we can finally put the Arti project up in our priorities list, and devote more time to it.

Below I'll talk about why we're doing this project, what it means for Tor users and operators, where it's going in the future, and how people can help.

A little background

Tor is a set of protocols to provide anonymity, privacy, and censorship resistance on the Internet. Tor is also a program (in C) that provides client-side and server-side implementations of those protocols. We started Tor back around 2002, based on earlier Onion Routing designs from the mid-1990s. In 2006, we incorporated the Tor Project as a nonprofit charity. Since then, Tor has grown to handle millions of users around the world.

Why write Tor in Rust?

Today's Tor is written in the C programming language. Although C is venerable and ubiquitous, it's notoriously error-prone to use, and its lack of high-level features make many programming tasks more complex than they'd be in a more modern language.

For us, these problems mean that programming in C is a slow and painstaking process. Everything we write takes more code than we'd like it to, and we need to double-check even the safest-looking code to make sure it doesn't fall prey to any of C's list of enormous gotchas. This slows us down seriously, and increases the cost of adding new features.

Rust seems like the clearest way out of our bind. It's a high-level language, and significantly more expressive than C. What's more, it's got some really innovative features that let the language enforce certain safety properties at compile-time. To a first approximation, if the code compiles, and it isn't explicitly marked as "unsafe", then large categories of bugs are supposed to be impossible.

That's a huge win for us in programming and debugging time, and a huge win for users in security and reliability. Since 2016, we've been tracking all the security bugs that we've found in Tor, and it turns out that at least half of them were specifically due to mistakes that should be impossible in safe Rust code.

Example: multithreaded crypto

Here's a case where Rust's safety can really help us.

For years now, we've wanted to split Tor's relay cryptography across multiple CPU cores, but we've run into trouble. C's support for thread-safety is quite fragile, and it is very easy to write a program that looks safe to run across multiple threads, but which introduces subtle bugs or security holes. If one thread accesses a piece of state at the same time that another thread is changing it, then your whole program can exhibit some truly confusing and bizarre bugs.

But in Rust, this kind of bug is easy to avoid: the same type system that keeps us from writing memory unsafety prevents us from writing dangerous concurrent access patterns. Because of that, Arti's circuit cryptography has been multicore from day 1, at very little additional programming effort.

Why a full rewrite?

At one point, we had hoped to slowly replace Tor's C code with Rust, one piece at a time. That hasn't worked out for us, however.

Our problem here is that the modules in our existing C code are not terribly well separated from one another: most modules are reachable from most other modules. That makes it hard for us to rewrite our code one module at a time, without first untangling it to be more modular. And untangling the code is risky, for all the same reasons that working in C is typically risky.

With a rewrite, we figured that we can keep our existing C code stable and make only minimal changes to it, while building up a working base of Rust code to serve as a basis for future development.

(And while we're writing a new implementation, we can clean up design issues that have been hard to fix in C. For example, the complicated structure of the C code has made it hard to adopt for embedding into other applications. But with our Arti rewrite, we can take embedding into account from the start, to help support applications down the road.)

What can Arti do today? What features are missing?

First off: Don't use Arti for real privacy yet.

Arti doesn't yet run as a relay at all. It doesn't support Tor's anti-censorship features yet, and it can't connect to onion services yet.

Finally, note that today's Arti is missing several key security features for privacy: you shouldn't use it for browsing if you have actual privacy needs at all.

So what can Arti do? Right now, Arti can successfully bootstrap, run as a SOCKS proxy, and connect over the Tor network. It has an (unstable) API that you can use to embed it in other Rust programs, and give them support for connections over the Tor network.

What are the next steps for Arti?

Thanks to funding from ZOMG, we're going to try bring Arti to a production-quality client implementation over the next year and a half.

In our first phase, we're focusing on the missing security features that we need in order to get Arti as secure as Tor. We estimate we'll be done with this in October of this year. This phase will probably move the most slowly, since we're ramping up our Rust development capacity (and getting better at Rust!), and as we're finishing up some existing commitments.

In our second phase, we'll focus on all the features needed for seamless embedding. We'll add missing features for efficiency and responsiveness, and add APIs for bootstrap reporting and other functionality that applications need to give a good user experience. We estimate we'll finish this around March of 2022.

In our third phase, we'll work to get Arti ready for production client use. We also expect that this will involve a lot of fine-tuning, experimentation, and fixing issues in response to early experimentation and user experience. We expect we'll finish this around September of 2022.

And in our fourth phase, we'll be working on anti-censorship features (including bridges and pluggable transports). We think we can do that in a single additional month, wrapping up around October of 2022.

Beyond that, the plans are unwritten (and so far, unfunded). The next priority will probably be programming support for v3 onion services, and after that, all the other missing client-side features that users need.

And then? We also want support for running a Tor Relay in Rust. That will require a great deal of additional effort, but it should help significantly with the network's performance, reliability, security, and pace of development.

What does this mean for the existing C Tor implementation?

Depending on whether you're an optimist, you might say that that the C Tor code isn't going anywhere soon. Or you might say that its days are numbered.

In order to make the time to work on Arti, we need to devote our resources in that direction. We expect that in the coming years, we will spend more and more time programming in Rust, and less in C. Eventually, once our Rust implementation of Tor is a good replacement for our C implementation, we will stop adding new features to the C implementation, and eventually drop support for it entirely.

But that's far off, for now. At present, we're going to continue supporting and developing our C Tor as a client and relay. We expect that the pace of new features in C will slow, but we will continue fixing issues, shipping bugfixes, and solving important problems in our C code, until Rust is ready to replace it entirely. We will work to keep C Tor users secure, safe, and private, until it is finally ready to be replaced.

How can I try out Arti?

Remember, don't try it yet if you want security or privacy, since it won't give you those.

If you'd like to try Arti with TorBrowser, you can read the instructions in our CONTRIBUTING.md file. They assume that you have cargo installed, and that you know how to build rust programs.

If you'd like to write a Rust program using Arti, have a look at the arti-tor-client crate. For now, you're probably better off using ours instead of the one on crates.io. (Remember, these APIs aren't stable, and are subject to change without warning.)

How can I follow along with development?

We're going to be posting updates in a bunch of different ways, to see what works best for everybody.

First off, we'll be posting regular updates (more technically and more frequently than you'd really want from this blog) on the tor-dev mailing list, and eventually on a dedicated website.

Second, we're going to be recording some of our regular meetings and posting them on the Tor Project's YouTube channel in a dedicated playlist. There we'll be talking about what to work on next, how to organize and schedule, and generally keeping track of pace and priorities.

Third, we hope to be hosting regular public hackathons and programming sessions for interested developers. More information as it develops!

How can I help?

For now, we most need developers and documentation -- especially you're already familiar with Rust or Tor, but even if you're not.

The CONTRIBUTING.md document has a few suggestions of where to start, but it's still pretty new. (Are you any good at writing "How can I help" documents?)