Project site for Sequoia PGP, a Rust implementation of OpenPGP with a command-line tool called sq.
Commenters suggest it as a cleaner alternative to GnuPG for those set on PGP. One notes its sq CLI reached v1.0 in December 2024.
You can look at this https://sequoia-pgp.org/blog/2021/06/29/202106-yes-we-want-cryptographic-protection-for-email/
I quote a section that corresponds to my situation
>Email is everyone’s primary trust anchor online
>If a user loses access to an online account, most services have an account recovery mechanism that will let the user back in. Usually, this works by sending an email to the user with a one-time password.
>If an attacker compromises a user’s email account, they can use the same mechanism to gain control of the user’s account on any service that uses the email account as a trust root. In practice, that’s most of the user’s online accounts. Unfortunately, two-factor authentication only offers limited protection. It is opt-in and usually uses a phone number, which is easily hijacked.
>If account recovery emails were encrypted, the trust anchor would instead be the encryption key. Since the encryption key is stored on the user’s computer, this would defeat this type of attack.
People have thought about how to do forward secrecy with PGP:
https://sequoia-pgp.org/talks/2018-08-moving-forward/moving-forward.pdf
https://sequoia-pgp.gitlab.io/openpgp-dr/openpgp_dr/index.html
https://github.com/stealth/opmsg
https://github.com/autocrypt/autocrypt/issues/444
There's a lot going on in the space. It is more innovative than you're giving it credit for, especially around double ratchet. Not there yet, but there's a good reason why I don't mind: control. Multi client support (DeltaChat desktop, hallelujah) and the fact that email remains federation-first.
My identity definitely leaks to my server because I pay it's bill. Not only that, but most of my contacts run their own email or borrow it from me or someone else. Our data does not leave any EU countries apart from the UK. We have IM that doesn't involve any Americans.
Some might imagine we feel terribly smug about that right now :)
As mentioned a few days ago, this post mainly covers a gpg problem not a PGP problem.
I recommend people to spend some time and try out sequoia (sq) [0][1], which is a sane, clean room re-implementation of OpenPGP in Rust. For crypto, it uses the backend you prefer (including openssl, no more ligcrypt!) and it isn't just a CLI application but also as a library you can invoke from many other languages.
It does signing and/or encryption, for modern crypto including AEAD, Argon2, PQC.
Sure, it still implements OpenPGP/RFC 9580 (which is not the ideal format most people would define from scratch today) but it throws away the dirty water (SHA1, old cruft) while keeping the baby (interoperability, the fine bits).
[0] https://sequoia-pgp.org/
[1] https://archive.fosdem.org/2025/events/attachments/fosdem-2025-6297-a-practical-introduction-to-using-sq-sequoia-pgp-s-cli/slides/237970/presentat_pvYEqR5.pdf
I can understand the desire to shake off the burden of compatability with PGP - but maybe not if sticking to the same design, and just shifting encryption primitives somewhat?
If you want PGP - there's the sequoia project to consider as well:
https://sequoia-pgp.org/
The "stateless cli tool"[1] looks like it's mostly complete for sign/encrypt etc now?:
https://gitlab.com/sequoia-pgp/sequoia-sop
sqop generate-key julia@example.org > julia.secret.pgp
sqop extract-cert < julia.secret.pgp > julia.public.pgp
echo "a message" | sqop encrypt julia.public.pgp > message.pgpo
sqop decrypt julia.secret.pgp < message.pgp
a message
[1] https://www.ietf.org/archive/id/draft-dkg-openpgp-stateless-cli-02.html
Apparently expired? Was sop abandoned?
This is mostly about the usability issues that make such attacks work so well on Signal:
https://www.ndss-symposium.org/wp-content/uploads/2018/03/09-when-signal-hits-the-fan-on-the-usability-and-security-of-state-of-the-art-secure-mobile-messaging.pdf
This adds some detail about how Signal can do MITM attacks:
https://sequoia-pgp.org/blog/2021/06/28/202106-hey-signal-great-encryption-needs-great-authentication/
Some of the details might of changed since publication. My current understanding is that Signal doesn't even bring up the idea of identity verification if a user has not previously done it. So if anything, things have gotten worse.
It's not a tutorial in the classic sense, but as the CLI is rather simple, and as there are examples, I'd point you at the official docs (man page like):
https://docs.sequoia-pgp.org/sq/index.html
The sub commands feel like they are pretty much self-explanatory to me, e.g., encrypt, decrypt, verify are pretty clear in what they will do, and the options for those sub-commands seem not to cryptic either to me, but that's naturally a bit opinionated.
Besides that the initial release news article of the sq tool has some quick demo:
https://sequoia-pgp.org/blog/2021/01/26/202101-sq-release/
What would be your use cases for sq?