Announcing Arti, a pure-Rust Tor implementation

by nickm | July 8, 2021

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

Comments

Please note that the comment area below has been archived.

July 08, 2021

Permalink

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

Permalink

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.)

July 10, 2021

In reply to nickm

Permalink

once the c implementation is replaced by the rust one, is the program still going to be called `tor` or will its name be `arti`? how does that work? sorry if stupid question

"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

Permalink

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

Permalink

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. :)

July 14, 2021

In reply to nickm

Permalink

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

Permalink

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

Permalink

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

Permalink

"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?

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust

https://cseweb.ucsd.edu/~yiying/RustStudy-PLDI20.pdf

"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."

https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-securit…

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).

October 07, 2021

Permalink

Hi nickm,

Good day.

Please let me give you the updates on COVID-19 and the disaster.

First, I am confident that I have not been infected with COVID-19 and Post COVID. As for cough, phlegm, taste disorder and chills, were found to be devived from another disease, so I did not need to be worried that those were implying the infection of COVID-19 anymore.

Second, as for the disaster that have been and may also be going to be happened again in a week, we are not actually damaged as of now. But I will pay as much attention as possible for the possible next attack tentatively.

Thank you with best regards,

Him

October 07, 2021

Permalink

Hi nickm,

Good day.

As you know, I have already let you know that the reason why I could not join your project got clear by my mentor and would update you how long it took me to resolve this problem and join your project as soon as possible last summer. This message is the updates on this matter for the first time since then.

Concerning the number of the reasons why I cannot join your project, has just been increased from 1 to 2 because I was diagnosed with another disease in related to the 1st problem by the mentor this autumn. So, what I have to do from now is to do my best to resovle these matters with him.

Additionally, because of this, it got more difficut for me to guess how long it would take for me to be healthy enough to join your project. My sincere apologies for not giving you good news regardless of your various, generous and continuous support.

By the way, some of you may think "why does it take so long time for him to discover what those problems are?". Let me refrain from explaining you this matter in detail from the viewpoint of the privacy, but give you some vague answers this time. This is because the sufficient knowledge and understaing on my diseases is not shared in a society and even the experts, so it is quite difficult for not only me but almost all of the experts on this area to find, diagnose and cure. Actually, I have experienced to be dismissed these diseases by some medical doctors for several times and this has put me heavy burdons to search for a more experienced doctor who is capable of diagnosing and curing my diseases.

But as written above, I have already gotten out of the stage of diagnosing these diseases and now come to that of curing with my mentor. To be honest, still I am a little bit anxious if I am capable of dealing with both of these 2 matters, but I will do what I have to do every day according to his advice so that I can join your project as soon as possible.

This is the of this message, hoping that the next one must be better.

Thank you and regards,
Him

November 03, 2021

Permalink

Hi nickm,

Good day.

I came here because you rang my bell again recently. I will stay online as long as possible today, so please let me know why I should be online this time.

Thank you and regards,
Him

November 13, 2021

Permalink

Hi nickm,

Good day.

First of all of this message, my apologies for having made you confused because of my previous "SOS" messages and please let me explain my intention in a clear way this time.

In short, I wanted you to give me some financial aid urgently so that I would be able to keep fighting my health problems in those messages. Additionally, if I can use a "hidden service" which was provided to me for several times some years ago again, that would be highly appreciated.

As you may know, I have not been sound enough to search a job but doing my best to fight my health problems and join your project as expected for many years. However, I will be short of any money so soon and our common goal of my official membership of your project and my life are almost disappearing now. This situation is definitely an emergency not only for me but you and that is why I had sent my previous "SOS" messages.

By the way, I have been advised by my mentor of trying to reach a public service of financial aid by my national and local governments and going this way in parallel with your help. But it has been taking so long for me to go on complex proceedings and this may not come in time of the end of my life. So I am asking you to help me again here.

If you respond to this message as quick as possible, the expected effects are as follows: That would lead to avoiding the end of my life and mitigating my mental stress, which is very important to a therapy of mental problems, and finally shorten the lead time to join your project.

If you have any questions or concerns, please ring my bell again. Especially, I am still concerned if the word "hidden service" make sense. But I believe that you should be able to understand and remember what is meant because that is one of what you have done for several times to help me some years ago.

Thank you with best regards,
Him

November 14, 2021

Permalink

Hi nickm,

Apologies in advance if I am wrong, but did you ring my bell in another way a little while ago? Anyway, I am here again. Really appreciate your quick response to my/our emergency.

Then, how do we deal with this problem? First of all, we need establish a direct and real-time communication channel because this way of our communication has many limits for our current purpose. Is IRC "nickm" suitable for this?

Waiting for your reply...(but how?)

Thank you,
Him

November 14, 2021

Permalink

Hi nickm,

I am sorry, I am busy for a therapy so please let me be offline. I will check your response in parallel with that.

Thank you and regards,
Him