From wk at gnupg.org Tue Sep 2 15:39:17 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:39:17 +0200 Subject: [Announce] GnuPG 2.5.12 released Message-ID: <87plc9c6t6.fsf@jacob.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG release: Version 2.5.12. This release adds new features and fixes two regressions. Note that this 2.5 series is fully supported and thus ready for production use. This means we won't break anything but may add some more features before 2.6. The main features in the 2.5. and 2.6 series are improvements for 64 bit Windows and the introduction of Kyber (ML-KEM, FIPS-203) as PQC encryption algorithm. Other than PQC support the 2.6 series will not differ a lot from 2.4 because the majority of changes are internal to make use of newer features from the supporting libraries. Please be aware that the 2.4 series will reach end of life in June next of year. What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.5.12 (2025-09-02) ================================================= [compared to version 2.5.11] * gpg: New options --[no-]auto-key-upload. [T7333] * gpg: Keys send to an LDAP server are now first updated from that server. New keyserver option "no-update-before-send" to disable this feature. [T7730] * gpg: Disable default compression for 7z compressed input. [rG53252628de] * gpg: Fix a regression with composite PQC and ECC algos. [T7649] * gpg: Fix the list of possible algos for --edit-key:addkey. [T7788] * gpg: Allow to select the Kyber variants with --edit-key:addkey. [T7792] * gpg: Avoid a second Pinentry pop-up for a configured ADSK during key generation. [T7491] * gpg: Change the ADSK key binding time to use the current time. [T6882] * gpgsm: Add option --no-qes-note and new trustlist flag "noconsent". [T7713] * agent: Enable "relax" in the trustlist by default and add flag "norelax". [rG7b133027ae] * agent: Fix a crash on Windows in the Putty support. [T7799] * dirmgr: Support LDAP servers using a schema like the Windows LDS servers. [T7742] * scd:openpgp: Support Yubikey attestation generation. [rG5ddfedf24a] * gpgtar: Fix regression in end-of-archive detection. [T7757] Release-info: https://dev.gnupg.org/T7756 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG may be downloaded from one of the GnuPG mirror sites or direct from its primary file server. The list of mirrors can be found at . Note that GnuPG is not available at ftp.gnu.org. The GnuPG source code compressed using BZIP2 and its OpenPGP signature are available here: https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.12.tar.bz2 (8032k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.5.12.tar.bz2.sig An installer for Windows without any graphical frontend except for a very minimal Pinentry tool is available here: https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.12_20250902.exe (5527k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.5.12_20250902.exe.sig The source used to build this installer for 64-bit Windows is available as https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.12_20250902.tar.xz (15M) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-w32-2.5.12_20250902.tar.xz.sig This source tarball may also be used to download all required libraries at once to build a Unix version on any modern system. See the included README. Debian Packages =============== For the first time we now provide Debian style packages for a couple of Debian variants. See https://repos.gnupg.org/deb/gnupg/bookworm-devel/ or use the menu to switch to other distros/releases. If you encounter packaging problems please report them to the gnupg-devel mailing list. Windows Installer ================= A new *Beta* version of Gpg4win, our full featured Windows installer including this version of GnuPG as well as the Kleopatra GUI and a PDF will soon be released. Stay tuned to https://gpg4win.org/version5.html Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a version of GnuPG installed, you can simply verify the supplied signature. For example to verify the signature of the file gnupg-2.5.12.tar.bz2 you would use this command: gpg --verify gnupg-2.5.12.tar.bz2.sig gnupg-2.5.12.tar.bz2 This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by one or more of the release signing keys. Make sure that this is a valid key, either by matching the shown fingerprint against a trustworthy list of valid release signing keys or by checking that the key has been signed by trustworthy other keys. See the end of this mail for information on the signing keys. * If you are not able to use an existing version of GnuPG, you have to verify the SHA-1 checksum. On Unix systems the command to do this is either "sha1sum" or "shasum". Assuming you downloaded the file gnupg-2.5.12.tar.bz2, you run the command like this: sha1sum gnupg-2.5.12.tar.bz2 and check that the output matches the next line: 027af3b8cc614683cad267ecb99ba24e4ce7709a gnupg-2.5.12.tar.bz2 d4a2e3e2d54bb37b643d36c2e566e5372f194b24 gnupg-w32-2.5.12_20250902.tar.xz a2a02f1aca6f7894840f534e65de08a6dbc84ba5 gnupg-w32-2.5.12_20250902.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Portuguese, Russian, Turkish, and Ukrainian being almost completely translated. Documentation and Support ========================= The file gnupg.info has the complete reference manual of the system. Separate man pages are included as well but they miss some of the details available only in the manual. The manual is also available online at https://gnupg.org/documentation/manuals/gnupg/ or can be downloaded as PDF at https://gnupg.org/documentation/manuals/gnupg.pdf You may also want to search the GnuPG mailing list archives or ask on the gnupg-users mailing list for advise on how to solve problems. Most of the new features are around for several years and thus enough public experience is available. https://wiki.gnupg.org has user contributed information around GnuPG and relate software. In case of build problems specific to this release please first check https://dev.gnupg.org/T7756 for updated information. Please consult the archive of the gnupg-users mailing list before reporting a bug: https://gnupg.org/documentation/mailing-lists.html. We suggest to send bug reports for a new release to this list in favor of filing a bug at https://bugs.gnupg.org. If you need commercial support go to https://gnupg.com or https://gnupg.org/service.html. If you are a developer and you need a certain feature for your project, please do not hesitate to bring it to the gnupg-devel mailing list for discussion. Thanks ====== Since 2001 maintenance and development of GnuPG is done by g10 Code GmbH and has mostly been financed by donations. A team of full-time employed developers and contractors are working exclusively on GnuPG and related software like Libgcrypt, GPGME, Kleopatra, Okular, and Gpg4win. Fortunately, and this is still not common with free software, we have established a way of financing the development while keeping all our software free and freely available for everyone. Our model is similar to the way RedHat manages RHEL and Fedora: Except for the actual binary of the MSI installer for Windows and client specific configuration files, all the software is available under the GNU GPL and other Open Source licenses. Thus customers may even build and distribute their own version of the software as long as they do not use our trademarks GnuPG Desktop? or GnuPG VS-Desktop?. We like to thank all the nice people who are helping the GnuPG project, be it testing, coding, translating, suggesting, auditing, administering the servers, spreading the word, answering questions on the mailing lists, or helped with donations. *Thank you all* Your GnuPG hackers p.s. This is an announcement only mailing list. Please send replies only to the gnupg-users at gnupg.org mailing list. * List of Release Signing Keys: To guarantee that a downloaded GnuPG version has not been tampered by malicious entities we provide signature files for all tarballs and binary versions. The keys are also signed by the long term keys of their respective owners. Current releases are signed by one or more of these four keys: ed25519 2020-08-24 [SC] [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [SC] [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) rsa3072 2025-05-09 [SC] [expires: 2033-03-03] 3B76 1AE4 E63B F351 9CE7 D63B ECB6 64CB E133 2EEF Alexander Kulbartsch (GnuPG Release Key) brainpoolP256r1 2021-10-15 [SC] [expires: 2029-12-31] 02F3 8DFF 731F F97C B039 A1DA 549E 695E 905B A208 GnuPG.com (Release Signing Key 2021) The keys are available at https://gnupg.org/signature_key.html and in any recently released GnuPG tarball in the file g10/distsigkey.gpg . Note that this mail has been signed by a different key. * Debian Package Signing Key: The new Debian style packages are signed using this key: ed25519 2025-07-08 [SC] [expires: 2035-07-14] 3209 7B71 9B37 45D6 E61D DA1B 85C4 5AE3 E1A2 B355 GnuPG.org Package Signing Key See the package website (https://repos.gnupg.org/deb/gnupg) for a list of supported distributions and a download link for the key. -- Arguing that you don't care about the right to privacy because you have nothing to hide is no different from saying you don't care about free speech because you have nothing to say. - Edward Snowden -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ Gnupg-announce mailing list Gnupg-announce at gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-announce From gnupg at securecryptohub.com Thu Sep 11 03:00:16 2025 From: gnupg at securecryptohub.com (Tanveer Salim) Date: Thu, 11 Sep 2025 03:00:16 +0200 (CEST) Subject: Question on Adding Support for Classic McEliece Message-ID: Hello! It seems the GNUPG developers are interested in adding support for Classic McEliece in the near future. I am excited about this. Now that GNUPG v 2.5.12 came out I was wondering what the schedule for Classic McEliece will be added. Is there an expected beta release date for Classic McEliece. I would love to try out if so. Please let me know. Thanks, Best, Tanveer Salim From contact at securecryptohub.com Thu Sep 11 02:57:09 2025 From: contact at securecryptohub.com (Tanveer Salim) Date: Thu, 11 Sep 2025 02:57:09 +0200 (CEST) Subject: Question on Adding Support for Classic McEliece Message-ID: Hello! It seems the GNUPG developers are interested in adding support for Classic McEliece in the near future. I am excited about this. Now that GNUPG v 2.5.12 came out I was wondering what the schedule for Classic McEliece will be added. Is there an expected beta release date for Classic McEliece. I would love to try out if so. Please let me know. Thanks, Best, Tanveer Salim From gnupg at securecryptohub.com Thu Sep 11 04:37:03 2025 From: gnupg at securecryptohub.com (Tanveer Salim) Date: Thu, 11 Sep 2025 04:37:03 +0200 (CEST) Subject: Question on Integrity of Sequoia-PGP Developers Message-ID: Hello, I am now aware there has been a split between the GNUPG and Sequoia-PGP developers. I read Andre's post here:?https://www.gnupg.org/blog/20250117-aheinecke-on-sequoia.html When I discussed the Sequoia-PGP developer's motivations for what they did they said it was for technical reasons which are described here as explained by Neal in an email he sent me: https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3297-sequoia-pgp-rethinking-openpgp-tooling/ Apparently they wanted GNUPG to be more secure, robust, and usable in a way the GNUPG developers did not agree with. It seems there is a disagreement between GNUPG and Sequoia-PGP about the security of GNUPG. GNUPG claims making the changes the Sequoia-PGP developers wanted would risk people's safety in using it--especially the crypto-refresh. Despite GNUPG's disagreements Phil Zimmermann, Micheal Rysiek-Wozniak (former GNUPG endorser), and Debian now are using Sequoia-PGP. Why would these people side with Sequoia-PGP despite the GNUPG team's reservations. What I am confused about is whether I can trust my privacy with the Sequoia Developers. Whether we like it or not Sequoia-PGP is used by Debian, SecureDrop, and even journalists such as Rysiek. These people /organizations do have a major influence in how security and privacy is practiced by important people such as software developers (Debian) and journalists / whisteblowers (Rysiek). What do the GNUPG developers think of this change in direction in the community? I still use GNUPG to protect my privacy when communicating to my friends and family I have no plans to change that but I cannot help but wonder how this shift to Sequoia-PGP will affect my ability to keep using PGP. I thank the GNUPG developers in advance for any responses. Best, Tanveer Salim From me at mattborja.dev Thu Sep 11 05:54:44 2025 From: me at mattborja.dev (Matt Borja) Date: Thu, 11 Sep 2025 03:54:44 +0000 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: Message-ID: Hi there, I recently had to prepare slides for a talk on Web of Trust for a local group and one of the introductory points was having them understand the difference between OpenPGP and GnuPG: one is the standard, the other is the implementation. While I don?t know the whole backstory to what is going on with Sequoia-PGP, I can say that when it comes to things like this, my recommendation will always default to staying truest to form (or standard). This implies a bias towards products with longevity and reputation in the field, that follows a reasonable cadence of continuous improvement. So, I have no problem continuing to recommend GnuPG to my clients and peers for the simple fact that it implements the standard, fulfills the purpose of upholding supply chain security, and has a reputable history. But we also have to remember that it?s ultimately the standard we?re most concerned with and need to be conformed to, not a specific implementation. Matt On Wed, Sep 10, 2025 at 19:39, Tanveer Salim via Gnupg-devel <[gnupg-devel at gnupg.org](mailto:On Wed, Sep 10, 2025 at 19:39, Tanveer Salim via Gnupg-devel < wrote: > Hello, > > I am now aware there has been a split between the GNUPG and Sequoia-PGP developers. > > I read Andre's post here: https://www.gnupg.org/blog/20250117-aheinecke-on-sequoia.html > > When I discussed the Sequoia-PGP developer's motivations for what they did they said > > it was for technical reasons which are described here as explained by Neal in an email he sent me: > > https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3297-sequoia-pgp-rethinking-openpgp-tooling/ > > Apparently they wanted GNUPG to be more secure, robust, and usable in a way the GNUPG > > developers did not agree with. > > It seems there is a disagreement between GNUPG and Sequoia-PGP about the security > > of GNUPG. GNUPG claims making the changes the Sequoia-PGP developers wanted would > > risk people's safety in using it--especially the crypto-refresh. > > Despite GNUPG's disagreements Phil Zimmermann, Micheal Rysiek-Wozniak (former GNUPG > > endorser), and Debian now are using Sequoia-PGP. > > Why would these people side with Sequoia-PGP despite the GNUPG team's reservations. > > What I am confused about is whether I can trust my privacy with the Sequoia Developers. > > Whether we like it or not Sequoia-PGP is used by Debian, SecureDrop, and even journalists > such as Rysiek. These people /organizations do have a major influence in how security > > and privacy is practiced by important people such as software developers (Debian) and > > journalists / whisteblowers (Rysiek). > > What do the GNUPG developers think of this change in direction in the community? > I still use GNUPG to protect my privacy when communicating to my friends and family I have > > no plans to change that but I cannot help but wonder how this shift to Sequoia-PGP will affect > > my ability to keep using PGP. > I thank the GNUPG developers in advance for any responses. > > Best, > Tanveer Salim > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Thu Sep 11 07:29:14 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 11 Sep 2025 01:29:14 -0400 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: Message-ID: > I am now aware there has been a split between the GNUPG and Sequoia- > PGP developers. I'm not a GnuPG developer, just a long-time community observer. There is a *lot* of stuff between the Sequoia and GnuPG devs that's hidden from public view. I don't mean that as "they're hiding stuff from us" -- I don't think that's true at all -- but more "they keep their disagreements private for the benefit of the community as a whole," which is probably a good policy. > Apparently they wanted GNUPG to be more secure, robust, and usable > in a way the GNUPG developers did not agree with. This appears to be incorrect. Engineering is all about tradeoffs. GnuPG embraces a different set of tradeoffs than Sequoia. That's the fundamental disagreement: it's not about security, robustness, or usability. It's about the tradeoffs the developers are willing to make to achieve those things. GnuPG came out in 1999, and some of those decisions from 1999 are still affecting its development today. Way back then, for instance, GnuPG decided it would support RFC1991 ("Classic PGP"). This turned out to, IMO, be a bad call: but now there are so many people dependent on GnuPG for RFC1991 support that GnuPG can't fix the mistake without incurring a lot of anger from the user base. Sequoia, on the other hand, is a clean slate. They get to make entirely new decisions about what behaviors they will support and which ones they won't. And in twenty years, Sequoia will be beholden to decisions they made long ago, too. This is the nature of software. > It seems there is a disagreement between GNUPG and Sequoia-PGP about > the security of GNUPG. GNUPG claims making the changes the Sequoia- > PGP developers wanted would risk people's safety in using it-- > especially the crypto-refresh. Some years ago a major international bank asked me to join them on a large engineering effort. Some consultant had told them that yes, their COBOL infrastructure had been running for decades without a problem, but sooner or later they weren't going to be able to hire COBOL programmers any more: so, this consultant said, it's best if the entire financial software system gets rewritten in Java, for ease of maintenance going into the future. When I heard this I immediately smiled, said "Nope!", stood up, and walked out. The bank looked at the risk of "maybe we can't hire COBOL programmers in the future", and weighed it against the risk of "we will definitely introduce tons of bugs in our first Java release, as opposed to the COBOL codebase which is stable, mature, and quite boring." The bank decided staying with COBOL would be the bigger risk. I looked at the same problem, said "rewriting in Java is a much bigger risk, and I'm not cool with this level of risk." Which one of us was right? It's hard to say. It's a judgment call. The Sequoia guys are free to make what judgment calls they wish. GnuPG gets to make its own judgment calls, too. Just as the Sequoia guys think the GnuPG guys are exercising bad judgment, the GnuPG guys think the same of Sequoia. > Despite GNUPG's disagreements Phil Zimmermann, Micheal Rysiek- > Wozniak (former GNUPG endorser), and Debian now are using Sequoia- > PGP. Sure. I also am using librnp right now for my OpenPGP needs. That doesn't mean I dislike GnuPG. Sure, some people in the community are using Sequoia. That's good! Competition is healthy. It doesn't mean those people have suddenly decided GnuPG should be abandoned, or that it's an inferior product, or anything else. > What I am confused about is whether I can trust my privacy with the > Sequoia Developers. Never trust anyone who will tell you whom you should or should not trust. Trust is too important a decision to outsource. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: From look at my.amazin.horse Thu Sep 11 09:57:12 2025 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 11 Sep 2025 09:57:12 +0200 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: Message-ID: <8cd5a4d6-8291-4d35-8e91-94c2dbaabc13@my.amazin.horse> Hey Matt and list, On 9/11/25 05:54, Matt Borja via Gnupg-devel wrote: > While I don?t know the whole backstory to what is going on with Sequoia- > PGP, I can say that when it comes to things like this, my recommendation > will always default to staying truest to form (or standard). This > implies a bias towards products with longevity and reputation in the > field, that follows a reasonable cadence of continuous improvement. Can you clarify what you mean by "truest to form (or standard)" here? I read your email as an endorsement of GnuPG, which is fair enough. But GnuPG is the single big implementation that has decided not to implement RFC9580, the IETF OpenPGP standard following RFC4880. With this context, I'm not sure what you're saying with this paragraph. - V From m at gnupg.org Thu Sep 11 11:22:09 2025 From: m at gnupg.org (Meik Michalke) Date: Thu, 11 Sep 2025 11:22:09 +0200 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: Message-ID: <8604729.q9xnsEsRLe@kasidy> hi, Am Donnerstag, 11. September 2025, 05:54:44 CEST schrieb Matt Borja via Gnupg- devel: > But we also have to remember that it?s ultimately the standard we?re most > concerned with and need to be conformed to, not a specific implementation. actually, the schism does cut deeper than that. when we say "OpenPGP" today, unfortunately, it is no longer "the standard" it used to be for many years. the conflict lines weren't just about implementation, but about the evolution of that standard itself. at a certain point, the direction this discussion took was seen as so wrong by the GnuPG devs that they felt it pointless to try and hold on to what was about to be named "OpenPGP" in the future. they took what was originally discussed to become the new OpenPGP standard (a stable but necessary update without disruptive changes), and named it "LibrePGP". in that sense, LibrePGP is actually a fully compatible evolution of the old OpenPGP standard, while the new OpenPGP standard breaks continuity at certain points. it's a paradox, but if you want to continue to support what used to be OpenPGP in the past, you would now need to abandon OpenPGP and support LibrePGP instead. it's a bit like when an established brand is bought by another company that uses it to sell products that do not continue to uphold what made the brand in the first place. it would have been a much better and more transparent decision if LibrePGP had been the updated OpenPGP standard as was originally planned, and the disruptive, new standard would have been given its own new name. if you want to go into the details, there's a homepage explaining all of it: https://librepgp.org it is true what has been written here before, that compatibility and stability are values held up high by GnuPG. it is a pitty that it came to this. it wasn't necessary to be this nasty and painful a process. disclaimer: i do work for g10 code/GnuPG. but i joined the company long after this conflict emerged and had no part in that. but i do admit that personally, i do find the arguments for LibrePGP much more compelling. viele gr??e :: m.eik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 265 bytes Desc: This is a digitally signed message part. URL: From me at mattborja.dev Thu Sep 11 16:25:25 2025 From: me at mattborja.dev (Matt Borja) Date: Thu, 11 Sep 2025 14:25:25 +0000 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: <8604729.q9xnsEsRLe@kasidy> References: <8604729.q9xnsEsRLe@kasidy> Message-ID: <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> Hi, Yeah, so this is also totally understandable and I think to be expected with the evolution of technology itself. In July of this year (2025), NIST announced the release of the latest major update to their Digital Identity Guidelines (NIST SP 800-63-4) that had not seen much activity since 2017: https://www.nist.gov/identity-access-management/projects/nist-special-publication-800-63-digital-identity-guidelines I think to your point, this is the sort of ?stewardship? of a given standard (or any standard) that would be necessary to mitigate these types of schisms (e.g., when NIST goes to revise a standard, companies are normally expectant and eventually follow suit). If in this space, the equivalent is IETF with the OpenPGP Working Group as the standards governing body, and this is how changes are managed for the industry, then fine. I would just clarify though that we don?t necessarily call it different things when dealing with NIST. It?s still ?Digital Identity Guidelines? NIST SP 800-63 whether it?s the 2017 version or the massively overhauled 2025 version that current implementations may now be falling behind on. And ?OpenPGP? should still mean ?OpenPGP? whether now on the 2024 standard, or the 2007 version?or the 1998 version for that matter. So, Vincent, to address your question, if RFC 9580 is the succeeding standard being ratified by this IETF group, then you will inevitably see my technology decisions and training materials moving towards that. I wasn?t aware of the 2024 update at the time I prepared my slides, but that doesn?t negate what I said earlier about staying truest to form, even when that form (standard) changes. It?s one thing to have varying implementations of a given standard. We just can?t be having multiple standards surrounding the same thing. That just renders the whole thing meaningless. To wit, it?s going to be harder for me to sell something that has not been endorsed (by IETF standards process in this case) than something that could even be, let?s say, theoretically wrong, that is endorsed. But as an engineer, if I get in there and find out Koch was right about LibrePGP and that that should?ve been the next version, but we go end up ratifying the other one instead, I?m just going to rage quit :P It?s not that I wouldn?t agree with him at that point; there are just way too many hills to die on out there and not enough bodies. And I?ve already died on mine at this point. The draft expires in 7 days and still has not been acknowledged it seems, but this is what I would have to look to: https://datatracker.ietf.org/doc/draft-koch-librepgp/ Trust me, I do know the feeling. Hoping for the best, Matt Borja On Thu, Sep 11, 2025 at 02:24, Meik Michalke via Gnupg-devel < [gnupg-devel at gnupg.org](mailto:On Thu, Sep 11, 2025 at 02:24, Meik Michalke via Gnupg-devel < wrote: > hi, > > Am Donnerstag, 11. September 2025, 05:54:44 CEST schrieb Matt Borja via Gnupg- > devel: >> But we also have to remember that it?s ultimately the standard we?re most >> concerned with and need to be conformed to, not a specific implementation. > > actually, the schism does cut deeper than that. when we say "OpenPGP" today, > unfortunately, it is no longer "the standard" it used to be for many years. > the conflict lines weren't just about implementation, but about the evolution > of that standard itself. at a certain point, the direction this discussion > took was seen as so wrong by the GnuPG devs that they felt it pointless to try > and hold on to what was about to be named "OpenPGP" in the future. they took > what was originally discussed to become the new OpenPGP standard (a stable but > necessary update without disruptive changes), and named it "LibrePGP". in that > sense, LibrePGP is actually a fully compatible evolution of the old OpenPGP > standard, while the new OpenPGP standard breaks continuity at certain points. > > it's a paradox, but if you want to continue to support what used to be OpenPGP > in the past, you would now need to abandon OpenPGP and support LibrePGP > instead. it's a bit like when an established brand is bought by another > company that uses it to sell products that do not continue to uphold what made > the brand in the first place. it would have been a much better and more > transparent decision if LibrePGP had been the updated OpenPGP standard as was > originally planned, and the disruptive, new standard would have been given its > own new name. > > if you want to go into the details, there's a homepage explaining all of it: > > https://librepgp.org > > it is true what has been written here before, that compatibility and stability > are values held up high by GnuPG. it is a pitty that it came to this. it > wasn't necessary to be this nasty and painful a process. > > disclaimer: i do work for g10 code/GnuPG. but i joined the company long after > this conflict emerged and had no part in that. but i do admit that personally, > i do find the arguments for LibrePGP much more compelling. > > viele gr??e :: m.eik_______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From look at my.amazin.horse Thu Sep 11 17:27:49 2025 From: look at my.amazin.horse (Vincent Breitmoser) Date: Thu, 11 Sep 2025 17:27:49 +0200 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> Message-ID: <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> Hey List and Matt, > It?s one thing to have varying implementations of a given standard. We > just can?t be having multiple standards surrounding the same thing. Well, that's what we ended up with. GnuPG has also been emitting LibrePGP packets by default for some years by now, so it's not just something that's coming soon, it's already here. And on the flip side, support of OpenPGP v6 is fairly complete in most big implementations and everyone is moving on to PQC, although none emit v6 by default yet as far as I'm aware. There are some comparison charts here: https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?q=v6#test-summary > But as an engineer, if I get in there and find out Koch was right > about LibrePGP and that that should?ve been the next version, but we > go end up ratifying the other one instead, I?m just going to rage quit To give you a starting point, there is a comparison of OpenPGP and LibrePGP from a technical and spec management perspective here: https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/blob/main/opgp-lpgp-comp.pdf Cheers - V From heiko.schaefer at posteo.de Fri Sep 12 19:42:17 2025 From: heiko.schaefer at posteo.de (=?UTF-8?Q?Heiko_Sch=C3=A4fer?=) Date: Fri, 12 Sep 2025 17:42:17 +0000 Subject: The case for OpenPGP as a collaborative effort In-Reply-To: <8604729.q9xnsEsRLe@kasidy> References: <8604729.q9xnsEsRLe@kasidy> Message-ID: Hello all, This thread has veered into questions about how the OpenPGP standard as such develops, and I have thoughts. Reasonable people can have different personal preferences on details of the RFC 9580 specification and the LibrePGP draft. However, objectively, RFC 9580 has been produced in a multi-stakeholder IETF process, and LibrePGP has not[1]. The initial framing of this thread misses this point by centering one actor who participated in the IETF process. However, I think the most interesting question is "Where is collaboration happening?" (not: "Which of two actors do I trust/favor?"). RFC 9580 is the result of multiple years of collaboration by a sizeable and diverse group. This work is public and on the record. Many trade-offs were considered, discussed and worked through. The design decisions that RFC 9580 embodies are certainly not impulsive. LibrePGP on the other hand, seems to be written single-handedly by Werner Koch, and in private (I am not aware of public deliberations about any of the design decisions in it). Also see [2], [3]. # RFC 9580 is supported by many independent implementers and contributors The work that went into RFC 9580 shows. The text is *much* clearer than its predecessor, RFC 4880 and its close relative, the LibrePGP draft. (A report comissioned by the BSI [4] also seems to make this point.) RFC 9580 specifies some new formats, but all of them are clear evolutions of what came before. Its new v6 formats enable a clean transition from the current "v4 OpenPGP" state of affairs to future artifacts that finally drop some of the legacy cruft that has been rightfully criticized about OpenPGP. As Vincent pointed out, all major OpenPGP libraries now feature rather complete implementations of v6/RFC 9580. Of course, since libraries are not user-facing, they have less mindshare than GnuPG. Still, I am confident that their aggregate use substantially outpaces GnuPG's. These libraries include Bouncy Castle, GopenPGP, OpenPGP.js, PGPainless, rnp, rPGP and Sequoia-PGP. We're looking at the work of *many* independent parties, all of which clearly agree that RFC 9580 is a good standard and represents the future direction of OpenPGP. As others have pointed out, GnuPG is a C codebase with a long history (going on 28 years). On top of that, it's a codebase that is mostly uncovered by tests, and has no automated CI. If GnuPG were my project, I would also be anxious about each change I make. I believe that because of this the LibrePGP draft errs on the side of making minimal changes, with the unspoken goal of limiting risks of breakage in a brittle codebase with practically no tests. (Maybe the new formats in RFC 9580 are indeed "too radical" of an evolutionary step to safely implement in GnuPG. But that's surely not a failing of RFC 9580.) # My place in the larger OpenPGP collective Just to clarify where I'm writing from: I have participated in many collaborative efforts in the OpenPGP space over the past 7 years [5]. Last year, I contributed an implementation of the new RFC 9580 formats to the rPGP library [6]. rPGP is a pure Rust implementation of OpenPGP, it is 8 years old, and most prominently used in the Delta Chat decentralized secure messenger app [7]. It's probably fair to say I am familiar with RFC 9580, and can judge its merits with some confidence. I've also implemented decryption support for the "OCB" encryption container format from the LibrePGP draft in rPGP. The latter effort further clarified the high quality of RFC 9580 to me - the LibrePGP draft does not compare favorably. Collaboration produces better quality and clarity. # Conclusion I am pretty happy how the OpenPGP space is developing lately. There's much progress and productive collaboration. It is very unfortunate that GnuPG has decoupled from the rest of the OpenPGP ecosystem. But then, a lot of people have spent a lot of time trying to reach out and build bridges, to find compromises. Sadly, so far to no avail. I'm well aware of many of the interpersonal undercurrents in this space over the past decade. Certainly, the "people"-aspect of collaboration can be hard and tiresome. But that's not specific to OpenPGP. Social complications happen in many specification and FOSS implementation efforts. It takes work to talk, coordinate, find common ground, actually take other perspectives seriously and work through their implications. But really, this is not a good reason - let alone justification - for forking the OpenPGP standard. Thanks, cheers, Heiko PS: Just to clarify two potential points of confusion: - Both RFC 9580 and LibrePGP are fully backward compatible with the formats in RFC 4880. Both drafts fully support existing v4 keys and messages. Also, they both use signaling mechanisms, so that, e.g., a sender's software knows which encryption formats a recipient can decrypt. Neither of the two drafts breaks the status quo. - Both RFC 9580 and LibrePGP introduce new formats that won't work with software that predates the respective spec. The main difference is that RFC 9580 defines v6 OpenPGP formats that actually clean up some legacy cruft (things that can never be dropped in v4, and that LibrePGP's v5 also doesn't clean up). -- [1]: Somewhat bizarrely, the same pattern of a "schism" between IETF- and GnuPG-formats seems to repeat around PQC in OpenPGP: A group at the IETF is working on draft-ietf-openpgp-pqc, while GnuPG at some point decided to implement a similar but incompatibly different PQC scheme (fwiw, Sequoia-PGP was not an active participant in the work on draft-ietf-openpgp-pqc. And yet, GnuPG has opted not to work with the group at the IETF.) [2]: "Requesting the editor to step down", Vincent Breitmoser 2020-04-17: https://mailarchive.ietf.org/arch/msg/openpgp/XxZt89Eh7XUenuVRajbgtcWzWdA/ [3]: "Speaking as Author / Editor of RFC 9580", Paul Wouters 2025-08-28: https://warmwasserwerfer.de/2025/08/28/towards-openpgp-v6-in-pgpainless/#comment-37301 [4]: "Comparison of RFC 9580 and LibrePGP", Johannes Roth and Falko Strenzke 2025-07-08: https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/releases/download/v1.4/opgp-lpgp-comp.pdf [5]: https://floss.social/@hko has more from and about me [6]: RFC 9580 support in rPGP: https://fosstodon.org/@hko/113198947595455844 [7]: Delta Chat is a decentralized system and has no telemetry. However, a known lower bound for its current use is "Three million OpenPGP encrypted messages per day" (using email as transport) From me at mattborja.dev Fri Sep 12 21:20:30 2025 From: me at mattborja.dev (Matt Borja) Date: Fri, 12 Sep 2025 19:20:30 +0000 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> Message-ID: The best course of action in the better interest of the industry, given the direction the official IETF standards process which is what the industry will inevitably follow, would be for the LibrePGP Message Format branch to merge back onto main at some point, either now or in the future; sooner rather than later in the interest of resolving those merge conflicts, as difficult as that may be. And then continuing forward with the effort collaboratively. The information provided in the comp I would hope would be a great starting point for this effort. But if that can?t be done, then there?s really no point to further discussion on this issue. Because what we?re saying then is that the only place where all this talk and effort will actually make a difference in resolving this split, is simply out of the question. And RFC 9580 will continue on as-is into the future as the industry standard ratified by IETF until some similar disruptive event in the future transpires; rinse and repeat. On Thu, Sep 11, 2025 at 08:30, Vincent Breitmoser via Gnupg-devel <[gnupg-devel at gnupg.org](mailto:On Thu, Sep 11, 2025 at 08:30, Vincent Breitmoser via Gnupg-devel < wrote: > Hey List and Matt, > >> It?s one thing to have varying implementations of a given standard. We >> just can?t be having multiple standards surrounding the same thing. > > Well, that's what we ended up with. GnuPG has also been emitting > LibrePGP packets by default for some years by now, so it's not just > something that's coming soon, it's already here. And on the flip side, > support of OpenPGP v6 is fairly complete in most big implementations and > everyone is moving on to PQC, although none emit v6 by default yet as > far as I'm aware. There are some comparison charts here: > > https://sequoia-pgp.gitlab.io/openpgp-interoperability-test-suite/results.html?q=v6#test-summary > >> But as an engineer, if I get in there and find out Koch was right >> about LibrePGP and that that should?ve been the next version, but we >> go end up ratifying the other one instead, I?m just going to rage quit > > To give you a starting point, there is a comparison of OpenPGP and > LibrePGP from a technical and spec management perspective here: > > https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/blob/main/opgp-lpgp-comp.pdf > > Cheers > > - V > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Sat Sep 13 06:27:40 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 12 Sep 2025 23:27:40 -0500 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> Message-ID: On 9/12/25 14:20, Matt Borja via Gnupg-devel wrote: > The best course of action in the better interest of the industry, > given the direction the official IETF standards process which is what > the industry will inevitably follow, would be for the LibrePGP Message > Format branch to merge back onto main at some point, either now or in > the future; sooner rather than later in the interest of resolving > those merge conflicts, as difficult as that may be. And then > continuing forward with the effort collaboratively. > > The information provided in the comp I would hope would be a great > starting point for this effort. > > But if that can?t be done, then there?s really no point to further > discussion on this issue. Because what we?re saying then is that the > only place where all this talk and effort will actually make a > difference in resolving this split, is simply out of the question. And > RFC 9580 will continue on as-is into the future as the industry > standard ratified by IETF until some similar disruptive event in the > future transpires; rinse and repeat. Do I correctly gather that LibrePGP defines v5 and RFC9580 defines v6?? If so, where is the problem?? What prevents both of those from co-existing and implementations eventually supporting both? -- Jacob From KaiE at kuix.de Sat Sep 13 13:11:11 2025 From: KaiE at kuix.de (Kai Engert) Date: Sat, 13 Sep 2025 13:11:11 +0200 Subject: v5 vs v6 consequences In-Reply-To: References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> Message-ID: <3a18a8fc-d2e4-4e52-8252-6687809e7a79@kuix.de> On 9/13/25 06:27, Jacob Bachmeyer via Gnupg-devel wrote: > Do I correctly gather that LibrePGP defines v5 and RFC9580 defines v6? > If so, where is the problem?? What prevents both of those from co- > existing and implementations eventually supporting both? It creates additional complexity for key management and group conversations. Despite your suggestion, some implementations might chose to one of the specifications. If Alices wishes to be compatible with everyone, including those who use software that implements one specification, would be required to own personal key pairs for both v5 and v6. Alice will have to ensure that both of her keys are published and discoverable. When Alice sends an email Bob to bootstrap an encrypted conversation, without knowing what software Bob uses, Alice would have to attach both her v5 and her v6 keys. Now let's say Alice uses software that supports both v5 and v6, and Bob uses software that supports v5, only, and Charlie uses software that supports v6, only. That means there is no v5 key for Charlie, and no v6 key for Bob. Alice wants to send an encrypted message to both Bob and Charlie. She cannot send a single email that would work for everyone that uses the latest secure mechanisms. Either Alice's MUA must fall back to the older, less secure mechanisms that are supported by both specs. Or, to use modern mechanisms, Alice's MUA must construct two separate messages, one to Bob using LibrePGP mechanisms, and another one to Charlie using IETF OpenPGP mechanisms. Now, Bob wishes to reply to the whole group. But Bob cannot find a public key for Charlie that's compatible with Bob's software. As a result, Bob cannot send an encrypted reply to Charlie. That dilemma is the reason why there is ongoing work on the replacement-key specification. It could allow software that supports only one of the specs to also generate a separate backwards-comaptible key. Charlie's software could generate a v4 key in addition to the v6 key, and add meta information that links the two, and publishes both. When Alice's MUA detects that there's only a v6 key for Charlie, but no v5 key for Charlie, she could include the v4 key that's linked from the v6 key into the gossip part of her outgoing email, too. That could allow Bob to notice that key and use it. Let me know if I'm missing easier ways to handle the schism. Kai From KaiE at kuix.de Sat Sep 13 13:14:33 2025 From: KaiE at kuix.de (Kai Engert) Date: Sat, 13 Sep 2025 13:14:33 +0200 Subject: v5 vs v6 consequences In-Reply-To: <3a18a8fc-d2e4-4e52-8252-6687809e7a79@kuix.de> References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> <3a18a8fc-d2e4-4e52-8252-6687809e7a79@kuix.de> Message-ID: sorry, there were two missing words here: On 9/13/25 13:11, Kai Engert wrote: > Despite your suggestion, some implementations might chose to ... implement only ... > one of the > specifications. From andrewg at andrewg.com Sat Sep 13 16:49:12 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sat, 13 Sep 2025 16:49:12 +0200 Subject: Question on Integrity of Sequoia-PGP Developers In-Reply-To: References: Message-ID: <15C4B993-320E-44D3-A4DA-49F1036255EE@andrewg.com> On 13 Sep 2025, at 07:25, Jacob Bachmeyer via Gnupg-devel wrote: > > Do I correctly gather that LibrePGP defines v5 and RFC9580 defines v6? Partly, yes. LibrePGP defines version 5 keys and signatures, type 20 aead/ocb encrypted data, and various other minor changes. RFC9580 defines version 6 keys and signatures, SEIPD2 encrypted data, and other changes - some of which correspond to librepgp and some of which do not. ?v5? and ?v6? are often used as shorthand, but they do not capture the whole picture. Daniel?s summary at https://mailarchive.ietf.org/arch/msg/openpgp/aqBy97lj2P4DVxTds0eKZDVdmms/ is technical, but comprehensive. > If so, where is the problem? What prevents both of those from co-existing and implementations eventually supporting both? Technically, there is no fundamental issue - several library implementations currently support both, to various extents. The real trick is how to present (or avoid presenting) these changes to the user. Choreographing a version bump is tricky enough at the best of times ?organising two competing ones sumultaneously has taxed the minds of many people in the *pgp space to destruction and back. As Kai pointed out in another reply, there are mechanisms (both current and potential) available to help ease a transition, but these all depend on the various implementations playing nice with each other. If one major implementation does not wish to cooperate, users of all implementations will inevitably stumble over interoperability issues at some point, and mitigating the resulting pain is very difficult, and probably impossible, through unilateral action. A -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Sat Sep 13 17:59:12 2025 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 13 Sep 2025 17:59:12 +0200 Subject: v5 vs v6 consequences In-Reply-To: References: <8604729.q9xnsEsRLe@kasidy> <-a5bg23216fyfVW71whQaPX770cKAuec4W37pAUizCZE2XL0BsSILH3-cRQdF3n1Ld_yijwZxnGdSQiGh22MVhGORVzy4j1_M-BxJFzgBU0=@mattborja.dev> <5f1ed1ec-4028-44d2-858d-ff7f5d5dc258@my.amazin.horse> <3a18a8fc-d2e4-4e52-8252-6687809e7a79@kuix.de> Message-ID: <20250913155912.WXPUYu23@steffen%sdaoden.eu> Kai Engert via Gnupg-devel wrote in : |sorry, there were two missing words here: | |On 9/13/25 13:11, Kai Engert wrote: |> Despite your suggestion, some implementations might chose to | |... implement only ... | |> one of the |> specifications. Wasn't the process unfair then given that certain implementations created keys for years of an anticipated format that then did not became reality? Granted, as a non-crypto non-mathematician (the latter as a conscious decision at some age), the librepgp web page reasoning bullet list does not thrill me, it was written for specialists. But that often prodded for comparison report i also did not truly get, given that the major vulnerability seems to refer to a "v3 key" concept that Werner Koch rejected with "v3 key is not supported" on the ML, which i found not reproduced in the report. In fact i personally found the report, that i only glanced over and read in a hurry, well my impression was that of a "biased flight over some topic". Maybe involved people should never write such a report, it is a characteristic of quality journalism to be able to step back, and write an objective article with a comprehensive (enough) context. Was actually what i thought. Granted also that it seems one side took certain steps as one would do it who has to keep a business going, anyone who had that, possibly even at a low financial comfort level, knows this is a treadmill: decisions have to be made quickly, however risky they may be, often "out of the gut", and then you have to "take this reality" and go with it. And in such a context, some peculiar little things just do not really matter, i think for example of algorithm OIDs i think it was, here possibly more communication would have been the optimum, but i actually have forgotten about the context, ie, how much that actually taken "OID" hurts. I bet it was just a "we need an OID; here is an OID", and that was it about it, and if seen in such a light, having had a communication on it is outstanding even, that much is eh, true. In any event it is easy (let aside much easier) to come from a saturated environment and simply do not care about a quarter of a century, as was already heard in this thread. This is 25 years, and, as was also already heard, maybe certain people will have opened their eyes if, indeed, 25 years of further adult life have passed. Personally i also think it is debatable whether "open and public process"es always are truly open and public. I cannot comment on this very process here, however. But i have watched, from the times when European films had some value, for example "Endstation Schaffott" ("Deux hommes dans la ville"), and that really moved me deeply enough to remember it fourty years later. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From andrewg at andrewg.com Sun Sep 14 09:27:40 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Sun, 14 Sep 2025 09:27:40 +0200 Subject: v5 vs v6 consequences In-Reply-To: <20250913155912.WXPUYu23@steffen%sdaoden.eu> References: <20250913155912.WXPUYu23@steffen%sdaoden.eu> Message-ID: <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> On 13 Sep 2025, at 18:00, Steffen Nurpmeso wrote: > > ?Kai Engert via Gnupg-devel wrote in > : > |sorry, there were two missing words here: > | > |On 9/13/25 13:11, Kai Engert wrote: > |> Despite your suggestion, some implementations might chose to > | > |... implement only ... > | > |> one of the > |> specifications. > > Wasn't the process unfair then given that certain implementations > created keys for years of an anticipated format that then did not > became reality? Nobody was ?creating v5 keys for years? other than testers and early adopters, they are only being generated by default since quite recently. A few other implementations had support for v5 keys since before the schism, but all except gnupg agreed to move to v6 once the issues with v5 signatures became known. A From jcb62281 at gmail.com Mon Sep 15 04:28:17 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 14 Sep 2025 21:28:17 -0500 Subject: v5 vs v6 consequences In-Reply-To: <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> References: <20250913155912.WXPUYu23@steffen%sdaoden.eu> <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> Message-ID: <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> On 9/14/25 02:27, Andrew Gallagher via Gnupg-devel wrote: > [...] A few other implementations had support for v5 keys since before the schism, but all except gnupg agreed to move to v6 once the issues with v5 signatures became known. [*sigh*] What are the issues with v5 signatures? -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From robinmathewrajan at gmail.com Mon Sep 15 06:50:54 2025 From: robinmathewrajan at gmail.com (=?UTF-8?B?4KSu4KS54KS+4KSw4KS+4KSc4KS+IG9mIOCkreCkvuCksOCkpOCkgiDgpLDgpYvgpKzgpL8=?= =?UTF-8?B?4KSoIOCkruCkvuCkpOCljeCkr+ClgiDgpLDgpL7gpJzgpKg=?=) Date: Mon, 15 Sep 2025 10:20:54 +0530 Subject: Hoist the Colours! Message-ID: Pretty Good Privacy stands for as the name itself is called, Pretty Good! It doesn't boast as it is too much secure and too much insecure. It is just a Pretty Good software. There is no change needed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robinmathewrajan at gmail.com Mon Sep 15 08:02:49 2025 From: robinmathewrajan at gmail.com (=?UTF-8?B?4KSu4KS54KS+4KSw4KS+4KSc4KS+IG9mIOCkreCkvuCksOCkpOCkgiDgpLDgpYvgpKzgpL8=?= =?UTF-8?B?4KSoIOCkruCkvuCkpOCljeCkr+ClgiDgpLDgpL7gpJzgpKg=?=) Date: Mon, 15 Sep 2025 11:32:49 +0530 Subject: Hoist the Colours! Message-ID: Pretty Good Privacy stands for as the name itself is called, Pretty Good! It doesn't boast as it is too much secure and too much insecure. It is just a Pretty Good software. There is no change needed. Go back to the old days where we started. -------------- next part -------------- An HTML attachment was scrubbed... URL: From look at my.amazin.horse Mon Sep 15 09:52:41 2025 From: look at my.amazin.horse (Vincent Breitmoser) Date: Mon, 15 Sep 2025 09:52:41 +0200 Subject: v5 vs v6 consequences In-Reply-To: <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> References: <20250913155912.WXPUYu23@steffen%sdaoden.eu> <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> Message-ID: > What are the issues with v5 signatures? As referenced earlier in this thread, please refer to https://github.com/crypto-security-tools/OpenPGP-LibrePGP-comparison/ for a technical and governance comparison of the specs. The main issues that you will find these days (imo) are that v5 is a format that is exclusively governed by GnuPG. As such it has limited support in other implementations, is not an OpenPGP format, and has dropped its stated goal of becoming such. If this is something that works for you, or you are bound to using GnuPG regardless, the technical issues are probably not significant as a deciding factor. > [*sigh*] Everyone please note that this is a *hugely* complicated topic, with many actors, years, technical complexities, and clashes of personal sensitivities involved. As such, it is difficult to explain in any amount of written text to folks watching from the sidelines. Some may find this "after the dust settled" blog post from GnuPG on the matter enlightening: https://www.gnupg.org/blog/20250117-aheinecke-on-sequoia.html Cheers - V On 9/15/25 04:28, Jacob Bachmeyer via Gnupg-devel wrote: > On 9/14/25 02:27, Andrew Gallagher via Gnupg-devel wrote: >> [...] A few other implementations had support for v5 keys since before the schism, but all except gnupg agreed to move to v6 once the issues with v5 signatures became known. > > [*sigh*] > > What are the issues with v5 signatures? > > > -- Jacob > > > > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel From wk at gnupg.org Mon Sep 15 10:34:28 2025 From: wk at gnupg.org (Werner Koch) Date: Mon, 15 Sep 2025 10:34:28 +0200 Subject: Question on Adding Support for Classic McEliece In-Reply-To: (Tanveer Salim via Gnupg-devel's message of "Thu, 11 Sep 2025 02:57:09 +0200 (CEST)") References: Message-ID: <87sego867f.fsf@jacob.g10code.de> On Thu, 11 Sep 2025 02:57, Tanveer Salim said: > It seems the GNUPG developers are interested in adding support for Classic > McEliece in the near future. I am excited about this. Now that GNUPG v I don't know about this. McEliece was added to Libgcrypt but there is no plan to add it to GnuPG. The old agreement we had with the PGP.com folks (PRZ and Jon Callas) still holds. This is to limit the proliferation of algorithms to the absolutely necessary list. For example only for political reasons we had to add algorithms like Camellia, Brainpool, and now FIPS-203 but that's it. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 284 bytes Desc: not available URL: From andrewg at andrewg.com Mon Sep 15 12:00:15 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 15 Sep 2025 11:00:15 +0100 Subject: v5 vs v6 consequences In-Reply-To: <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> References: <20250913155912.WXPUYu23@steffen%sdaoden.eu> <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> Message-ID: On 15 Sep 2025, at 03:28, Jacob Bachmeyer wrote: > > On 9/14/25 02:27, Andrew Gallagher via Gnupg-devel wrote: >> [...] A few other implementations had support for v5 keys since before the schism, but all except gnupg agreed to move to v6 once the issues with v5 signatures became known. > [*sigh*] > > What are the issues with v5 signatures? > The issue is that they are convertible to v3 signatures over different data (see e.g. https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/130). The likelihood of exploitation is nonzero, and so most implementers agreed that it was better to modify the wire format. GnuPG disagreed with the modified (now v6) signature format because it didn?t sign over the literal data metadata by default (file name, file type and file modification date), which v5 signatures do - although the librepgp spec also defines a more generic method of signing over the file metadata using any signature version, but GnuPG has not implemented it. Ironically, it has since emerged that the way v5 signatures sign over the metadata is also flawed (although not exploitable in practice). The fundamental issue leading to both flaws in the v5 signature design arises from the fact that *PGP stores metadata in a "trailer" at the end of the data stream being signed over, rather than prefixing it. This means that standard computer-science tricks to prevent ambiguity, such as prefixing data fields with their lengths, or always storing values at a fixed offset from the start of the data stream, are not effective in pgp trailers. Instead, values must be stored at a fixed offset from *the end* of the data stream - and v5 signatures violate this principle in more than one place. What makes it worse is that v4 signatures contain fixed values at certain offsets that make no sense unless you understand that they exist purely to avoid aliasing between v4 and v3. GnuPG was part of the design team for v4 signatures, so should have been well aware of this. But by changing the size of one field and introducing a novel field for the metadata, v5 signatures no longer store these anti-aliasing fixed values at the correct offsets. The fact that these errors are not easily exploitable appears to be by pure accident, not by design. To be blunt, this is why we have standards processes for security protocols. The more eyes on the document, the more people thinking about the design process, the more likely that such mistakes will get caught early. One of the reasons given by GnuPG for why they continued with the v5 signature format is that the v5 signature verification code had already been shipped in production. But this was GnuPG?s choice, and a self-inflicted problem. Dissenting voices were locked out of the design process, and when they did eventually scrutinise the details it was too late. Security is a collective process. A -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From noloader at gmail.com Mon Sep 15 18:41:11 2025 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 15 Sep 2025 12:41:11 -0400 Subject: v5 vs v6 consequences In-Reply-To: References: <20250913155912.WXPUYu23@steffen%sdaoden.eu> <959ABC1E-BF24-4E0F-B5B4-CF159B8B0117@andrewg.com> <2dc9177c-7eea-4904-9369-1d3ff2434c68@gmail.com> Message-ID: On Mon, Sep 15, 2025 at 3:53?AM Vincent Breitmoser via Gnupg-devel < gnupg-devel at gnupg.org> wrote: > [...] > > > [*sigh*] > > Everyone please note that this is a *hugely* complicated topic, with > many actors, years, technical complexities, and clashes of personal > sensitivities involved. As such, it is difficult to explain in any > amount of written text to folks watching from the sidelines. A long time ago someone told me the technical part is easy. He said the biggest technical problem was the 1's complain they are too skinny, and 0's complain they are too fat. The hard part is managing the human personalities. The human element takes things into the weeds. I think he was right. Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnupg at securecryptohub.com Tue Sep 16 15:56:13 2025 From: gnupg at securecryptohub.com (Tanveer Salim) Date: Tue, 16 Sep 2025 15:56:13 +0200 (CEST) Subject: Question on Adding Support for Classic McEliece In-Reply-To: <87sego867f.fsf@jacob.g10code.de-O_BV_BV----9> References: <87sego867f.fsf@jacob.g10code.de-O_BV_BV----9> Message-ID: Hi Werner, Thanks for responding. I am now curious. Why was Classic McEliece added to Libgcrypt in that case? Please let me know. Best, Tanveer Salim Sep 15, 2025, 3:33 AM by gnupg-devel at gnupg.org: > On Thu, 11 Sep 2025 02:57, Tanveer Salim said: > >> It seems the GNUPG developers are interested in adding support for Classic >> McEliece in the near future. I am excited about this. Now that GNUPG v >> > > I don't know about this. McEliece was added to Libgcrypt but there is > no plan to add it to GnuPG. The old agreement we had with the PGP.com > folks (PRZ and Jon Callas) still holds. This is to limit the > proliferation of algorithms to the absolutely necessary list. For > example only for political reasons we had to add algorithms like > Camellia, Brainpool, and now FIPS-203 but that's it. > > > > Shalom-Salam, > > Werner > > -- > The pioneers of a warless world are the youth that > refuse military service. - A. Einstein > _______________________________________________ > Gnupg-devel mailing list > Gnupg-devel at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-devel > From rjh at sixdemonbag.org Tue Sep 16 19:57:09 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 16 Sep 2025 13:57:09 -0400 Subject: Question on Adding Support for Classic McEliece In-Reply-To: References: <87sego867f.fsf@jacob.g10code.de-O_BV_BV----9> Message-ID: <51f17f90-a4f6-48cd-8f2f-f5e63b626f05@sixdemonbag.org> > I am now curious. > > Why was Classic McEliece added to Libgcrypt in that case? Why does it support Whirlpool? Or SHA-3? Or Serpent? Or? The answer can be found in the first sentence of libgcrypt's home page: "Libgcrypt is a general purpose cryptographic library?" Libgcrypt supports an awful lot more than just what's needed to implement LibrePGP. It is, as it says, a general-purpose cryptographic library. https://gnupg.org/software/libgcrypt -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 236 bytes Desc: OpenPGP digital signature URL: