OpenPGP in Rust: the Sequoia project

In 2018, three former GnuPG developers began work on Sequoia, a new implementation of OpenPGP in Rust. OpenPGP is an open standard for data encryption, often used for secure email; GnuPG is an implementation of that standard. The GPLv2-licensed Sequoia is heading toward version 1.0, with a handful of issues remaining to be addressed. The project's founders believe that there is much to be desired in GnuPG, which is the de facto standard implementation of OpenPGP today. They hope to fix this with a reimplementation of the specification using a language with features that will help protect users from common types of memory bugs.

While GnuPG is the most popular OpenPGP implementation — especially for Linux — there are others, including OpenKeychain, OpenPGP.js, and RNP. OpenPGP has been criticized for years (such as this blog post from 2014, and another from 2019); the Sequoia project is working to build modern OpenPGP tooling that addresses many of those complaints. Sequoia has already been adopted by several other projects, including keys.openpgp.org, OpenPGP CA, koverto, Pijul, and KIPA.

Sequoia was started by Neal H. Walfield, Justus Winter, and Kai Michaelis; each worked on GnuPG for about two years. In a 2018 presentation [YouTube] (slides [PDF]) Walfield discussed their motivations for the new project. In his opinion, GnuPG is "hard to modify" — mostly due to its organic growth over the decades. Walfield pointed out the tight coupling between components in GnuPG and the lack of unit testing as specific problem areas. As an example, he noted that the GnuPG command-line tool and the corresponding application libraries do not have the same abilities; there are things that can only be done using the command-line tool.

Community is a big part of the Sequoia project, as Walfield explained in his presentation. The project is financially backed by the p≡p (pep) and Wau Holland foundations, with "all development done in the open". Before code was even written, the project founders met with prominent members of the OpenPGP community as well as end users to discuss the project's plans and make sure their approach was sound. The project's current status, Git repository, and issue tracker are all available. The repository logs indicate approximately 30 contributors to the project and, since announcing the pending version 1.0 release in April 2020, three releases have been made. The latest release, version 0.19.0, was made in August 2020 — its most notable improvement is the inclusion of Windows Cryptography API: Next Generation (CNG) as a backend, replacing Nettle which has issues in non-POSIX environments.

Because it is written in Rust, Sequoia benefits from all of the memory-safety advantages that the language provides. The repository shows significant efforts are being made to write unit tests to prevent regressions and improve quality. Unlike GnuPG, where the command-line gpg tool is more powerful than the library, Sequoia is an OpenPGP library first; all of its functionality is available via the exposed APIs. The project plans to provide two "levels" of API, a low-level unopinionated implementation of the OpenPGP specification and a high-level API with sensible defaults to make common tasks like signing and signature verification easier for users. Walfield's presentation was clear that, while the project endeavored to be unopinionated on the low-level API implementation, it does avoid the outdated parts of the specification such as the use of MD5 hashes.

Sequoia is targeted at "modern platforms" including Linux, Windows, macOS, Android, and iOS. When possible, this includes using existing cryptographic tooling; it is a design goal of the project to tightly integrate with platform-specific cryptographic services. For example, Sequoia plans to make use of the Secure Enclave coprocessor on iOS devices when available. It also provides a foreign function interface (FFI) for integrating the project with programs written in other languages. Currently, Sequoia offers C and Python FFI bindings. Readers should note that programs using the bindings lack memory safety, so the project's rules must be followed in order to use them correctly.

Walfield responded to my question on the Sequoia development mailing list with information about the current state of the project and the upcoming version 1.0 release:

This means readers shouldn't expect Sequoia to be an end-user replacement for tools like GnuPG just yet; the first major release will be focused on a library for developers. For the project to be ready for end users, it will need the equivalent of the gpg command found in GnuPG. For Sequoia, this is the sq command-line tool, which is not included for version 1.0. Walfield described sq as "missing quite a bit of functionality," explaining "we want to reserve the right to change its interface" before it is released to the public.

The sq tool isn't the only thing missing from the version 1.0 release; key-storage services are still in progress. According to Walfield, it is one of the project's "top priorities" after the version 1.0 release.

Key storage is one of the areas where Sequoia's plans are unique compared to other OpenPGP implementations. For added security, the project plans to use process separation between the services handling public and private keys; Cap'n Proto will be used for interprocess communication. Walfield notes in his presentation that process separation is not always possible, such as in iOS environments. When it is unavailable, Sequoia plans to use a shared SQLite database to communicate between the two services in a process Walfield described as "colocation".

Conceptually, Sequoia takes an identity-based approach to its public keyrings, where the keyring is designed to be "more like a per-domain address book than a PGP keyring." Keys are designed to be stored and accessed using a user-assigned Petname, with the ability to associate arbitrary structured data that will be useful in the implementation of trust models. Walfield also argues that this approach is more in line with how users actually think about keys: associated with names, rather than a collection of abstract IDs. Further, all keys are assigned a "realm" in Sequoia indicating the intended purpose of the key; presently realms include "contacts" and "software update key" designations. When completed, Sequoia's keyring service will automatically update public keys from remote servers (similar to parcimonie), ensuring that changes like new sub-keys and revocations are discovered in a timely fashion. The API documentation indicates this can be done using anonymized services like Tor in addition to more common TLS-encryption methods.

The private keyring service is slated to offer an optional one-password solution for unlocking local keys. The library will provide access to the private keyring using what Walfield describes as a "Smartcard-like" API. Currently Sequoia does not support Smartcards, but based on this ticket, the community would like to see it happen in the future. Sequoia's private keyring service will be written with forward secrecy in mind, by using the OpenPGP specifications supporting the distinction between data "at rest" (encrypted storage) and data "in motion" (encrypted transmission), which is not found in many other implementations. It is a sound security practice to frequently rotate "in motion" keys, but that needs to be done in a way that still allows archived encrypted data to be decrypted. A presentation (slides [PDF]) by Winter compares the project's forward secrecy features to other OpenPGP implementations.

Wrapping up

Those who are interested in getting involved in the project should be aware that it requires contributors to assign their copyright to the p≡p foundation. The project further states that code may then end up being published under multiple licenses, but "all software is also published under a GNU License as Free Software, without exception."

In all, it is good to see a project focused on making OpenPGP a more easily accessible technology, and it looks like the project has made steady progress since it started almost three years ago. The project's documentation also provides a reasonable starting point to using the library in applications. That said, Sequoia has a ways to go before it will be a trusted cryptographic tool; for starters, the code still needs to be audited. The project's status page states it has "has not been audited yet, but as soon as we release the core Sequoia crate, it will be audited by a third party." Readers may be interested in checking out the project's contributors page, which provides details on their mailing list and IRC channel. As Walfield said, there isn't a timetable for when Sequoia version 1.0 will land, but it does sound like it will be soon. End users of OpenPGP will still have to wait a bit longer, however, before Sequoia becomes a viable alternative.