NLnet recently held a webinar on the future of OpenPGP. The Sequoia team made five short presentations. In addition to an introduction summarizing the past, present, and future of Sequoia, we presented four of our current projects, which provide a nice cross section of our current work.
The EFAIL attacks demonstrate that securing email is hard. Incautious improvements to usability can lead to critical security vulnerabilities. In the case of EFAIL, an attacker could exploit mail clients that show corrupted messages to exfiltrate a message’s plain text.
Although the EFAIL researchers are measured in their response, others, like Thomas Ptacek in his widely cited articles The PGP Problem from 2019, and Stop Using Encrypted Email from 2020, are calling for people to abandon OpenPGP, and give up on secure email. Instead, they argue, people should use secure messengers like Signal.
In 2017, Moxie Marlinspike and Trevor Perrin were awarded the The Levchin Prize for Real-World Cryptography for developing the Signal protocol. It’s a well-earned honor and I have no doubt that Signal is the best practical in-class encryption scheme for messaging that the cryptographic community knows about.
But, securing communication requires more than encryption. The sender also needs to make sure the public keys that they intend to use are the right keys for the intended recipients. This check is called authentication. If the sender uses the wrong public key then either the recipient won’t be able to read the message, or worse, an active attacker could intercept the message, and reencrypt it on the fly so that the connection appears to be secure when in fact someone is eavesdropping.
We’re happy to announce the release of version 1.3 of our low-level OpenPGP library. For those of you following along at home, you’re probably asking what happened to 1.2. This past Sunday was PGP’s 30th birthday. To celebrate three decades of PGP, we’ve decided to skip 1.2 and directly release 1.3.
In a blog post that I published two weeks ago, I wrote that RNP is dangerous, because it is too easy to misuse. I also explained how we avoid those problems in Sequoia. In this blog post, I will lay out how not one, but two CVEs have since come up in Thunderbird that seem to underline that danger.
OpenPGP CA is a tool for administrators to create and manage a decentralized, in-house certification authority. OpenPGP CA makes it possible and easy for an organization to delegate authentication decisions to someone they can rely on, like their system administrator. And, external groups and individuals can use these CAs to authenticate certificates for just that organization using OpenPGP’s scoped trust signatures. OpenPGP CA also helps with key discovery and key updates by managing a Web Key Directory (WKD).
I was recently talking to a Thunderbird developer about API design. In the course of that conversation, I expressed concerns about RNP, the new OpenPGP implementation that Thunderbird has recently started using in place of GnuPG. That person, skeptical about my assertion that RNP’s API needs improvement, asked “Isn’t it subjective what a better API is?” I’d agree that we don’t yet have good metrics to evaluate an API. But, I disagree that we can’t judge APIs at all. In fact, I suspect, most experienced programmers know a bad API when they see it. Further, I think we can come up with some good heuristics, which I’ll try to do based on my experience working on and with GnuPG, Sequoia, and RNP. Then, I’ll take a look at RNP’s API. Unfortunately, RNP’s API is not only easy to misuse, but it’s misleading, and, as such, shouldn’t yet be used in a safety-critical context. Yet, Thunderbird is relied on by vulnerable people like journalists, activists, lawyers, and their communication partners who need this protection. For me, this means that Thunderbird should reevaluate their decision to use RNP.
We are thrilled to release the first version of the Octopus, an alternate OpenPGP backend for Thunderbird built on top of Sequoia.
The Octopus is a drop-in replacement for RNP, the OpenPGP library shipped with Thunderbird 78. In addition to providing all of the RNP functionality that Thunderbird uses, the Octopus also includes a number of enhancements. These fall into several categories. The Octopus restores some functionality that was present in Enigmail, but removed or has not yet been reimplemented in Thunderbird’s OpenPGP integration. In particular, the Octopus uses GnuPG’s keystore, interacts with gpg-agent, integrates GnuPG’s web of trust information, and updates certificates in the background. The Octopus includes a number of security fixes and improvements. For instance, it fixes Thunderbird’s insecure message composition, and automatically encrypts in-memory secret key material at rest. The Octopus adds a few performance improvements, such as, parsing the keyring in the background and using multiple threads. And, the Octopus has better support for parsing less usual, but not necessarily esoteric, certificates and keys.