Hi!
I’m Nick Mathewson, one of the co-founders of Tor. We’ve been working on Tor for a long time now (since 2002!), and over the years it has become a widely used and widely analyzed tool for internet privacy.
Last year, I made a post on the Zcash Community forum about a project called Arti—“a Rust Tor implementation”—and its network-level privacy benefits for the Zcash privacy portfolio, not only as a communications privacy layer for Zcash, but also for all the other communications tools that Zcash users employ. We discussed the project with stakeholders, and used their suggestions about Zcash’s needs to improve our project plan. After more revisions, we applied for a grant to fund the first year of Arti work from what was known at the time as ZOMG, and is now ZCF.
Thanks to ZCF’s generous funding of this project, we’ve taken enormous steps forward in developing Arti from an experimental project to a usable privacy backend. And today, I’m returning to the forum to discuss our progress, talk about what comes next, and propose our idea for a second-year grant to the Tor Project.
Brief introduction to Tor and Arti + Zcash
In my post last year, I wrote about Tor and its network-level privacy benefits, and defined Arti in depth. I encourage you to read this post if you are just now learning about this project and want to dive in!
Here’s what I said last year, and I think it still applies:
Tor provides robust network-level privacy for a huge variety of protocols, hiding their traffic among millions of active Tor users. Tor is available to use, well established, and well analyzed today, and works with most any protocol that works over TCP. Our network’s performance and scalability have been improving over time, and we layer with an ecosystem of tools to circumvent different censorship regimes around the world.
But the current Tor implementation bears the signs of its age. Tor is implemented in C, as a stand-alone network proxy. Because Tor is a stand-alone proxy, it’s cumbersome for third parties to embed. And because Tor is written in C, it’s difficult to have the same confidence in its memory-safety as would be possible with a higher-level memory-safe language. Moreover, because C is unsafe and error-prone, our development requires more time and energy than it should, which slows us down when delivering improvements to our users.
Here’s where Arti comes into play. Arti is a pure-Rust implementation of the Tor protocols designed from the ground up for flexibility in embedding, straightforward maintenance, flexible deployment, and reasonably good performance. We believe Arti is the future of Tor: by using Rust, we get memory safety “for free,” and will eventually get compilation to WASM. Moreover, we get a codebase that others can maintain and adapt to fit with their projects, taking only the parts that they need to keep their binaries small for mobile or other restricted environments.
Arti has the potential to benefit Zcash in many ways, both in the short term and the long term, as it resolves some existing painpoints for using Tor for network privacy: (1) Arti makes Tor easier to embed, (2) Arti allows for more fine-grained control over Tor’s behavior, and (3) Arti ensures Tor improvements can be developed faster.
By adding a layer of communications privacy between wallet users and the Zcash network, we expect Arti to improve the overall privacy of Zcash by hiding which users are communicating to which servers when, and thereby protecting users against a wider variety of traffic analysis and correlation attacks.
Moreover, Arti’s communications privacy benefits other applications in the privacy space that Zcash users depend on. After all, it’s hard to use Zcash’s private transactions in a meaningful way if you cannot have private communications with your transaction partners. By improving the ecosystem around online private communications, Arti provides more opportunities for Zcash users to privately coordinate and communicate.
Progress of our current grant with ZCF
We’re a little past the half-way mark in our year-one plans. Since we started, we’ve put out a number of releases, making Arti more secure, more stable, and more embeddable. You can read the details in our announcement posts for each of the versions we’ve released:
-
Arti 0.0.1 with basic anonymity support.
CHANGELOG -
Arti 0.0.2 with API groundwork and lots of refactoring.
CHANGELOG -
Arti 0.0.3 with better configuration support, predictive circuits, and anonymity improvements. [
CHANGELOG](CHANGELOG.md · main · The Tor Project / Core / Arti · GitLab) -
Arti 0.0.4 with support for Rustls, and bootstrap status reporting.
CHANGELOG -
Arti 0.1.0 with a somewhat stable API.
CHANGELOG -
Arti 0.2.0 with performance improvements, a
dns_portfeature, and a “dormant mode” API.CHANGELOG
For people who like statistics: since we started this grant, Arti has grown by about 35,000 lines of code, and our test coverage remains well above 80%.
Now we’re focusing on the missing features needed to use Arti in production. When we release version 1.0.0 in a few months, we intend for Arti to be ready for at least some production use. This will require implementing important security features, tolerating more kinds of network failures, and converging on even more stable APIs.
In August and September, we’ll focus on censorship resistance in Arti 1.1.0, making sure that Arti can take advantage of Tor’s current group of bridge relays and pluggable transports to avoid censorship on the internet. When we finish 1.1.0, we will have finished the work laid out in our original grant with ZCF.
Lessons learned so far
Our attempts at consructing APIs before finalizing related functionality proved to be somewhat ill-conceived. In at least two places (our event-reporting API and our configuration API), initial work has proven to need API and implementation revision based on deployment experience and needs. Up-front design was not an adequate substitute for iterative refinement. One possible lesson to take from this is that in the future, we should avoid stabilizing a definite API for a piece of functionality before a couple of versions’ worth of experience trying to use it in practice.
One surprising piece of good news for us is that as this grant gave us the chance to hire more Rust developers, we had a much easier time than we typically have had when hiring C programmers in the past. The applicant pool was large, and of very high quality. We attribute this to the fact that writing new security-critical high-performance network programs in Rust is simply a more attractive job than maintaining 20-year-old security-critical legacy code in C.
Arti in the wild
At least three projects have already tried using Arti experimentally. In one, a group of researchers developing a COVID-19 contact-tracing app adapted Arti to anonymize their client-server communications for added privacy. In another, an internal team of developers at Tor is using Arti to construct a new cross-platform mobile-friendly Tor-based VPN application. Both groups have reported that using Arti was, for them, far easier than trying to embed the C Tor implementation. The third project is Zebra: @teor added experimental Tor support using Arti 0.0.2, and reported the results.
What’s next
When we end our year 1 grant, we intend that Arti should be production ready for at least some users and use-cases. But there is more work to do, which we believe will also be of benefit to the Zcash community. In year 2, we have two major milestones planned. In 1.2.0, we hope to be able to implement onion services for responder anonymity in Arti, and in 2.0.0 we plan to make Arti a viable replacement for most current users of the C tor client. I’ll talk about each of these phases below.
Year 2: Phases of Work
Implementing onion services (Arti 1.2.0)
The Tor client allows users to run onion services: a location-hidden server on the network that you can only connect to if you know its public key. For many users, this is their main use case for tor. Some applications (such as Onionshare, Ricochet Refresh, and cwtch) rely on onion services as their primary transport for private communications. Some developers in the broader Zcash community have also told us that onion services are a critical feature for meaningful integration with their applications.
To start the second year of Arti’s work, we plan to produce a complete implementation of the current (v3) onion service protocol, with support for both client-side and server-side implementations.
We also plan to include a full range of Tor’s tools for security and denial-of-service improvements to onion services, to make them safer to run on the internet. As we go, we’ll incorporate ideas from existing research to try to produce the most secure onion service implementation possible.
This is no small task: as you can see from the main ticket, onion services require a complex set of subprotocols in addition to the main Tor implementation. We’ll be drawing on the experience we’ve gained in the past from building these protocols in C, and from designing Arti to support protocol extensions.
Replacing the C tor client. (Arti 2.0.0)
In time, we want Arti to become the primary Tor implementation, so that we can focus our efforts on a high-productivity, high-security program environment without all of the risks and drawbacks of our old C implementation. But before we can do that, we need Arti to work well enough as a replacement for existing Tor users that they can migrate to it comfortably.
In the second half of our second year, we will be “filling in the gaps” to make Arti 2.0.0 a better alternative to the C client implementation for nearly all users. This will include work on circuit padding, a stable C FFI, support for more proxy protocols, and whatever missing features users and developers judge to be most important.
Once that’s done, we’ll be able to deprecate client usage of the C Tor implementation (though we’ll have to keep supporting it in maintenance mode for a couple of years at least).
After year two
Although this is beyond the scope of our proposed grant, I thought it would make sense to share what we’re planning for future work on Arti.
Our long-term goal with Arti is to improve the pace of Tor development by breaking free from our legacy code and architecture, and from the dangerous of the memory-unsafe world. So once we have parity with the C client implementation, we’re going to switch our attention to implementing the relay and directory-authority parts of the Tor protocol. Once that is done, we’ll be able to deprecate our C implementation completely, and deploy new features and improvements to the protocol as “Rust only”. We’re at the early stages of estimating this work, but we think it should be something we can accomplish in one or two further years.
In closing
Thanks for reading this post! Based on our work so far on Arti, we believe that this second year of work is of interest to the Zcash community. We’d like to hear from the community about this idea before we propose a grant to ZCF, so that we can integrate your feedback. Thanks again: we’re looking forward to your ideas!
(This seems like a good time to say that the Tor Project is a 501(c)3 not-for-profit charitable corporation, incorporated since 2006. We don’t have shares, or answer to shareholders. We are committed to free software, and we don’t do patents. We also believe in transparency, and we post our annual financial filings online once they’ve been audited. Our mission is to develop and promote privacy software, and we believe in it strongly.)
