#librepgp — Public Fediverse posts

Post-quantum defaults and GnuPG

@andrewg email is a very insightful overview of where the standards, implementations, and openness of the community.

After years of using OpenPGP, the PQC discussions are a good opportunity to rethink what we should prepare for next and especially which community we should work with.

#pgp #librepgp #openpgp #opensource
#community #cybersecurity

🔗 https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068280.html

@ber @GnuPG @rob Thanks! I'll point the lurkers to the mailing list for my full response, which I agree is better in long form: https://lists.gnupg.org/pipermail/gnupg-users/2026-April/068288.html

The tl;dr though is simple: the burning issue is a power struggle between a collective governance model (#OpenPGP) and a BDFL governance model (#LibrePGP). There isn't room for both. And while we can all try to be more civil, calling out bad behaviour will always have the appearance of incivility.

When looking at the changes towards the new 2.5.19 version of #GnuPG, there are many small things; like a way to use OCB for symmetric-only encryption, a few defect fixes and improvements.

Not that exciting, but maintenance of the well known #LibrePGP, OpenPGPv4 and CMS capable crypto engine.... you may want to know anyhow. ;)

https://lists.gnupg.org/pipermail/gnupg-announce/2026q2/000504.html
https://dev.gnupg.org/T7998

#GnuPG #EndtoEndCrypto #FreeSoftware

Dear GnuPG packagers and builders, please upgrade libgcrypt to v1.12.2 to remove a denial of service vulnerability (estimated CVSS 3.1: AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H -- 7.5 (HIGH)) Releases of other stable versions of libgcrypt are available as well.

(GnuPG versions >= 2.5.7 are not affected due to the use of a different encryption API.)

See https://lists.gnupg.org/pipermail/gnupg-announce/2026q2/000503.html for details.

#GnuPG #EndtoEndCrypto #FreeSoftware #LibrePGP

Details about the (ongoing) response to https://gpg.fail/ from GnuPG's side:

* https://www.gnupg.org/blog/20251226-cleartext-signatures.html
* https://dev.gnupg.org/T7906 Memory Corruption in ASCII-Armor Parsing
* https://dev.gnupg.org/T7900 (overview)

Please upgrade to GnuPG 2.5.16, 2.4.9 or #Gpg4win 5.0.0-beta479 which already have the fix for what (currently) is seen to be the only major defect: T7906.

(Researchers - Thanks! - found defects in GnuPG, Sequoia-PG, Minisign and age.)

#EndtoEndCrypto #LibrePGP #GnuPG #Security

#GnuPG v2.5.14 is here to try.

A no-brainer upgrade for those who use the 2.5 series already. You'd get some defects fixed and a new secret key export-import for the Post quantum cryptography (#PQC) algorithm "Kyber". RCF8332 for ssh is now supported.

For others: the 2.5 series is good for Windows 64 and PQC. #LibrePGP #OpenPGPv4 #EndtoEndCrypto

https://lists.gnupg.org/pipermail/gnupg-announce/2025q4/000499.html

@Velocifyer @andrewg That's the reason for my plans to switch from #GnuPG to #sequoiapgp, not the #LibrePGP vs #RFC9580 mess. If a RTFM doesn't suffice and it comes down to RTFC (...Code), I am out.

See GnuPG manpage:

❯ gpg --version | head -n 1
gpg (GnuPG) 2.5.13
❯ man gpg | sed -n '/^[[:space:]]*dane/,/^$/p'
              dane   Locate a key using DANE, as specified in draft-ietf-dane-openpgpkey-05.txt.

... and:

The lookup result MUST pass DNSSEC validation; if validation reaches any state other than "Secure", the verification MUST be treated as a failure.

Source: https://datatracker.ietf.org/doc/html/draft-ietf-dane-openpgpkey-05#section-5

@DD9JN ... and #GnuPG v2.5.13 is a production ready version with improvements for PQC encryption and Windows.

This version comes with a few smaller security improvements over the previous release, and reduces problems if several applications use GnuPG as crypto engine in the background.

#OpenPGPv4 #LibrePGP #EndtoEndCrypto #FreeSoftware

No to poprawcie mnie, jeżeli się mylę, co do aktualnego stanu #OpenPGP.

Po pierwsze, jest dawne #RFC4880bis, aktualnie przepychane jako "#LibrePGP", używane przez #GnuPG (i #rnp?), z formatem kluczy "v5" — i zdaje się, że każdy inny projekt spogląda na to z politowaniem.

Po drugie, jest #RFC9580 z formatem kluczy "v6", używany przez #OpenPGPjs, #SequoiaPGP (i inne narzędzia), ale odrzucony przez GnuPG. I wygląda na to, że jest przepychane z założeniem, że GnuPG ugnie się pod presją.

Więc mamy dwa niezgodne ze sobą standardy, ze "wspólnym mianownikiem" w postaci zabytkowego #RFC4880; jedne narzędzia przepychają jeden standard i ignorują drugi, a inne decydują się wspierać oba, by pomóc swoim użytkownikom. A #Gentoo ostatecznie utknie z tym, co wspierać będzie GnuPG, bo potrzebujemy kryptografii, która działa na wszystkich wspieranych platformach, a nie tylko tam, gdzie Rust.

https://bugs.gentoo.org/963069

Okay, so please correct me if I'm wrong about the state of #OpenPGP right now.

So first there's the former #RFC4880bis which is now pursued as "#LibrePGP", used by #GnuPG (and #rnp?), with a "v5" key format, that everyone else seem to looks "politely" at.

Then there's #RFC9580 with a "v6" key format, used by #OpenPGPjs, #SequoiaPGP (and more) but explicitly rejected by GnuPG. However, it seems to be pushed forward under the assumption that GnuPG will yield to pressure.

So we effectively have two incompatible standards, with a "common denominator" of ancient #RFC4880, some tools pursuing one of them with disregard for the other, and a few supporting both for the sake of the users. And #Gentoo is effectively stuck with whatever GnuPG supports, because we need working crypto on all supported platforms, not just the "Rust subset".

https://bugs.gentoo.org/963069

Back from the summer, #GnuPG 2.5.12 is now ready for production usage.
And this includes the post-quantum cryptography encryption (#PQC) support which is the main feature of the 2.5 series. (Okay, there is also better support for 64bit Windows.)

So give it a spin or point your favourite GNU/Linux distribution to it for packaging.

https://lists.gnupg.org/pipermail/gnupg-announce/2025q3/000497.html

#EndtoEndCrypto #LibrePGP #OpenPGPv4
#FreeSoftware

#GnuPG's "public testing release series" has a new version 2.5.7.

https://lists.gnupg.org/pipermail/gnupg-announce/2025q2/000493.html

Remember:

* It is for you, if you want to test the new
post-quantum cryptography (PQC) features
or the 64 Bit Windows support.

* The series features Kyber (FIPS-203) as PQC encryption algorithm.

A new Gpg4win 5 Beta is forthcoming in the next days.

Technical details: https://dev.gnupg.org/T7671

#LibrePGP #OpenPGPv4 #EndtoEndCrypto

Better handling of certificates and public keys
with #Gpg4win v4.4.0's improved crypto manager _Kleopatra_.

It also comes with #GnuPG v2.4.7 for Windows. Workflows that profit from several signatures on a file
profit as well.

https://gpg4win.org/version4.4.html <-- see what else is new.

#LibrePGP #OpenPGPv4 #EndtoEndCrypto #FreeSoftware

LWN.net weist auf eine drohende Spaltung der #OpenPGP -Welt hin, woran eigentlich niemand Interesse haben kann (siehe auch deren Posting). Soweit ich es verstanden habe, geht es um die Aktualisierung von RFC 4880. Eine Working Group, der auch Werner Koch (Autor von #GnuPG )  angehörte, hat an einer Aktualisierung jahrelang gearbeitet und, so die Aussage, zu einem Konsens gebracht. Nun soll von einer anderen Gruppierungist ein anderer Vorschlag überraschend eingebracht worden sein (see comment from [email protected])  wurde ein neuer Vorschlag eingebracht. Unter anderem Werner Koch wehrt sich dagegen, beispielsweise sieht er Kompatibilitätsprobleme. Ein Blick auf die Diskussion auf der Mailingliste zeigt, dass es hier neben den rein technischen Abwägung auch um persönliche Differenzen und vielleicht auch um strategischen Erwägungen (GnuPGP vs. Sequoia-PGP?) geht.

Die beiden unterschiedlichen Drafts:
- Vorschlag: #^https://www.ietf.org/archive/id/draft-koch-openpgp-2015-rfc4880bis-02.txt
- Neuer Vorschlag: #^https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/

Stand scheint zu sein, dass sich auf der Mailingliste der neue Vorschlag („Crypto Refresh“) durchgesetzt hat, unter anderem auch Phil Zimmermann  hat sich dafür ausgesprochen. Für Werner Koch und andere scheint diese Entscheidung aber nicht tragbar zu sein. Sie propagieren darum einen Gegenentwurf unter dem Namen #LibrePGP.

Das blöde an der Sache: Für eine Software wie GnuPGP ist es nicht einfach herauszubekommen, nach welchem Standard die Verschlüsselung vorgenommen worden ist. Das bedeutet für beispielsweise das E-Mail-Ökosystem, das es noch schwieriger werden wird, E-Mail-Verschlüsselung für Anwender:innen einfach und fehlerfrei umzusetzen. Für eine stärkere Verbreitung von E-Mail-Verschlüsselung ist das also so hilfreich wie Fußpils zu haben.

Hier geht es zum LWN.net-Artikel: #^https://lwn.net/SubscriberLink/953797/b1701e578f357ba8/

#E-Mail #Verschlüsselung #Sequoia-PGP