👋 Dear NGI-er:
Have you ever wondered about the challenges and opportunities in encryption and online security?
If your answer is yes, then this interview is perfect for you!
Meet Neal H. Walfield who has embarked on an ambitious journey with Sequoia PGP to expand and vitalize the OpenPGP ecosystem.
Curious about how Sequoia PGP addresses the complexities of modern cryptography and user needs?
✨Welcome to the world of Sequoia PGP✨
Can you introduce yourself and your project?
Sequoia PGP is a project that aims to expand and vitalize the OpenPGP ecosystem. Justus Winter, Kai Michaelis, and I started the project in 2017. The three of us had previously worked on GnuPG, the most common OpenPGP implementation at the time. In addition to working with GnuPG’s code, we interacted with developers integrating GnuPG into their programs, and spoke to end users.
The message that we heard was consistently twofold:
📌 First, there was a lot of excitement around GnuPG. People valued its goals of protecting privacy, and providing security, and its decentralized architecture.
📌 At the same time, there was a lot of frustration. GnuPG was brittle and too opinionated.
These opinions about how to correctly use GnuPG were acceptable as long as they solved the problem. But often, they only mostly solved the problem. The practical result was that the developer had to write hundreds of lines of code to bend GnuPG to their will. This is time-consuming and error-prone.
Unable and not wanting to usurp the project, but convinced that OpenPGP is pretty good, we decided to start a new project, Sequoia PGP.
A few fundamental design goals drive Sequoia PGP:
Our first design goal is that low-level interfaces should impose as little policy as possible.
High-level interfaces that introduce policy should be built on top of the low-level interfaces. Wherever possible, the high-level interfaces should use the same data structures as the low-level interfaces so that it is easy to tweak the behavior of the high-level interfaces when necessary.
As an example of this design philosophy, our core library does not implement a certificate store. Instead, it deals with certificates, and we have a separate library that implements a certificate store. Many programs use our certificate store, but stateless programs don’t want a persistent store, and server programs, which already have a database, don’t want a second one. This separation of concerns means that programs don’t have to work around functionality they don’t want, and can easily integrate OpenPGP into their existing architecture. For instance, a server program that wants to associate a certificate with a user just needs to add a column to an existing database table; no fancy acrobatics are required.
Another important design goal is to make interfaces safe by default.
We expose as much mechanism as reasonable but are careful to ensure that the simple solution is a safe solution. For instance, when serialising a certificate secret key material is stripped by default. Developers must explicitly opt-in if they want to export secret key material. This makes it harder to accidentally leak secret key material.
In Sequoia PGP, we are revisiting higher-level paradigms, and rethinking them when appropriate. For instance, historically, the web of trust was hard to use. We think this is because the available tools focused on high-risk threat models, which require a lot of input from the user. Yet, the web of trust can support a variety of threat models. Using the web of trust’s mechanisms, it’s straightforward to use certification authorities (CAs). This means it is easy to use global CAs as are used in the web PKI. But it is also easy to use organization-specific CAs.
Further, with the web of trust it is possible to partially trust CAs. For instance, Alice can say that she is willing to rely on a CA run by her bank to authenticate user IDs with a bank.com email address but no one else. These mechanisms can be used to create a federated CA system in which a person can delegate authentication judgments in such a way that the CA’s interests and their interests are mostly aligned.
We think that this will make strong authentication accessible to less technical people.
What are the key issues you see with the state of the Internet today?
There are three key issues that I see with the state of the internet today: commercialization, government overreach, and centralization.
I don’t think commercialization in the sense of commerce on the internet is fundamentally problematic. What is problematic is the degree to which business models are built on violating privacy.
There is a saying that if you aren’t paying for a product, you are the product. But this hasn’t been true for a few years: companies increasingly make people pay for a product and sell their personal data.
A horrible example is how car companies harvest and monetize driver data, as uncovered by the Mozilla Foundation. Data harvesting exposes everyone to danger but is terrible for vulnerable people. For instance, noyb has filed a complaint against Microsoft, saying that Microsoft 365 Education tracks children for advertising purposes.
A well-known example of government overreach is mass surveillance. This is a human rights violation and, as such, is non-negotiable. However, government overreach is not limited to that. Instead of patching vulnerabilities, governments are hoarding them, and coercing companies to add backdoors into their products. A poignant case is the backdoored Dual EC DRBG standard, which the US government convinced RSA, a large, influential American security company, to make the default in many of their products.
These problems are further exasperated by overtly authoritarian governments that make no pretence of respecting individuals’ human rights.
By centralization, I mean not only that there are large providers of a service but that the services are closed gardens designed to trap their users. We saw this with XMPP, a messaging protocol that supports federation. Google and Facebook both supported the XMPP messaging protocol and then removed it. Interoperability is essential. In this regard, I’m happy to see the recent success of the Fediverse.
We still have a long way to go, and the walled gardens make it hard to convince users to move.
How does your project contribute to correcting some of those issues?
Sequoia PGP is a set of tools for encryption and authentication based on interoperable standards. Sequoia PGP can help protect personal data from surveillance capitalism and government overreach when integrated into applications. It can also protect data integrity, including supply chain security, which can protect individuals from attacks.
Sequoia PGP is not the solution to these problems. Indeed, I reject the notion that there is a single solution or that the most important solutions will be technical. Instead, we need to build and nurture social movements.
I hope that Sequoia PGP can, on the one hand, help mitigate some of the technical problems and, on the other hand, help, in a small way, facilitate social movements.
What do you like most about (working on) your project?
Like most programmers, I enjoy solving a tricky technical problem or implementing a cool new feature. But what I like most about working on Sequoia PGP is a sense of doing something meaningful.
I’m deeply concerned about human rights like privacy, free speech, and personal security and how they are threatened by government overreach and surveillance capitalism. My primary goal with Sequoia PGP is to provide tools to help protect individuals.
This extends not only to personal communication but also things like decentralized supply-chain security in the form of Sequoia git.
Where will you take your project next?
In December 2020, we released version 1.0 of our low-level library. Since then, we’ve worked on the next layer of infrastructure—a certificate store, a key store, and a web of trust engine—and our CLI tool, sq.
We’ve invested a lot of time in sq to ensure that the CLI is usable. By usable, I mean that the mechanisms are understandable and the interface is internally consistent. In the coming months, we plan to release version 1.0 of sq.
Our next project is to revisit our low-level library. We will implement the upcoming OpenPGP and post-quantum cryptography standards, and clean up a bunch of mostly minor issues we’ve discovered in the API over the past few years.
We have two goals for 2025. We plan to add machine-readable output to sq so that it is easier to use from scripts. And, we will use our experience developing sq to create a user-friendly high-level library.
Along the way, we plan to continue helping projects integrate Sequoia PGP, as we are have done with the Swiss Government’s Sett program, the whistleblowing platform Secure Drop, and the RPM package manager, among others.
How did NGI Assure help you reach your goals for your project?
Sequoia PGP and some closely related projects received grants from NLNet between 2020 and 2022.
💫This was a significant help; we would not have come as far as we have without it.💫
Do you have advice for people who are considering applying for NGI funding?
I advise people applying for NLnet funding that it is not without risk. In particular, because NLnet funds projects, you must be careful with what you promise to deliver. Unfortunately, there is an incentive to promise more for your application to be more competitive.
🔥Try to resist this; you risk burning yourself out🔥
Do you have any recommendations to improve future NGI programs or the wider NGI initiative?
NLnet is doing fantastic work supporting the FOSS ecosystem, and I am grateful that NGI supports them. Keep it up!
My biggest hope for FOSS funders is that they will provide more sustainable funding. Currently, grants from NLNet are limited to 50k euro. Although this is non-trivial, it doesn’t provide the long-term financial stability many people need to work on FOSS as their day job.
As a project, we were lucky that the pEp Foundation provided us with a good and reliable financial base. This enabled us to use the money from NLnet to accelerate our work. In particular, we could use the pEp Foundation’s money to absorb the risk of a project failing (it happened) or taking longer than planned (they almost all did). Unfortunately, most FOSS projects don’t have a significant financial sponsor.
I think the FOSS ecosystem needs long-term, time-based funding, not project-based funding.
This would enable not only risk-tolerant people to finance their work but also the vast majority of the population who are reliant on a stable income, because they have a family, a mortgage, etc.
The Sovereign Tech Fund recently started exploring the idea of an Open Source Maintainer Fellowship. I think this is a great idea, and I hope we see many such programs in the future. Given that FOSS plays such a large role in our everyday lives, there is no reason that governments shouldn’t be sponsoring these fellowships and building physical FOSS centers to improve collaboration, as they finance academia and universities.
This isn’t a big ask. Whereas the German government paid over 1.3 billion euro in software licensing fees last year, the Sovereign Tech Fund, Germany’s most significant funder of FOSS projects, only received 17 million euro in 2024.
My second wish is that more funding would be explicitly oriented towards maintenance, documentation, and community building, and not only developing new features. New features are great, but if we agree that FOSS is providing the basis of much of our infrastructure, then we need to focus on making our infrastructure robust in both a technical and a social sense.
Finally, I am deeply disappointed in the European Commision. In the current draft of the Horizon Europe 2025 Work Program, the EC will cut the funding for FOSS projects despite an impact study showing how effective the money has been. This decision will put even more pressure on FOSS projects. Based on my discussions with various companies about financially supporting Sequoia PGP, I’m doubtful that the industry will step up.
