I’m reading about post-quantum encryption in PGP, and it appears that (for reasons unknown) GnuPG has recently implemented post-quantum PGP in a way that is deliberately incompatible with the post-quantum OpenPGP standard (now mainly developed by Proton & Sequoia-PGP).
The most compelling analyses of this situation I’ve seen suggest that the main reason for this is that GnuPG has such an old codebase with no integration testing that nobody outside of GnuPG really understand it, and the few developers who do are not confident about making changes to it. Alternatively (or additionally), there seems to be some petty/personal drama between GnuPG (at least the lead dev) and RFC9580 proponents (Sequoia, Proton).
SequoiaPGP is a modern re-implementation of the current OpenPGP standard (RFC9580, which supersedes RFC4880), written in Rust. I am unsure whether Proton uses Sequoia themselves, but at the very least Sequoia’s implementation is compatible with Proton’s. Sequoia PGP is also used by keys.openpgp.org which is the primary keyserver now used by PGP users by a wide margin.
For our purposes, Sequoia PGP has an sq command line tool with “good compatibility” with GnuPG:
They also have sequoia-chameleon-gnupg i.e. gpg-sq which is a drop in replacement for gpg:
Proton is one of the (if not the) most significant users of PGP at the moment, and maintaining compatibility with them should be considered essential, mainly for WKD/email users. I believe we also generally consider post-quantum cryptography to be important, and Sequoia PGP is the clear frontrunner in PQC PGP as far as I can tell. Fedora has switched to Sequoia for signing packages.
I think we should list both sq and sq-gpg (depending on use-case).
I also think we should not only remove GnuPG, but add a prominent warning against GnuPG. Given how important post-quantum encryption is, it would be dangerous & unfortunate for users to lock themselves into the GnuPG standard developed by essentially one man, instead of the OpenPGP standard.
Potential Problems
GnuPG is obviously a very widely used implementation.
RFC9580 drops a significant amount of legacy features, which is why LibrePGP (GnuPG’s new competitor to OpenPGP) was created in the first place.
Maybe most notably, the web of trust is removed(?), which I personally think is a shame. It’s unclear to me at this time whether OpenPGP supports some new form of web of trust, but my understanding is that switching to a v6 OpenPGP key will remove all existing web of trust signatures.
A primary reason people use PGP is backwards compatibility, and Sequoia/OpenPGP will intentionally not support some older forms of PGP, therefore will not be able to decrypt/read messages signed with older PGP keys. LibreGPG explicitly maintains all backwards compatibility with all of PGP.
Thunderbird only supports RNP, which in turn publicly supports LibreGPG (GnuPG’s new competitor to OpenPGP). Sequoia has built a full replacement for RNP for Thunderbird, but Thunderbird is choosing not to implement it. It’s unclear whether RNP will actually add support for either V5 or V6 at the moment.
Sequoia fully supports V4 signatures (and may even still default to them, I’m not sure) just like GnuPG, which means current & and modern PGP keys should be fully supported. The difference between OpenPGP and GnuPG appear to only be when it comes to post-quantum encryption, and when it comes to much older PGP keys with insecure settings.
Fedora/RedHat seems to prefer Sequoia and has switched to it for package signing.
Some PGP implementations have taken the time to support both v5 (LibrePGP) and v6 (OpenPGP/crypto-refresh) signatures.
Phil Zimmermann seems to prefer Sequoia, if you’re an appeal-to-authority type of person lol
If we approve this thread then we will have a few options. I would probably prefer the more conservative approach of #2 but I would be fine either way.
1
We would need to remove all three if we want to require PGP V6 (OpenPGP’s) PQC support, and recommend against PGP V5 (LibrePGP’s) PQC support.
As far as I know there are no RFC9580 GUI tools for Windows or macOS (unless you count Mailvelope). There is at least one potential replacement for OpenKeychain, although Thunderbird for Android and FairEmail on Android both require OpenKeychain exclusively as far as I know.
If we make this requirement, we should remove all three, and then discuss potential OpenKeychain replacements in a new thread. I believe we would have to recommend the CLI only for desktop users.
2
We could not require V6 signatures, and only require that recommended implementations don’t support LibrePGP/V5 key creation.
GPG4win is developed by GnuPG and would have to be removed. They added PQC support in January which is incompatible with OpenPGP.
I don’t think GPG Suite or OpenKeychain have explicitly pledged support for LibreGPG, meaning they could easily choose to adopt RFC9580 instead of LibreGPG.
As far as I know, they both only support V4 (and earlier) signatures for now, meaning they currently maintain compatibility with Sequoia PGP and therefore would not have to be removed at this time.
V4 is the most modern RFC 4880 standard which supports strong traditional cryptography (Curve25519 / Ed25519), but not PQC. As such, I don’t think it would be super dangerous to continue recommending both of these tools and V4 keys (especially since even Sequoia themselves still defaults to V4 for compatibility reasons for the foreseeable future).
We would simply have to note that people who want PQC at the expense of compatibility with GnuPG users can’t use these tools yet.
It is also still not clear to me how this squares with their stated support for LibrePGP over OpenPGP, but whatever. Maybe by “LibrePGP support” they simply mean V4 and aren’t pledging support for V5.
Thunderbird still does not (yet) support V6 though.
I’m also looking at rPGP, and there are some GUI tools which use rPGP and could therefore be recommended instead of GPG4win and GPG Suite on macOS, namely: https://gpgfrontend.bktus.com/
The German government does fully support OpenPGP RFC 9580, which is interesting since they’re probably the main users of GnuPG that are funding GnuPG’s work. It seems they are rejecting LibrePGP’s V5 entirely.
There’s another OpenPGP tool written in Go instead of Rust: https://gopenpgp.org/ - Proton develops this one and OpenPGP.js.
I said:
It’s unclear to me at this time whether OpenPGP supports some new form of web of trust
It definitely does, but upgrading to V6 means you’ll lose all your signatures. This is normal with PGP key changes, but usually when you upgrade PGP keys you can sign the new one with your old one. I don’t believe it is possible to sign a V6 key with a V4 key, so you are always losing your existing network sadly. (edit: idk I’ll just have to test it)
RFC 9580 lays the groundwork for PQC, but PQC in OpenPGP is actually defined in OpenPGP by RFC-to-be 9980 (draft-ietf-openpgp-pqc). This is the version Proton et al. is using, but is not officially a standard yet.
GnuPG could add support for this version of PQC, which would mean there would at least be one way for PQC communication to exist between GnuPG and OpenPGP users. However, during the time GnuPG supports V5 (and if they never support V6) it still remains possible for people to generate incompatible PQC keys, so we still should be explicitly recommending against GnuPG and V5 keys.
This is a pivotal time for encryption and for quite a while now I’ve been telling myself that I need to stop being lazy and re-encrypt everything I have in cloud storage as well as delete the old account that I was using, with the old encryption, and use a different provider with ‘safe’ encryption implemented on my end before upload.
You make really good points and I’m glad someone has researched it and posted about it. As The Man With No Plan, I’m lazy by nature and therefore support any idea that is well thought out, makes sense, and in this case addresses something that we take for granted yet is sort of paramount in it’s importance. The only thing that jumped out was Proton’s support and my paranoid skepticism jumped out immediately with the thought “Those sneaky bastards may have already pulled a Google and gone evil… they’ve probably already sold us all out AND they’re probably going all political on a walled garden of encryption that will be normalized, so we need to be careful!” but on second thought, that sounds pretty stupid given the context of a company that’s just trying to use encryption that’s both good and well supported, just like the rest of us.
I would say something here. Not because I think it is wrong. Rather because from brief reading on this topic I got some misconception that is pretty common, I guess.
Many speakers discuss it the way it seems that
RFC 9580 (v6) = PQC,
RFC 4880 (v4) = lack of PQC security.
But it is not the case: we already can use KEM-768+X25519 with v4. And most of us won’t use other algos even with v6. KEM-768+X25519 is just a reasonable choice in most cases.
GPG supports KEM-768+X25519 right now. Seqsequoia-sq needs to be recompiled with a special flag to use it. Literally, GPG makes PQC more easy and accessible today. (While yes, generally, I believe sq does a lot for the future of this technology.)
Is is easy to miss the fact that PQC is already accessible and has not so much to do with v4/v5/v6 debates . At least for privacy(signing is more complicated).
I feel this misconception is used to push people to implement/use v6 ASAP. Following discussion is pretty important:
Aron: GnuPG allows to attach a v5 PQC ML-KEM encryption subkey to a v4 key. With v4 ML-KEM subkeys we provide an alternative that is even compatible with v4. For full PQC compliance signatures are also needed.
Kai: As soon as RNP provides stable v4 PQC encryption, it can be integrated in Thunderbird. I want to see PQC support in Thunderbird ASAP, but I don’t think it will come fast. First we need replacement keys mechanism.
Andrew: Repl. keys is needed for v6, not v4 PQC.
Kai: v4 PQC support in Thunderbird could be there maybe end of the year.
Most of the clients are going live with v4 PQC for years, if not decades - that is my bet. forcing users to switch to v6 practicaly means “Use Proton and nothing else”. As no single other email client works with v6. From the same discussion:
Aron: there is v4->v6 migration and traditional->PQC migration. Let’s focus on the latter. Proton will bundle both transitions together because PQC is a user-measurable upgrade and selling point.
Ok, one does, Parula, which author said a few words in the same discussion. And while the client is pretty interesting, I don’t think it changes much for the described landscape.