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-20...

▲

SahAssar 4 days ago | parent | next [-]

But if you use the modern crypto stuff you loose interoperability, right? What is the point of keeping the cruft of the format if you still won't have compatability if you use the modern crypto? The article mentions this:

> Take AEAD ciphers: the Rust-language Sequoia PGP defaulted to the AES-EAX AEAD mode, which is great, and nobody can read those messages because most PGP installs don’t know what EAX mode is, which is not great.

Other implementations also don't support stuff like Argon2.

So it feels like the article is on point when it says

> You can have backwards compatibility with the 1990s or you can have sound cryptography; you can’t have both.

▲

zimmerfrei 4 days ago | parent [-]

When you encrypt something, you are the one deciding which level of interoperability you want and you can select the crypto primitives matching capabilities you know you recipient reasonably have. I don't see anything special with this: when you run a web service, you also decide if you want to talk to TLS 1.0 clients (hopefully not).

sequoia's defaults are reasonable as far as I remember. It's also bit strange that the post found it defaulted to using AEAD in 2019 when AEAD was standardized only in 2024 with RFC 9580.

But the elephant in the room is that gpg famously decided to NOT adopt RFC 9580 (which Sequoia and Proton do support) and stick to a variant of the older RFC (LibrePGP), officially because the changes to the crypto were seen as too "ground-breaking".

▲

woodruffw 4 days ago | parent [-]

I think GP’s point isn’t that you don’t have the freedom to decide your own interoperability (you clearly do), but that the primary remaining benefit of PGP as an ecosystem is that interoperability. If you’re throwing that away, then there’s very little reason to shackle yourself to a larger design that the cryptographic community (more or less) unanimously agrees is dangerous and antiquated.

▲

zimmerfrei 4 days ago | parent [-]

It is not a coincidence that most of the various proposed alternatives to PGP (signal, wormhole, age, minisign, etc) are led by a single golden implementation and neither support nor promote community-driven specifications (e.g., at the IETF).

Over the decades, PGP has already transitioned out of old key formats or old crypto. None of us is expecting to receive messages encrypted with BassOmatic (the original encryption algorithm by Zimmermann) I assume? The process has been slow, arguably way slower than it should have after the advancements in attacks in the past 15 years (and that is exactly the crux behind the schism librepgp/opengpgp). Nonetheless, here we are, pointing at the current gpg as "the" interoperable (yet flawed) standard.

In this age, when implementations are expected (sometimes by law) to be ready to update more quickly, the introduction of new crypto can take into account adoption rates and the specific context one operates in. And still, that happens within the boundaries of a reasonably interoperable protocol.

TLS 1.3 is a case in point - from certain points of view, it has been a total revolution and break with the past. But from many others, it is still remarkably similar to the previous TLS as before, lots of concepts are reused, and it can be deemed as an iteration of the same standard. Nobody is questioning its level of interoperability, and nobody is shocked by the fact that older clients can't connect to a TLS 1.3-only server.

	▲	tptacek 4 days ago \| parent [-]
		You're right, it's not a coincidence. The track record of standards-body-driven cryptography is wretched. It's why we all use WireGuard and not IPSEC. TLS 1.3 is an actually good protocol, but it took for-ev-er to get there, and part of that process involved basically letting the cryptographers seize the microphones and make decisions by fiat in the 1.2->1.3 shift (TLS 1.3 also follows a professionalization at CFRG). It's the exception that proves the rule. It's contemporaneous sibling is WPA3 and Dragonfly, and look how that went.

▲

tptacek 4 days ago | parent | prev [-]

I wrote the post and object to the argument that it primarily covers GnuPG issues.

But stipulate that it does, and riddle me this: what's the point? You can use Sequoia set up for "modern crypto including AEAD", yes, but now you're not compatible with the rest of the installed base of PGP.

If you're going to surrender compatibility, why on Earth would you continue to use OpenPGP, a design mired in 1990s decisions that no cryptography engineer on the planet endorses?

▲

zimmerfrei 3 days ago | parent [-]

If you use AEAD, you clearly expect your recipients to use a recent client. Same as if you want to use PQC or any other recent feature.

If your audience is wider, dont use AEAD but make sure to sign the data too.

With respect to the 90's design, yes, it is not pretty and it could be simpler. It is also not broken and not too difficult to understand.

	▲	tptacek 3 days ago \| parent [-]
		You're missing my point. I agree that you can use Sequoia to communicate between peers also using Sequoia. But you're no longer compatible with the overwhelming majority of PGP deployments. So what's the point? Why not just use a modern tool with that same group of peers?