Arti: a pure-Rust Tor implementation for Zcash and beyond

Applicant background

We’re the Tor Project: we’ve been developing the Tor since 2002. We’ve grown Tor to anonymize millions of users over thousands of volunteer-operated relays. Nick Mathewson, Tor cofounder and original developer of Arti, will direct this work.

Motivation and overview

Tor provides robust network-level privacy, hiding traffic among millions of Tor users. Thus, it fits as a "missing piece" of the Zcash privacy story–as a communications privacy layer for Zcash, and for other tools that Zcash users employ.

Tor is deployed, well established, and well analyzed, and works with most any TCP-based protocol. Our performance is improving over time, and we layer with an ecosystem of anticensorship tools.

But the current Tor implementation bears signs of its age. Tor is implemented in C, as a standalone network proxy. This makes it cumbersome to embed. And because Tor is written in C, security is risky, and we need to be meticulously careful when writing new code.

We’re solving these issues with Arti, a Rust implementation of the Tor client protocols. We hope Arti will replace our C, and thereby help Zcash protect users from surveillance and censorship. Arti will make the Tor protocols easier to embed, to develop, to adjust, and to use.

Technical approach

Today, Arti is a working Tor client, but is not yet fully secure, featureful, efficient, or usable. We will close these gaps one-by-one as roadmapped below. We hope to work together with developers from Zcash-related projects to refine those milestones and deliver a usable product.

Architecturally, Arti’s high-level crates provide a set of async/await APIs for connecting through the Tor network; lower-level crates provide fine-grained control over specific behavior. We separate networking from domain logic, to make our code more testable and portable.

diagram

For further information about Arti see https://gitlab.torproject.org/tpo/core/arti/ . For the Tor protocols, see https://gitlab.torproject.org/tpo/core/torspec/ .

Execution risks

Arti is our first major Rust project. Though we’ve been learning as we go, we may still make a few Rust mistakes. Depending on funding, we may be able to hire experienced Rust developers to assist.

Since Arti is embeddable, we face risks in defining stable APIs: we must provide everything users need, but nothing that hinders us long-term. We’re mitigating this risk by rolling out APIs through a gated process, carefully distinguishing between stable and unstable APIs.

We have to support our C code until Arti can replace it, and address emerging attacks, network issues, research findings, etc. Thus, a sudden issue may distract us from Arti while we resolve it. To mitigate somewhat, we will try to avoid new features in the C implementation while Arti is under development.

We depend on users for feedback about our design choices. This work will rely particularly on feedback from downstream developers about our APIs. In case our existing contacts within the Zcash ecosystem become busy or distracted, we are also in contact with other users who can comment and assist.

Downsides

Even though Arti will be more maintainable and usable than our C code, it will inevitably be less mature. Thus it will likely have some bugs or deficiencies at first, due to loss of implicit knowledge currently embodied in the C implementation.

Evaluation plan

Our goal is successful deployment. Success means that Zcash ecosystem developers will be able to embed Arti for improved network privacy, with minimal hassle.
We will measure Arti’s latency, throughput, and memory usage against our C implementation, and aim for equivalent or better performance.
Our security will be evaluated via external code audit.

Schedule and Milestones

Our timeline is based on feedback from our Zcash forum post, and assumes three full-time developers. For specifics, see https://gitlab.torproject.org/tpo/core/arti/-/milestones .

0.0.1: Minimally secure release. Won’t wreck your privacy. Alpha APIs. (4 months)
0.1.0: Beta-level usability and embedding, suitable for giving to users and gathering experience. (4 months)
1.0.0: Production-ready for general use and embedding. (6 months)
1.1.0: Censorship resistance. (1 month)

Removed:

1.2.0: Onion service support. (6 months)
2.0.0: Full-featured release, to replace the C tor client for all purposes. (9 months)
Security audit by an external team

Budget and Payout Timeline

We budget for $44,800 per month. This is based on 3 developers at an average of $13,267 per month, 10% of a project manager’s time at $10k per month, and 10% overhead. Thus our budget is:

0.0.1: $179,520
0.1.0: $179,520
1.0.0: $269,280
1.1.0: $44,880

Removed: