The original version of this post had a bunch of links, but these forums only allow me two. I’ve put the original version up at [the project wiki]](Zcash Grants post · Wiki · The Tor Project / Core / arti · GitLab) in case you want to follow the links and find out more. I’m marking the linked words with italics.
- The Tor Project has a project proposal that will solve a network-privacy challenge for Zcash by making Tor easy to embed, customize, and maintain.
- To do so, the Tor Project will create an implementation of the Tor protocols in Rust (called “Arti”), moving away from its current implementation in C.
- Making Tor easier to embed benefits the broader ecosystem of privacy tools, making an impact for users beyond the Tor Project and Zcash communities.
About Tor & network-level privacy benefits
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.
Tor provides robust network-level privacy for a huge variety of protocols, hiding their traffic among millions of active Tor users. Thus, it fits as a “missing piece” of the Zcash privacy story – not only as a communications privacy layer for Zcash, but also for all the other communications tools that Zcash users employ.
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 standalone network proxy. (This made sense back in 2002, when high-performance cross-platform languages were less common on the ground.) Because Tor is a stand-alone proxy, it’s cumbersome for third parties to embed: we have a “library mode,” but the library mode just runs the proxy in a separate set of threads. 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.
We’ve heard from a bunch of other projects that what they want from us is a lightweight, easy-to-tweak implementation of the Tor protocols, in a safe language that they can embed in other programs and use as a library. With that in mind, we’ve started on a Rust implementation of the Tor protocols that we’re calling “Arti.”
We’re designing Arti from the ground up for flexibility in embedding, straightforward maintenance, flexible deployment, and reasonably good performance. Even though it’s comparatively new, we hope and believe it’s 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 works today: you can fetch the source and run it as a SOCKS proxy. The README file has instructions for using it with Tor Browser. (Treat it as experimental for now, and do not rely on it for security or privacy: I’ll explain why below.) The code is simpler and smaller than the C Tor implementation, and it already has a simple (unstable) API for embedding.
Arti, Zcash, and ZOMG
Arti has the potential to benefit Zcash in many ways, both in the short term and the long term. In the past, when Zcash has looked into using Tor as a privacy layer (see for example this thread), several issues came up.
- First, Tor is difficult to embed. Arti solves that by being structured as a set of Rust crates from the ground up.
- Second, Zcash would want fine-grained control over Tor’s behavior of a kind that’s difficult to achieve in today’s Tor. Arti solves this by using a modular design that makes it easy for other projects to replace pieces of the Tor implementation (such as circuit scheduling or path selection) as required.
- Finally, sometimes our work in delivering Tor improvements is slowed because of our legacy code. Arti solves this by giving us a new, safer architecture for prototyping and deploying protocol improvements, and delivering them to users and developers. Basically, with a better foundation to build on, all of our solutions become easier to build.
We hope to engage not only with the ZOMG as a grant partner for Arti, but also with the broader Zcash community as partners in development: Arti would benefit from the Zcash community’s Rust expertise and experience; Zcash would benefit from having a major network privacy client designed and built with an eye to Zcash’s requirements from the beginning into account. We believe that by making sure that Arti is built to meet Zcash’s needs (as well as the needs of existing Tor users), we can
deliver a more flexible tool than we would otherwise, to better spread privacy to the world at large.
Phases of work
In terms of the structure of the work: We are structuring our progress for Arti on three main tracks: (1) API usefulness/stability, (2) protocol security, (3) and feature parity with the C implementation. I’ll discuss each track below.
So far, Arti’s API is minimal but usable, but we’ll need to expose at least a minimal surface for other tools to use before we can call Arti a useful embedded solution… and we’ll need to design those APIs with a view towards the use cases that other tools have for the Tor protocols. It’s our understanding that our first-draft minimal API already meets some of Zebra’s needs, and we look forward to working with them, as well as the rest of the Zcash-in-rust world, to provide something they can use.
Some important high-level milestones for the API include:
- A stable top-level API that we can commit to supporting in the future.
- Support for introspection on the state of the Tor client, to detect censorship, bootstrapping issues, network status, and so on.
- Support for explicit circuit creation and management, as needed for tools like Zebra to manage linkability.
- Fine-grained control over path generation, circuit construction, stream isolation, and routing for applications that need them.
- Support for building without unneeded modules in resource-contrained environments.
- Support for multiple Rust async execution environments, TLS backends, and so on.
We’re grouping many of our goals here under milestone A2 in gitlab, but we expect to find more work here as we progress and work with application developers.
Although Arti conforms to the Tor protocol specification, the C Tor implementation has lots of security features that Arti does not. Before we can recommend Arti for general use, we’ll have to add these features to Arti so that it provides network privacy at least as good as the C Tor implementation.
Some of these features are absolutely essential to privacy, including:
- Guard nodes to resist predecessor attacks.
- Application stream isolation to avoid cross-domain linkability.
Other security features are valuable but not critical, including:
- Adaptive circuit-build-timeout inference and path bias detection, to avoid certain kinds of active insider attacks.
- Preemptive circuit construction, connection padding, and circuit padding, to resist certain kinds of timing attacks.
We’re grouping this kind of work under milestone “B” in gitlab , but we do expect to find more work here as we progress.
Feature parity with the C Tor implementation
Right now Arti is a simple SOCKS proxy, and a simple way to make anonymous connections. The C implementation has numerous other features that clients use and rely on, which we think are necessary before we could stop maintaining the C version of Tor entirely. Some are generally useful, whereas others are more applicable for specific niches.
The most important missing features are:
- Onion services for responder anonymity.
- Pluggable transports for censorship circumvention
- Performance and fairness features, to make sure that Arti behaves well when handling hundreds or thousands of simultaneous client streams.
We’re grouping all this work under milestone “C” in gitlab, but as above, we expect to find more work here as we progress.
We think we can get everything above done in about 2 years, using 3 developers’ worth of time. This work can be broken into multiple phases, depending on funding.
- Minimal safe, usable prototype: 3-6 months
- Incremental releases improving stability & security, to production-ready status: 6 months-1 year
- Feature partity with C: 1 year
Total development time: ~2 years, 3 full-time developers.
Thanks for reading so far! Based on other conversations and forum threads, we think our work on Arti is of interest to the Zcash community. We’d like to hear from the community about this idea before we propose a grant to ZOMG, 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©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.)