Announcing Arti, a pure-Rust Tor implementation


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 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 (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 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?)


July 08, 2021


This is exciting news.... looking forward to the day when Arti is stable, and maybe even further to the day when TBB can be completely Rust too (Servo?)


July 08, 2021


1. Does this mean Tor will be discontinued in near future?
2. Will it be easy to migrate from Tor to Arti? e.g `apt remove tor` & `apt install arti`
3. Will Arti supports current .onion keys? (this should be)

1. Does this mean Tor will be discontinued in near future?

No. I tried to answer that in advance, in the part of the blog post titled "What does this mean for the existing C Tor implementation?".

2. Will it be easy to migrate from Tor to Arti? e.g `apt remove tor` & `apt install arti`

I hope that the migration will be easy, but we won't be at that point for a while. We're prioritizing "getting things right" over stuff like "not breaking the configuration file format".

3. Will Arti supports current .onion keys? (this should be)

When Arti gets onion service support (which isn't scheduled for quite a while), it will support current v3 onion keys and addresses. (V2 onion addresses are deprecated.)

"Tor" is the name of the program, the protocols that it implements, and the project that makes that program and protocols. The protocols and the project will still be "Tor" even when Arti is done. I don't think we're going to rename Arti, though I guess it is a possibility. That's a long way off, though.


July 09, 2021


Nick you are doing great work as always! Arti and Rust are going to be so good for security if you stick with minimal unsafe code and Rust best practices. It's a good time to brainstorm all the new design decisions and revert any old protocol or code mistakes now as this opportunity will not come again soon. Please don't forget to make torsocks compatible with Arti too.


July 10, 2021


Rust? Well this is troublesome to build from source in low power systems such as arm/mips/riscv.
So please do not drop C based tor for at least 10 years. Maybe by then we use zig or something. :P

It's true that Rust takes more CPU to build than C does. In return, it gives us an environment where we can write safer, faster programs with less programmer effort. I'm hoping that this is the right trade-off: we spend a lot more time developing than we do compiling, and users spend a lot more time running the program than they do compiling.

Anyways, like the blog post says, we do not have a timeline to C tor support any time soon at all: not until some time after Arti is truly ready to replace it. :)

ever tried compiling the actual Rust compiler on a single board? (e.g. Raspberry Pi)

for people using source-based Linux on a single board, rust based tor is not viable if they have constant demands on system resources, such as....

....Bitcoin channel routing (lightning). Using Tor just to enable port forwarding is very common for home based lightning nodes. Trusting dev binaries when you're handling money is a bad idea, "it only takes one bad apple" etc. Source based, headless (and minimalistic generally) is best for lightning nodes.

And a rust compiled Tor rules out that whole model. When recompiling rustc uses up to 4GB RAM for 12-48 hours (depends on the board) and a huge amount of CPU, any payment routing the node might have done is going to be impinged on rather alot. C based Tor has no such problems.

So, cross-compiling is real, and I would strongly recommend it to anybody who wants to run software on a lower-powered computer. With cross-compilation, you don't need to run the rust compiler on the raspberry pi: you can run it on any computer, and have it make a binary that you can copy onto your raspberry pi.

(I definitely would recommend cross-compilation if your threat model requires you to bootstrap your compiler on a regular basis.)


July 10, 2021


This is a wonderfull development! It is good you got the ZOMG funding for this project.

I have some questions out of curiousity.

1. Were languages other than Rust ever considered or was Rust the only language considered from the start?

2. How will this affect branding? Will Tor become known as Arti or Tor/Arti? Or will it just stay "Tor"?

3. Does the Tor Project also have a PeerTube channel or only a YouTube channel?

Keep up the amazing work!

1. Were languages other than Rust ever considered or was Rust the only language considered from the start?

We've been trying to keep abreast of new developments in languages, but there are probably a bunch we don't know about. Rust has been running ahead of our other options for a long time, due to the properties discussed in the blog post, and also because of its growing mindshare and tremendously supportive community.

2. How will this affect branding? Will Tor become known as Arti or Tor/Arti? Or will it just stay "Tor"?

Right now my guess is this: The Tor protocols will still be called the Tor protocols; the Tor Project will still be called the Tor Project; the Tor Browser will still, I assume, be called the Tor browser. "Arti" will be a program that implements the Tor protocols.

This is kind of like how the Web is still the Web, even though the web browser is no longer called WorldWideWeb.

3. Does the Tor Project also have a PeerTube channel or only a YouTube channel?

I don't know; I'll ask!


July 15, 2021


Will it be easy to utilize the dependencies Tor has on zlib, OpenSSL etc in Rust ?

Does it bind to 'C' libraries.

I'll be honest in asking out of some ignorance of Rust.
Thank you.


July 22, 2021


"were specifically due to mistakes that should be impossible in safe Rust code"

But there are multiple examples of the contrary? isn't there such a saying if it sounds too good to be true?

"New programming languages such as Go and Rust rely entirely on static linking, and there’s nothing we can do about it. Instead of packaging the dependencies and having programs use the newest versions, we just fetch the versions pinned by upstream and make big blobs out of it. And while upstreams brag how they magically resolved all security issues you could ever think of (entirely ignoring other classes of security issues than memory-related), we just hope that we won’t suddenly be caught with our pants down when a common pinned dependency of many packages turns out to be vulnerable.

Added 2021-04-27: Deadlock vulnerability through embedded app-emulation/containers-storage (CVE-2021-20291) is an example how a vulnerability in a single Go package requires hunting all affected ebuilds."…

When you use 'unsafe', you do have to keep in mind that you're now in-charge of preventing Undefined Behaviours/exploits. Most of these CVEs were because of usage of 'unsafe' (not to say all bugs are because of unsafe). Honestly the amount of bugs seen here is surprisingly low (313 CVEs for all Rust projects ever since Rust's inception is pretty good).

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

8 + 5 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.