Do you use sq or want to use it in the future? Please volunteer to
help guide its development.
Sequoia isn’t just a library. It just takes a library-first approach.
Sequoia’s command-line interface, which exposes a lot of the library’s
functionality, is called sq. It already exists in a basic form, but a
lot of functionality is missing. You can help with that.
The NLnet Foundation has granted me funding (from the NGI Assure
fund, financially supported by the European Council) to improve the
Sequoia sq program in three ways.
I will add important missing functionality, especially compared to GnuPG. This work will be guided by feedback from actual and potential users and the wisdom of Sequoia developers.
I will also add a JSON API to allow sq to be used from scripts.
Ideally, other programs would use the Sequoia library directly,
however, using sq from other programs should be easy and secure, and
JSON is a better format than parsing textual output or ad hoc
structured data formats
I will additionally document the acceptance criteria of sq and how
they are verified automatically, to make sure sq does the right
thing for its users, and to help keep sq working far into the
future.
I have now started the work, and am about to reach the first milestone.
Over the last months we’ve worked on adding support for OpenPGP card hardware tokens to Sequoia. OpenPGP cards (like the free Gnuk implementation, or e.g. Nitrokey and YubiKey devices) are great when you want to use an OpenPGP key, but don’t want the private key material stored on your computer. Advanced OpenPGP users have come to expect their software to support them.
Earlier this month, we connected a set of physical cards to our continuous integration (CI) machine and configured a job to run a test suite on these cards. This setup ensures that every change to our code is tested on a set of physical OpenPGP cards. The ability to test against multiple cards is essential, as cards implement different versions of the specification, and, on top of that, many have various quirks.
I’m pleased to announce a new release of the Octopus, an alternative OpenPGP backend for Thunderbird. This release brings several compatibility improvements with newer versions of Thunderbird, a few bug fixes, and some documentation improvements. And, it changes the Octopus’ license from the GPL to the LGPL to be consistent with our recent relicensing of the Sequoia libraries.
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.
We’re happy to announce that we’ve changed Sequoia PGP’s license from the GPL 2+ to the more permissive LGPL 2+. Simultaneously, we’ve also released version 1.5 of the openpgp crate under these terms.
We’re happy to announce the release of version 1.4 of our low-level OpenPGP library. The most prominent change is the addition of a new cryptographic backend based on the RustCrypto crates.
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.
Copyright (c) 2018-2023, p≡p foundation. 
This work is licensed under a Creative Commons Attribution 4.0 International License.
Follow us on Mastodon.
Template by Bootstrapious.
Ported to Hugo by DevCows.
Images by Ingo Kleiber, and Robert Anders.
