Website
Short description
OpenPGP reimplementation in Rust
Why I think this tool should be added
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 now 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 obviously the biggest user 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
sqandsq-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.
-
-
GnuPG’s rebuttal to Sequoia: My thoughts on Sequoia PGP and LibrePGP
-
Thunderbird only supports RNP, which in turn only supports LibreGPG (GnuPG’s new competitor to OpenPGP). Sequoia has built a full replacement for RNP for Thunderbird, which Thunderbird will not implement themselves.
- Additional discussion on this: Topicbox
-
GnuPG is certified for government use in some EU/NATO countries.
Misc.
-
Additional information: A schism in the OpenPGP world - #4 by beantaco
-
A schism in the OpenPGP world [LWN.net] (also, GnuPG maintainer’s comment on this article)
-
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
Section on Privacy Guides
Encryption tools