From m at gnupg.org Tue Sep 2 09:34:56 2025 From: m at gnupg.org (Meik Michalke) Date: Tue, 02 Sep 2025 09:34:56 +0200 Subject: new GnuPG merchandise available Message-ID: <2182566.YXv2LNvnCZ@kasidy> hi, we're happy to announce that we have launched a new web shop where you can find merchandise to show your support for GnuPG: https://gnupg.myspreadshop.de our main goal here is to enhance the visibility of GnuPG. we will donate our profits to other free software projects which lack financial support. we have been planning to offer merchandise again for a long time, and this print-on-demand service enables us to offer a wide range of products, so we hope there is something for everyone. please contact us if you can't find what you're looking for. you can get a 25% discount for orders within the next 9 days. 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 rjh at sixdemonbag.org Tue Sep 2 09:54:45 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 2 Sep 2025 03:54:45 -0400 Subject: new GnuPG merchandise available In-Reply-To: <2182566.YXv2LNvnCZ@kasidy> References: <2182566.YXv2LNvnCZ@kasidy> Message-ID: <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> > we're happy to announce that we have launched a new web shop where you can > find merchandise to show your support for GnuPG: > > https://gnupg.myspreadshop.de Is there any possibility of GnuPG laptop stickers, or GnuPG-branded OpenPGP cards, or a GnuPG laptop bag? I'd be interested in any and all of them, but branded T-shirts just aren't my thing. -------------- 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 m at gnupg.org Tue Sep 2 10:39:50 2025 From: m at gnupg.org (Meik Michalke) Date: Tue, 02 Sep 2025 10:39:50 +0200 Subject: new GnuPG merchandise available In-Reply-To: <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> References: <2182566.YXv2LNvnCZ@kasidy> <35db5028-0a65-4201-b613-f02289121c0e@sixdemonbag.org> Message-ID: <2323467.n5hnW3eMMA@kasidy> Am Dienstag, 2. September 2025, 09:54:45 CEST schrieb Robert J. Hansen via Gnupg-users: > Is there any possibility of GnuPG laptop stickers, or GnuPG-branded > OpenPGP cards, or a GnuPG laptop bag? I'd be interested in any and all > of them, but branded T-shirts just aren't my thing. FWIW, there's a lot more than just t-shirts, including stickers, mousepads, and various bags and backpacks: https://gnupg.myspreadshop.de/accessoires 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 wk at gnupg.org Tue Sep 2 15:09:48 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:09:48 +0200 Subject: Egon In-Reply-To: <172f9047-ab9b-f8ad-a958-9d4cb77699c0@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Fri, 29 Aug 2025 18:18:57 +0200") References: <46f0c4e6-f3f4-4779-97ad-6408c0526e87@sixdemonbag.org> <87bjo1dfd2.fsf@nyarlathotep> <2e30631d-3c10-d3c0-8965-a88791697543@wisemo.com> <172f9047-ab9b-f8ad-a958-9d4cb77699c0@wisemo.com> Message-ID: <873495dmqr.fsf@jacob.g10code.de> On Fri, 29 Aug 2025 18:18, Jakob Bohm said: > Cool, maybe put that information in the man page near the affected > options (I looked up the options in the Debian Bookworm packaged > man page from package version 2.2.40-1.1) Maybe I should write an update to https://gnupg.org/blog/20160830-web-key-service.html to explain the options we introduced a bit later. 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 wk at gnupg.org Tue Sep 2 15:23:39 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 02 Sep 2025 15:23:39 +0200 Subject: Get pinentry to work in a container In-Reply-To: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> (zyxhere's message of "Sun, 31 Aug 2025 01:41:19 +0500") References: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> Message-ID: <87y0qxc7j8.fsf@jacob.g10code.de> Hi! This is somewhat off topic but I find it really hard to parse all that Python style quoting. Please remember that many folks are reading this and example and thus is should be easy to read. Saving 10 seconds in writing takes up 1000*2 secoonds to read. Or lets say 500*2 seconds because many won't read it at all due to crude formatting. Compare this snippted from your mail Permissions on /dev/console (that bubblwrap creates): ``` localhost # ll /dev/console crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console ``` Permissions of bind mounted /dev/console: ``` localhost # ll /dev/console crw--w---- 1 nobody nobody 5, 1 Aug 29 21:45 /dev/console ``` to this style: Permissions on /dev/console (that bubblwrap creates): localhost # ll /dev/console crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console Permissions of bind mounted /dev/console: localhost # ll /dev/console crw--w---- 1 nobody nobody 5, 1 Aug 29 21:45 /dev/console tia, 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 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 bernhard at intevation.de Wed Sep 3 09:16:12 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:16:12 +0200 Subject: How to format code in emails to this list In-Reply-To: <87y0qxc7j8.fsf@jacob.g10code.de> References: <5563d48260499725b73ae97a942a4a5ec8b02470.camel@envs.net> <87y0qxc7j8.fsf@jacob.g10code.de> Message-ID: <202509030916.22888.bernhard@intevation.de> Werner, Am Dienstag 02 September 2025 15:23:39 schrieb Werner Koch via Gnupg-users: > This is somewhat off topic but I find it really hard to parse all that > Python style quoting. to be fair, the trend as I have observed it, comes with Markdown style, especially github-flavoured-markdown. > Permissions on /dev/console (that bubblwrap creates): > ``` > localhost # ll /dev/console > crw--w---- 1 1000 nobody 136, 1 Aug 30 20:37 /dev/console > ``` something like ```c int main() { } ``` will give syntax highlighting on platforms like Heptapod (based on the Free Software gitlab core) and others. In that case it helps to mark what kind of output is described. While Python allows for full line strings, it does not have the syntax marking. Overall I think it is okay, though the reStructured text style that you have mentioned, which is more like the original Python documentation, is better to read in a simple email. Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 3 09:21:09 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:21:09 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <87plc9c6t6.fsf@jacob.g10code.de> References: <87plc9c6t6.fsf@jacob.g10code.de> Message-ID: <202509030921.10162.bernhard@intevation.de> Am Dienstag 02 September 2025 15:39:17 schrieb Werner Koch via Gnupg-users: > 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. Congratulations to 2.5.12 and that it is now ready for production usage! As there have not been announcements of 2.5.10 and .11 and the last announcement still had Version 2.5.9 which will soon lead us to the new stable 2.6 series. when did this happen? From 2.5.11 -> .12? Best Regards, Bernhard -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Wed Sep 3 09:26:53 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Wed, 3 Sep 2025 09:26:53 +0200 Subject: WKD <- some sites using it (Re: Egon) In-Reply-To: <87qzwxf3yc.fsf@jacob.g10code.de> References: <46f0c4e6-f3f4-4779-97ad-6408c0526e87@sixdemonbag.org> <87qzwxf3yc.fsf@jacob.g10code.de> Message-ID: <202509030926.53579.bernhard@intevation.de> Am Mittwoch 27 August 2025 12:34:35 schrieb Werner Koch via Gnupg-users: > gpg --locate-external-key foo at exmaple.org > > which does the lookup even if the key already exists in your local > keyring. > > WKD is used at more sites than Proton; > for example kernel.org. ?I think we have some list at wiki.gnupg.org. https://wiki.gnupg.org/WKD#Mail_Service_Providers_offering_WKD -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Wed Sep 3 11:49:32 2025 From: wk at gnupg.org (Werner Koch) Date: Wed, 03 Sep 2025 11:49:32 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <202509030921.10162.bernhard@intevation.de> (Bernhard Reiter via Gnupg-users's message of "Wed, 3 Sep 2025 09:21:09 +0200") References: <87plc9c6t6.fsf@jacob.g10code.de> <202509030921.10162.bernhard@intevation.de> Message-ID: <87bjnrdfwz.fsf@jacob.g10code.de> On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > Congratulations to 2.5.12 and that it is now ready for production usage! It has been for quite some time: Note that this 2.5 series [...] I just added a note to make this more clear. FWIW, we have customers using this on their systems since December. Salam-Shalom, 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 Wed Sep 3 18:32:25 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Wed, 3 Sep 2025 18:32:25 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: <87bjnrdfwz.fsf@jacob.g10code.de> References: <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: On 3 Sep 2025, at 11:47, Werner Koch via Gnupg-users wrote: > > On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > >> Congratulations to 2.5.12 and that it is now ready for production usage! > > It has been for quite some time: > > Note that this 2.5 series [...] > > I just added a note to make this more clear. FWIW, we have customers > using this on their systems since December. It used to be that the marker of whether a gnupg release was ?production ready? or not was the odd vs even minor release number. Will this no longer be the case in the future? Thanks, A From fg.gnupg at shimps.de Wed Sep 3 19:19:39 2025 From: fg.gnupg at shimps.de (Frank Guthausen) Date: Wed, 3 Sep 2025 19:19:39 +0200 Subject: [Announce] GnuPG 2.5.12 released In-Reply-To: References: <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: <20250903191939.419b2794@incubator.example.com> Hello. On Wed, 3 Sep 2025 18:32:25 +0200 Andrew Gallagher via Gnupg-users wrote: > > It used to be that the marker of whether a gnupg release was > ?production ready? or not was the odd vs even minor release number. > Will this no longer be the case in the future? As I read the announce mail | This means we won't break anything but may add some | more features before 2.6. the minor release number change will happen in the future, but the quality of the development branch is high thus it can be recommended for production even before this number change. -- kind regards Frank -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: OpenPGP digital signature URL: From bernhard at intevation.de Thu Sep 4 10:11:37 2025 From: bernhard at intevation.de (Bernhard Reiter) Date: Thu, 4 Sep 2025 10:11:37 +0200 Subject: 2.5.12 production ready (Re: [Announce] GnuPG 2.5.12 released) In-Reply-To: <87bjnrdfwz.fsf@jacob.g10code.de> References: <87plc9c6t6.fsf@jacob.g10code.de> <202509030921.10162.bernhard@intevation.de> <87bjnrdfwz.fsf@jacob.g10code.de> Message-ID: <202509041011.37387.bernhard@intevation.de> Am Mittwoch 03 September 2025 11:49:32 schrieb Werner Koch via Gnupg-users: > On Wed, 3 Sep 2025 09:21, Bernhard Reiter said: > > Congratulations to 2.5.12 and that it is now ready for production usage! > > It has been for quite some time: > > Note that this 2.5 series [...] This note first appeared in the 2.5.12 announcement, the last release announcement was 2.5.9 and did not have this note. > I just added a note to make this more clear. Very good, may I ask where: for the next annoucement or on the webpages? I think Andrew's question is good, if the even odd logic is kept. It helps to communicate to our users. Of course a mature 2.5. series can be "production ready" and still not "stable" in the sense that more features are planned. > FWIW, we have customers using this on their systems since December. Good to know! (General remark: pre-releases can be used in production if the usage is known and monitored closely. And the more usage a product revision or series sees, the better.) -- https://intevation.de/~bernhard ? +49 541 33 508 3-3 Intevation GmbH, Osnabr?ck, DE; Amtsgericht Osnabr?ck, HRB 18998 Gesch?ftsf?hrer: Frank Koormann, Bernhard Reiter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From bkw.2524710 at 150mpg.com Thu Sep 4 17:40:28 2025 From: bkw.2524710 at 150mpg.com (Bryan K. Walton) Date: Thu, 04 Sep 2025 10:40:28 -0500 Subject: Formatting issue with pinentry-fltk? Message-ID: I've recently switched from X11 (with I3) to Wayland (with Sway). Therefore, I've also switched from using pinentry-gtk2 to pinentry-fltk. This is working for me. However, I've noticed that the pinentry prompt is only showing the first part of my secret key? Specifically, it shows something like this: Please enter the passphrase to unlock the OpenPGP secret key: "Firstname LastName " 4096-bit RSA key, ID xxxxxxxxxxxxx, created 2024-05-13 (main key ID yyyyyyyyyyyyy). Passphrase: I'm curious if the truncated key information shown by pinentry-fltk is intentional? Is there a way that I can configure pinentry-fltk to show all of the information that was shown by pinentry-gtk2? Thanks, Bryan From gk at leniwiec.biz Thu Sep 4 21:45:55 2025 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Thu, 4 Sep 2025 21:45:55 +0200 Subject: TPM and PCRs Message-ID: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> Hello, I know that gnupg supports TPMs (from 2.3 IIRC) via keytotpm command. But AFAIK the main "selling point" of TPMs is binding encryption of secrets to specific software versions and system state via hashes (PCRs), so that the enrolled key is only accessible (may be "unsealed") if specific trusted software and/or configuration is used. Does gpg supports binding keys to PCRs' state? Are there any plans to add such feature? Is it possible to somehow work it around before it is implemented? Thank you in advance. -- Grzegorz Kulewski From lee at zoo.dev Fri Sep 5 15:29:38 2025 From: lee at zoo.dev (Lee) Date: Fri, 5 Sep 2025 09:29:38 -0400 Subject: Silent failure when keyboxd is not running, no error or warning Message-ID: <6ad3fd88-49e9-4f0a-8408-5ac2dff78cb4@zoo.dev> Hello, hope you're all doing well! Today I noticed when trying to list my private keys with `--list-secret-keys` that nothing appeared. I was very confused. After some debugging with `--list-secret-keys --debug-all`, this line stood out: gpg: DBG: chan_4 <- ERR 134217755 Not found After re-verifying all my secret keys were really there on storage, and I had a pubring.kbx, I began to look through `gpg.conf` and `common.conf`. Behold, there was a `use-keyboxd` there. Deleting this line, I could use my keys again. It would have been really nice for gpg to report the internal error I pasted above, as "Unable to communicate with keyboxd", instead of a silent failure causing me to have a minor heart palpitation :) Thank you all for your super hard work on GPG! Lee From mcr at sandelman.ca Fri Sep 5 21:36:01 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 05 Sep 2025 15:36:01 -0400 Subject: TPM and PCRs In-Reply-To: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> Message-ID: <13271.1757100961@obiwan.sandelman.ca> Grzegorz Kulewski wrote: > I know that gnupg supports TPMs (from 2.3 IIRC) via keytotpm command. I have never used keytotpm myself, as yet. (I am deep in the openssl provider interface, trying to use it with openssl-tpm2, via ruby-openssl, to sign PKIX certificates, COSE/JOSE and CMS artifacts, and eventually, yes git commits using some tbd openpgp tool) (Also editor of RFC9334 Remote?ATtestation?procedureS?(RATS)?Architecture) > But AFAIK the main "selling point" of TPMs is binding encryption of > secrets to specific software versions and system state via hashes > (PCRs), so that the enrolled key is only accessible (may be "unsealed") > if specific trusted software and/or configuration is used. It's the major selling point, but it's not really the only thing they are good for. > Does gpg supports binding keys to PCRs' state? Are there any plans to > add such feature? Is it possible to somehow work it around before it is > implemented? You are kinda asking the question wrong. GNUPG is just an application; it has no special priviledge with the TPM. The question you should ask: are there TPMs and/or priviledged TPM interactions where a GNUPG private key could be unsealed by TPM only once the system is in a known trustoworthy state? I think that the answer is sorta. The evaluation ("Verification") of whether a final state PCR (Evidence) is valid or not generally something that occurs locally: You can't trust a trojan'ed system to claim to not be trojaned. While measured boot depends upon a root of trust, and that part usually involves a secured boot, if one wants to do secure boot all the way, then it leads to profound vendor lock-in, and "treasurous computing", that's really the only way to build a system that independantly can be judged as to whether or not it's in the right state. So in *this* model, you could imagine some thing returned from the Verifier that would allow a priviledged process to ask the TPM to unseal something. I'm unaware of any existing system that does exactly this, but that's probably just my limited knowledge. My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the main (disk) decryption key is stored in the TPM. It's only protected because the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and ability to talk to the TPM is restricted. Attacks on this have involved hardware access to i2c bus; there are ways to defend against this by encrypting that bus using the EK, but in that case, the main CPU has to have a copy of the EK public key somewhere safe. I suspect that your ultimate goal might be better satisfied with a USB connected secure element, with the ability to physically remove it from the system. An ummarked USB secure element key in a locked drawer full of USB keys containing endless pictures of cats is what I'd do :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: From gk at leniwiec.biz Fri Sep 5 22:12:50 2025 From: gk at leniwiec.biz (Grzegorz Kulewski) Date: Fri, 5 Sep 2025 22:12:50 +0200 Subject: TPM and PCRs In-Reply-To: <13271.1757100961@obiwan.sandelman.ca> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> <13271.1757100961@obiwan.sandelman.ca> Message-ID: <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> W dniu 05.09.2025 o?21:36, Michael Richardson pisze: > Grzegorz Kulewski wrote: > > Does gpg supports binding keys to PCRs' state? Are there any plans to > > add such feature? Is it possible to somehow work it around before it is > > implemented? > > You are kinda asking the question wrong. > GNUPG is just an application; it has no special priviledge with the TPM. > > The question you should ask: are there TPMs and/or priviledged TPM interactions > where a GNUPG private key could be unsealed by TPM only once the system is in > a known trustoworthy state? > I think that the answer is sorta. > > The evaluation ("Verification") of whether a final state PCR > (Evidence) is valid or not generally something that occurs locally: You can't > trust a trojan'ed system to claim to not be trojaned. While measured boot > depends upon a root of trust, and that part usually involves a secured boot, > if one wants to do secure boot all the way, then it leads to profound vendor > lock-in, and "treasurous computing", that's really the only way to build a > system that independantly can be judged as to whether or not it's in the right state. > > So in *this* model, you could imagine some thing returned from the Verifier > that would allow a priviledged process to ask the TPM to unseal something. > I'm unaware of any existing system that does exactly this, but that's probably just > my limited knowledge. > > My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the > main (disk) decryption key is stored in the TPM. It's only protected because > the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and > ability to talk to the TPM is restricted. Attacks on this have involved > hardware access to i2c bus; there are ways to defend against this by > encrypting that bus using the EK, but in that case, the main CPU has to have > a copy of the EK public key somewhere safe. I am not an expert but AFAIK when sealing a secret in TPM you can bind it to some PCR state (or not). I believe any code that can open TPM /dev can do this, not something "privileged". But if gpg doesn't do it then the secret is not protected by any "verified state" bindings and nothing (except improving gpg and sealing that key again) can be done about it. But maybe I am wrong. I see no option to tell gpg to bind the key to some PCRs - that's why I am asking about plans to implement such feature. Yes, AFAIK using PCRs is only possible (and makes sense) when secure boot is enabled. Of course security of such "verified state" depends on perfect (or good enough) implementation all the way from TPM and CPU via UEFI, bootloader, kernel, initramfs to root fs verification. So it's probably not 100% perfect and can have a lot of holes. But it's the only thing (except maybe PIN, if it's used and if it's still secret) that can potentially stop attacker from just booting some LiveCD and unsealing and using the key there. AFAIK in most (all?) cases keys are not stored in TPM but only sealed (encrypted) by it and stored on disk and then unsealed (bound state is verified, if any, key is decrypted and loaded into TPM so it can be used to do further crypto). Not sure about rest of your message and it's relevance to my original question. > I suspect that your ultimate goal might be better satisfied with a USB > connected secure element, with the ability to physically remove it from the > system. An ummarked USB secure element key in a locked drawer full of USB > keys containing endless pictures of cats is what I'd do :-) Not sure how do you know my goals from my original post. :-) Basically we _are_ using USB SEs too. They are "user bound" (user is supposed to carry them all the time) and they often require physical interaction to unseal the key. But for some keys it's more convenient for them to be "machine bound" (forever bound to some computer and only usable if the computer is in a "valid secure state", not necessarily when user is physically present). That's why using TPM is convenient in those cases. For example you may want to store your company VPN key in the TPM (and only allow it to be unsealed if company approved OS is booted and wasn't tampered with) while storing your normal SSH/e-mail/whatever keys in USB SE. If some service (SSH for example) requires both VPN and such USB key you are basically getting double protection. Also note that in such cases some operations (for example backups via VPN) can happen when computer is booted and the TPM key is unsealed but the user and their USB SE can be away while some (for example SSH login via VPN) require both "secure computer" and "physical presence of the user" - it's a matter of policy planning and configuration. -- Grzegorz Kulewski From mcr at sandelman.ca Sat Sep 6 04:26:17 2025 From: mcr at sandelman.ca (Michael Richardson) Date: Fri, 05 Sep 2025 22:26:17 -0400 Subject: TPM and PCRs In-Reply-To: <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> References: <04327697-b0bb-d544-89e2-62c75f09aab4@leniwiec.biz> <13271.1757100961@obiwan.sandelman.ca> <054deab3-6018-5a6d-b95d-c0d0636f6292@leniwiec.biz> Message-ID: <26263.1757125577@obiwan.sandelman.ca> Grzegorz Kulewski wrote: >> My understanding of how TPM-enabled LUKS and MS Bitlocker work is that the >> main (disk) decryption key is stored in the TPM. It's only protected because >> the TPM is not the main CPU (or is a TEE of the main CPU, if fTPM), and >> ability to talk to the TPM is restricted. Attacks on this have involved >> hardware access to i2c bus; there are ways to defend against this by >> encrypting that bus using the EK, but in that case, the main CPU has to have >> a copy of the EK public key somewhere safe. > I am not an expert but AFAIK when sealing a secret in TPM you can bind > it to some PCR state (or not). I believe any code that can open TPM I'm not intimately familiar with sealing based upon PCR state. I would hesistate to go this direction because PCR state is rather fragile. (Annoyingly so, and I suspect unnecessarily so) It depends upon the amount of ram installed, BIOS/UEFI options! I think that in some cases, having a bootable USB key inserted, even when it's not used for boot, can change things! > /dev can do this, not something "privileged". But if gpg doesn't do it > then the secret is not protected by any "verified state" bindings and > nothing (except improving gpg and sealing that key again) can be done > about it. But maybe I am wrong. I see no option to tell gpg to bind the > key to some PCRs - that's why I am asking about plans to implement such > feature. I think that one would have to use some tpm2_ or tss-* tools to configure this. I think that after that, it's just a question of having the interface, probably the PKCS11 interface can be used... The abrmd process can mitigate access to /dev/tpm*, and that's mostly how you'd want it. Otherwise, one would be relying on just group permissions on /dev/tpm*. Going via the abrmd allows for the possibility of a richer ACLs in the future too. > Yes, AFAIK using PCRs is only possible (and makes sense) when secure > boot is enabled. Of course security of such "verified state" depends on > perfect (or good enough) implementation all the way from TPM and CPU > via UEFI, bootloader, kernel, initramfs to root fs verification. To be clear: secure boot is when each stage verifies a signature on the next step of boot. The *public* root of trust key can be stored in a TPM for integrity protection. Or burnt into a ROM. Many microcontrollers have eFuses for this purpose. PCRs are generally used for *measured* boot, where each stage measures (SHA256 hash, etc.) the next stage, but does not know how to verify if it's correct or not. This is significantly more democratic. > So > it's probably not 100% perfect and can have a lot of holes. But it's > the only thing (except maybe PIN, if it's used and if it's still > secret) that can potentially stop attacker from just booting some > LiveCD and unsealing and using the key there. > AFAIK in most (all?) cases keys are not stored in TPM but only sealed > (encrypted) by it and stored on disk and then unsealed (bound state is You can do either. TPMs have historically had very limited space for keys, so, yes, one seals the private key with the TPM, and then stores the encrypted blob on disk. But, that space is growing, and fTPMs (a software TPM running in a SGX or TrustZone or other TEE) often have significant space, but obviously how much flash they have access is not infinite. And that flash has to sealed. >> I suspect that your ultimate goal might be better satisfied with a USB >> connected secure element, with the ability to physically remove it from the >> system. An ummarked USB secure element key in a locked drawer full of USB >> keys containing endless pictures of cats is what I'd do :-) > Not sure how do you know my goals from my original post. :-) It's true, I made assumptions. I mean, do you even like cats? And did those cats even consent to have their image used in that way? :-) > Basically we _are_ using USB SEs too. They are "user bound" (user is > supposed to carry them all the time) and they often require physical > interaction to unseal the key. > But for some keys it's more convenient > for them to be "machine bound" (forever bound to some computer and only > usable if the computer is in a "valid secure state", not necessarily > when user is physically present). Yes, I completely agree that this is a desired thing. > That's why using TPM is convenient in > those cases. For example you may want to store your company VPN key in > the TPM (and only allow it to be unsealed if company approved OS is > booted and wasn't tampered with) while storing your normal And just to be clear: in this case, there is often an interaction with the company's Verifier before the VPN key is unlocked. This interaction is often not easily visible. ActiveDirectory is involved. My understanding is that the user login to laptop also unlocks a kerberos ticket that contains the unseal key. (But I'm priviledged to have never really run windows) > SSH/e-mail/whatever keys in USB SE. If some service (SSH for example) > requires both VPN and such USB key you are basically getting double > protection. Also note that in such cases some operations (for example > backups via VPN) can happen when computer is booted and the TPM key is > unsealed but the user and their USB SE can be away while some (for > example SSH login via VPN) require both "secure computer" and "physical > presence of the user" - it's a matter of policy planning and > configuration. All good reasons to have many different kinds of keys. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 511 bytes Desc: not available URL: From borden_c at tutanota.com Fri Sep 12 22:02:43 2025 From: borden_c at tutanota.com (Borden) Date: Fri, 12 Sep 2025 22:02:43 +0200 (CEST) Subject: Multiple issues in GPG documentation Message-ID: I'm trying to work through the documentation on https://www.gnupg.org/documentation, which is largely OK, but I've noticed multiple issues: 1. The gpgsm documentation for the --generate-key command says that it can "either create a certificate signing request (CSR)or an X.509 certificate." However, I've only ever got CSRs from it, and I don't see anything anywhere explaining how to generate a X.509 certificate. 2. The gpgsm documentation says that it supports an --output parameter, yet when I try to use it, the software complains that --output isn't a valid parameter, so I have to use output redirect instead. 3. Incidentally, it's great that gpgsm supports a --batch parameter, which lets me use a parameter file for my CSR. Is there any support to redirected input into gpgsm --generate-key to answer the questions automatically? 4. The FAQs would benefit from updating, as I don't think questions like "Is this the official GnuPG FAQ?" are that "frequently asked." More topically, it has several FAQs discouraging users from using anything longer than RSA-2048, when it now defaults to RSA-3072. I'm surprised it hasn't caused more confusion for newcomers. 5. A problem that took me hours to figure out was how to certify and trust a new user ID in a GPG key. Again, I'm not sure where documentation on this is hiding. It certainly doesn't explain how to use a different signing key to certify the user ID, which is the only way I could control the trust level. Again, the FAQ talks abstractly about what "trust" and "verification" mean, but don't provide any implementation details. 6. I question whether the FAQ's discussion on algorithms in is up-to-date. It gives no mention to ed25519, which I understand is the most reliable ECC cypher. It says that 3DES is still reliable, but I thought all DES-based cyphers were obsolete. I've never seen Camellia offered as a GPG cypher option, so I'm not sure of the relevance of including it. You get the picture. I understand that I need to request an account to file bugs, and I'd probably need a different account to propose changes to the documentation. Are there any quick answers to my questions above? From rjh at sixdemonbag.org Sat Sep 13 01:49:02 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 12 Sep 2025 19:49:02 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: Hi! I'm the principal author of the FAQ. > 4. The FAQs would benefit from updating Yes, they would. I stepped away from my role as FAQ maintainer a few years ago in protest of some very unwise decisions by the FSF. It's been unmaintained since. I'm working on a totally rewritten FAQ, but it will be entirely my own work and not FSF/FSFE supported. Unfortunately, progress on this has gone quite slowly due to a health crisis (which is slowly improving, thank you to everyone who's thought of me). > I don't think questions like "Is this the official GnuPG FAQ?" are > that "frequently asked." That was in fact the *most* frequently asked. It started life as my own personal list of questions people kept asking me. Far and away the most commonly asked question was whether my personal FAQ represented official guidance from GnuPG and/or whether I was an official team member. That FAQ used to have an answer of "No, and I'm not part of the GnuPG team." > More topically, it has several FAQs discouraging users from using > anything longer than RSA-2048, when it now defaults to RSA-3072. Yes, it badly needs a refresh. > 6. I question whether the FAQ's discussion on algorithms in is up-to- > date. It gives no mention to ed25519, which I understand is the most > reliable ECC cypher. It says that 3DES is still reliable, but I > thought all DES-based cyphers were obsolete. I've never seen > Camellia offered as a GPG cypher option, so I'm not sure of the > relevance of including it. You get the picture. It predates widespread adoption of ECC. 3DES is still considered secure for files under about 8 MiB in size. Past that you run into an unacceptable risk of block collision attacks. The FAQ's guidance on 3DES is still accurate. (It may say to avoid 3DES for files larger than 1 GiB, which was accurate at the time of writing.) 3DES is not a recommended cipher due to the 64-bit block size, or how slow and inefficient it is. There are many good reasons to prefer more modern algorithms and I don't want to be mistaken for sounding like I'm recommending 3DES. I'm not. But it's still considered quite safe against cryptanalysis for files smaller than 8 MiB. -------------- 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 rjh at sixdemonbag.org Sat Sep 13 01:59:27 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Fri, 12 Sep 2025 19:59:27 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: <43939995-ee30-4f3b-8a5e-bde5c08be92e@sixdemonbag.org> Oh, also: > I've never seen Camellia offered as a GPG cypher option rjh at sarah:~$ gpg --version gpg (GnuPG) 2.4.6 libgcrypt 1.11.0 Copyright (C) 2024 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home/rjh/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 Right there you go, Camellia in three keylengths on Fedora Workstation 42. It is almost certainly supported by your GnuPG installation. > so I'm not sure of the relevance of including it. Camellia is Japan's answer to AES and is included in GnuPG in order to better support the needs of Japanese users. -------------- 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 pyromania at disroot.org Sat Sep 13 01:49:52 2025 From: pyromania at disroot.org (Pyromania) Date: Fri, 12 Sep 2025 23:49:52 +0000 Subject: Multiple issues in GPG documentation In-Reply-To: (Borden via Gnupg-users's message of "Fri, 12 Sep 2025 22:02:43 +0200 (CEST)") References: Message-ID: On Fri, Sep 12 2025, Borden via Gnupg-users wrote: [?21L?] > I'm surprised it hasn't caused more confusion for newcomers. I guess, it definitely has; many newcomers just don?t bother to provide any feedback. > 5. A problem that took me hours to figure out was how to certify and > trust a new user ID in a GPG key. Again, I'm not sure where > documentation on this is hiding. It certainly doesn't explain how to > use a different signing key to certify the user ID, which is the only > way I could control the trust level. Again, the FAQ talks abstractly > about what "trust" and "verification" mean, but don't provide any > implementation details. I had the same problem, too. [?17L?] -- English is not my native/mother language. I can read and understand English well, but I have problems expressing my thoughts in it. Please, bear with me. Sincerely, Pyromania. PGP fingerprint = 2B24 291E 0637 4D2E 0D14 9EFC D7B3 10D4 5C9D 5892 () ASCII ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments From borden_c at tutanota.com Sat Sep 13 07:03:30 2025 From: borden_c at tutanota.com (Borden) Date: Sat, 13 Sep 2025 07:03:30 +0200 (CEST) Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: > Yes, they would. I stepped away from my role as FAQ maintainer a few > years ago in protest of some very unwise decisions by the FSF. It's been > unmaintained since. I'm working on a totally rewritten FAQ, but it will > be entirely my own work and not FSF/FSFE supported. Unfortunately, > progress on this has gone quite slowly due to a health crisis (which is > slowly improving, thank you to everyone who's thought of me). > I'm very sympathetic to your political issues, of which I have similar stories from other projects. I recently saw a video of Torvalds explaining why he has nothing to do with the FSF. Something about them being well-intentioned but extremist fanatics. I'm happy that you are on the mend (although this is our only introduction, but still, basic human decency). I lack technical competence, but if I can help at all, feel free to reach out. > That was in fact the *most* frequently asked. > I stand corrected. > 3DES is still considered secure for files under about 8 MiB in size... > For what it's worth, I select my encryption algorithms based on two criteria: 1. If I'm encrypting for someone else's service (typically, SSH), what cyphers do they support? 2. If I'm encrypting for myself, what's the most advanced and future-proofed cypher I can use that my hardware supports? Although your comprehensive discussions on cyphers is certainly interesting, if you want to streamline your workflow, perhaps consider linking to other discussions (like Wikipedia) for?technical and historical information. Otherwise, recommending a couple really good cyphers may make the FAQ more digestible for newcomers. Just occurred to me: you may want to consider adding an FAQ about which cyphers are quantum vulnerable, since newcomers will probably want advice on that. > Right there you go, Camellia in three keylengths on Fedora Workstation 42. It is almost certainly supported by your GnuPG installation. > My comments were unclear. I agree that gpg (which I confirm on my Debian box) supports Camellia. My point was that it doesn't seem easy to access. Specifically, when I run `gpg --full-generate-key --expert`, I get these options: ``` (1) RSA and RSA (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC (sign and encrypt) *default* (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key (14) Existing key from card ``` ... none of which appear to lead me to a Camellia key. Having said that, being a symmetric cypher, maybe it's only supported for directly encrypting documents and not generating keys. I was trying to say that the attention it gets seems excessive to the ease of generating it. I would think that RSA, DSA & ECC cyphers would be far more relevant and should be the focus of that discussion. I used it as an example, and there are other cyphers that are completely unfamiliar to me. Then again, I respect that you could have been bombarded with so many questions about Camellia and the other cyphers that you added it to your FAQ. From collin.funk1 at gmail.com Sat Sep 13 08:12:08 2025 From: collin.funk1 at gmail.com (Collin Funk) Date: Fri, 12 Sep 2025 23:12:08 -0700 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: <875xdmzxs7.fsf@gmail.com> Borden via Gnupg-users writes: > For what it's worth, I select my encryption algorithms based on two criteria: > > 1. If I'm encrypting for someone else's service (typically, SSH), what cyphers do they support? > 2. If I'm encrypting for myself, what's the most advanced and future-proofed cypher I can use that my hardware supports? Number 1 is a bad idea. Some services still support legacy ciphers for backwards comparability. A recent example is Microsoft's Active Directory defaulting to RC-4 [1]. This cipher has been known to be insecure for decades now [2]. Generally, NIST recommendations can be trusted. Minus a few exceptions where researchers raised alarms [3]. > Just occurred to me: you may want to consider adding an FAQ about which cyphers are quantum vulnerable, since newcomers will probably want advice on that. I think that is a bit technical for an FAQ. Quantum computing is still an active field of research, and it will likely be quite some time before current algorithms are broken. The worry about quantum computers is because of their theoretical ability to efficiently perform integer factorization and solve the discrete logarithm problem [4]. Efficiently performing integer factorization would make RSA insecure. Solving the discrete log problem would make Diffie-Hellman key exchanges insecure. I don't know much about quantum computing, so maybe someone else on the list can cover anything I missed. >> Right there you go, Camellia in three keylengths on Fedora Workstation 42. It is almost certainly supported by your GnuPG installation. >> > My comments were unclear. I agree that gpg (which I confirm on my > Debian box) supports Camellia. My point was that it doesn't seem easy > to access. Specifically, when I run `gpg --full-generate-key > --expert`, I get these options: > > ``` > (1) RSA and RSA > (2) DSA and Elgamal > (3) DSA (sign only) > (4) RSA (sign only) > (7) DSA (set your own capabilities) > (8) RSA (set your own capabilities) > (9) ECC (sign and encrypt) *default* > (10) ECC (sign only) > (11) ECC (set your own capabilities) > (13) Existing key > (14) Existing key from card > ``` > > ... none of which appear to lead me to a Camellia key. Having said > that, being a symmetric cypher, maybe it's only supported for directly > encrypting documents and not generating keys. I was trying to say that > the attention it gets seems excessive to the ease of generating it. I > would think that RSA, DSA & ECC cyphers would be far more relevant and > should be the focus of that discussion. I used it as an example, and > there are other cyphers that are completely unfamiliar to me. Camellia is a symmetric cipher so you would not use it to create a key. You can use it to encrypt a file like so: $ echo 'abc' > input $ gpg --symmetric --cipher-algo CAMELLIA256 input Enter passphrase: $ rm input $ gpg --decrypt input.gpg Enter passphrase: gpg: CAMELLIA256.CFB encrypted data gpg: encrypted with 1 passphrase abc Collin [1] https://arstechnica.com/security/2025/09/senator-blasts-microsoft-for-making-default-windows-vulnerable-to-kerberoasting/ [2] https://en.wikipedia.org/wiki/RC4#Security [3] https://en.wikipedia.org/wiki/National_Institute_of_Standards_and_Technology#Controversy_regarding_NIST_standard_SP_800-90 [4] https://en.wikipedia.org/wiki/Shor's_algorithm From borden_c at tutanota.com Sat Sep 13 18:01:35 2025 From: borden_c at tutanota.com (Borden) Date: Sat, 13 Sep 2025 18:01:35 +0200 (GMT+02:00) Subject: Multiple issues in GPG documentation In-Reply-To: <875xdmzxs7.fsf@gmail.com> References: <875xdmzxs7.fsf@gmail.com> Message-ID: > Some services still support legacy ciphers for backwards comparability. > This is a distraction to my original e-mail, but I was referring to how some SSH servers don't support ECC so I need to use RSA. GPG deprecates weak ciphers, anyhow (right?), so I'm unclear on what relevance it has to GPG. > I think that is a bit technical for an FAQ. Quantum computing is still an active field of research, and it will likely be quite some time before current algorithms are broken. > If we added a FAQ to the effect of: "Is GPG quantum secure? "Although there are currently no known quantum computers or attacks that can crack the cyphers used in GPG, quantum computers could theoretically drastically shorten brute force attacks against algorithms X, Y, & Z that would make them crackable. "Algorithms A, B & C (if any) used in GPG are not known to be vulnerable to these sorts of attacks." ... I don't think that would be any more technical than the existing FAQ documentation. We don't need to go into the theory of superposition to provide useful information. > Camellia is a symmetric cipher so you would not use it to create a key. > Understood. Since I haven't used GPG to encrypt anything directly, that would explain why it hasn't been offered to me. From rjh at sixdemonbag.org Sat Sep 13 19:41:38 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Sep 2025 13:41:38 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: > Although your comprehensive discussions on cyphers is certainly > interesting, if you want to streamline your workflow, perhaps > consider linking to other discussions (like Wikipedia) for technical > and historical information. Otherwise, recommending a couple really > good cyphers may make the FAQ more digestible for newcomers. The FAQ *does* recommend a couple of good ciphers. There is a recurring line in the FAQ, words to the effect of "unless you know what you're doing and why, just use the defaults." It's surprisingly awesome advice. If you just use the defaults you'll get an excellent selection of algorithms. You don't need to tweak anything. However, no matter how often I told people this, quite often they would come back with "no, really, which ones are the _best_?" And I can't answer that -- "best" is inherently subjective -- but I can give brief breakdowns on the different ciphers. And I was asked to do this often enough that I just threw it in the FAQ. > Just occurred to me: you may want to consider adding an FAQ about > which cyphers are quantum vulnerable, since newcomers will probably > want advice on that. It's due for the rewrite, but that question is surprisingly hard. RSA is considered far more quantum-resistant than ECC, for instance, and most of the modern ciphers in the suite are inherently quantum-resistant but some are potentially not. And then you have to weigh against practical engineering realities: sure, a 128-bit cipher can _theoretically_ be brute-forced by a large quantum computer in 2**64 time using Grover's algorithm, but the energy requirements to create the ensemble are ... uh. Well. "Extraordinarily silly" might be the only polite answer there. Cryptographic engineering is not the same as cryptography. Cryptography is a purely mathematical field; if you can reduce a 128-bit cipher to a 2**64 work factor, well, that might be very significant. But cryptographic engineering asks questions like, "what are the time, energy, and space requirements for this attack?", and if an attack is totally unfeasible then it's not really an attack at all, is it? Years ago I talked down some user who found some obscure paper that promised to break some cipher or another in a small work factor... although it required about 10^33 joules of energy to pull off. Okay, great, as soon as we build a Dyson sphere around the sun I'll start worrying. But not until the 10^8 seconds necessary to collect all that energy have passed. > My comments were unclear. I agree that gpg (which I confirm on my > Debian box) supports Camellia. My point was that it doesn't seem > easy to access. Specifically, when I run `gpg --full-generate-key -- > expert`, I get these options: When generating a certificate, you're asked for which asymmetric algorithms should be used for encryption and signing. Camellia is a symmetric algorithm. Add CAMELLIA256 to your list of personal-cipher-preferences and GnuPG will start using Camellia when appropriate. For instance, I quite like Camellia: it's construction is a lot like AES but I find it a little clearer and easier to implement (which is a *totally* subjective call), which means I tend to think Camellia implementations will be maybe a little better (again, *totally* subjective). So my own personal-cipher- preference (in ~/.gnupg/gpg.conf) reads: personal-cipher-preferences CAMELLIA256 AES256 TWOFISH CAMELLIA192 \ AES192 CAMELLIA128 AES BLOWFISH CAST5 \ 3DES (Note: that should all be placed on one single line. The backslash is meant to indicate data is broken across multiple lines; it should not be included in the final single line.) This tells GnuPG, "when choosing which symmetric cipher to use, prefer the 256-bit symmetric ciphers starting with Camellia256; only if no 256- bit cipher is available should we choose a 192-bit cipher starting with Camellia192; only if no 192-bit cipher is available should we fall back to 128-bit ciphers starting with Camellia128; and only if everything else fails should we fall back to 3DES." > Then again, I respect that you could have been bombarded with so > many questions about Camellia and the other cyphers that you added > it to your FAQ. A lot of people see unusual names in the output of --version and ask, "hey, what's Camellia?" I have to be honest here: most of the people asking these questions are not competent to evaluate which ciphers are better or worse, or how they are better or worse, or the mathematical structures, or... etc. And that's okay. But that's why the discussion of ciphers is kept at a very high level, giving basic background information and nothing more. This is also why the FAQ doesn't link to Wikipedia, which tends to be very newbie-unfriendly. Looking at the Wikipedia page on Camellia, for instance: https://en.wikipedia.org/wiki/Camellia_(cipher) That page has language like, "Camellia is a Feistel cipher with either 18 rounds (when using 128-bit keys) or 24 rounds (when using 192- or 256-bit keys). Every six rounds, a logical transformation layer is applied: the so-called "FL-function" or its inverse. Camellia uses four 8?8-bit S-boxes with input and output affine transformations and logical operations. The cipher also uses input and output key whitening. The diffusion layer uses a linear transformation based on a matrix with a branch number of 5." Which is all true, you know, but it's also not exactly accessible to people who don't have a strong background in cryptography. Wikipedia is a great resource, but for newbies it's sometimes a little daunting. -------------- 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 borden_c at tutanota.com Sun Sep 14 01:25:04 2025 From: borden_c at tutanota.com (Borden) Date: Sun, 14 Sep 2025 01:25:04 +0200 (CEST) Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: > The FAQ *does* recommend a couple of good ciphers. There is a recurriing line in the FAQ, words to the effect of "unless you know what you're doing and why, just use the defaults." > My point exactly. So why not streamline the documentation to explaining the defaults and offloading everything else to somewhere where keeners can go down the rabbit hole? > I can't answer that -- "best" is inherently subjective -- but I can give brief breakdowns on the different ciphers. And I was asked to do this often > enough that I just threw it in the FAQ. > Fair. Which is why I suggest consolidating it all into one question that goes to the effect of "The 'best' cyphers are the ones we set to the defaults." I think the question people mean to ask - as it's one I often have - is "What's the difference between them?" or "What's the best for _my_ situation?" If people are anything like me (and fortunately almost all of them aren't), I think they come from believing that if one algorithm were universally the best, everyone would use it. But since we have different algorithms, there surely must be some reason why people went through all that extra effort. Again, advising to offload discussion onto other sources, I think the best response to that FAQ is to provide a layman's difference between them. Something to the effect of "Algo X is faster than Y, but Y produces more compact hashes than Z, but Z has higher resistance to side attacks than X, etc." Wikipedia has comparison pages that, often in a tabular format, summarise the differences in whatever - like database engines or text editors. A table like that should shut most people up (if they bother to read it). If Wikipedia, or somewhere else, has a page comparing cyphers, so much the better. Link to it and save some typing. > It's due for the rewrite, but that question is surprisingly hard. RSA is considered far more quantum-resistant than ECC, for instance, and most of the modern ciphers in the suite are inherently quantum-resistant but some are potentially not. And then you have to weigh against practical engineering realities: sure, a 128-bit cipher can _theoretically_ be brute-forced by a large quantum computer in 2**64 time using Grover's algorithm, but the energy requirements to create the ensemble are ... uh. Well. > Perfect answer. Plug it in the FAQ. Better still, make it a column in that comparison table I was talking about: "Theoretical resistance to quantum cracking" ... "Weaker"; "Stronger"; "Vulnerable" etc. > When generating a certificate, you're asked for which asymmetric algorithms should be used for encryption and signing. Camellia is a symmetric algorithm. > Noted. Would also be a good column for that table: "One-way hash"; "Asymmetric"; "Symmetric" > I quite like Camellia: it's construction is a lot like AES but I find it a little clearer and easier to implement (which is a *totally* subjective call), > I would offload that discussion to Wikipedia. If someone wants to go down that rabbit hole, godspeed to them. For my purposes (and I'm not sure how well they reflect the public's), all that I need to know is "Can I use it where I want to use it?" and "For how long can I use it until I need to add another 512 bits to the length?" Notwithstanding the discovery of a systemic security vulnerability, of course, > personal-cipher-preferences CAMELLIA256 AES256 TWOFISH CAMELLIA192 \ > AES192 CAMELLIA128 AES BLOWFISH CAST5 \ > 3DES > And, to me, that's largely a string of random characters. Again, would be great if the major differences were summarised in a comparison table or something. > But that's why the discussion of ciphers is kept at a very high level, giving basic background information and nothing more. > Agreed. One more time for the back of the room: offload to another source for people who want to go down that rabbit hole. For laymen like me, reassure us that the defaults are "the best," (or, at least, grossly sufficient) and add a summary table so people can quickly learn the differences between the alternatives. > This is also why the FAQ doesn't link to Wikipedia, which tends to be very newbie-unfriendly. > For my minimal competence, Wikipedia is fine. Yes, it gets into the mathematical weeds with alien notation as you quote, but their articles also begin with good summaries and histories that tell me what I need to know. But if there's a better layman's source, use that. I'm suggesting that you don't make work for yourself by repeating what's already been done. GPG documentation should explain how to use GPG, not number theory or electronic engineering. This is all fascinating, and I hope someone other than me found it useful, but we've gone a bit off topic. The documentation (particularly man pages) seems to have obvious errors and omissions. Any chance of fixing those? From rjh at sixdemonbag.org Sun Sep 14 04:04:57 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Sep 2025 22:04:57 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: > My point exactly. So why not streamline the documentation to > explaining the defaults and offloading everything else to somewhere > where keeners can go down the rabbit hole? There are a few answers there. All are accurate. (a) nobody asks what the defaults are, (b) at the time it was written GnuPG was in transition: the defaults were changing, and hence it was impossible to say what "the defaults" were without going into detail about GnuPG versions, (c) a refreshed FAQ probably would explain the defaults, since we're in a period of algorithmic stability. > Fair. Which is why I suggest consolidating it all into one question > that goes to the effect of "The 'best' cyphers are the ones we set > to the defaults." Because few people asked the best symmetric algorithm to use, but lots of people asked the best asymmetric algorithm to use. This is why the FAQ only talks about asymmetric algorithms. https://gnupg.org/faq/gnupg-faq.html#new_key_algo Again, a refreshed FAQ would probably address this differently. > I think the question people mean to ask - as it's one I often have - > is "What's the difference between them?" or "What's the best for > _my_ situation?" Although that is a FAQ, it's one I deliberately didn't answer because all the answers are unsatisfactory. They run between, "How should I know what your situation is?" to "for $300 an hour, I'll happily listen to your specific needs and give you a tailored recommendation, which will probably be 'just use the defaults, they're great for you'." A FAQ is not personalized for individual questioners, and it needs to avoid questions that require personal intervention. > If people are anything like me (and fortunately almost all of them > aren't), I think they come from believing that if one algorithm were > universally the best, everyone would use it. But since we have > different algorithms, there surely must be some reason why people > went through all that extra effort. There may be virtue in asking "why does GnuPG support so many algorithms?", but the answer is unsatisfactory: "because RFC4880bis has support for so many algorithms, go ask them why, we just implement the standard." One hard-and-fast rule I made with the FAQ is I don't explain the RFCs. GnuPG implements RFC4880bis; if RFC4880bis says X, GnuPG does X, if you want to know why X you need to ask the Working Group. I don't write code for any OpenPGP/LibrePGP implementation and I have zero involvement in the development of the RFCs. (Until early this year, I was an IT contractor for the United States government. Many people in the community think the United States government is untrustworthy and/or dedicated to sabotaging secure communications. I disagree with that position utterly, but I respect it: and thus, to minimize the amount of stress I bring to the community, I don't participate in either the Working Group or GnuPG development. I used to write a FAQ, that's it.) > Again, advising to offload discussion onto other sources, I think > the best response to that FAQ is to provide a layman's difference > between them. Something to the effect of "Algo X is faster than Y, > but Y produces more compact hashes than Z, but Z has higher > resistance to side attacks than X, etc." Absolutely not. Flat no. This is counterproductive. The differences between Camellia256 and Twofish, for instance, are... well, there are a lot of them, but for the layman the whole of our advice could be (should be!) "all the 256-bit ciphers are effectively identical for lay purposes, please only use the other ciphers for small messages of smaller than 8 MiB." But that doesn't satisfy the crypto Tom, Dick, and Harry crowd, who are absolutely certain that (a) there are significant differences and (b) they have the mathematical and engineering background necessary to judge which is best for them. (a) might be true. (b) rarely is, and I'm not going to try to educate people for free. > Wikipedia has comparison pages that, often in a tabular format, > summarise the differences in whatever - like database engines or > text editors. A table like that should shut most people up (if they > bother to read it). If Wikipedia, or somewhere else, has a page > comparing cyphers, so much the better. Link to it and save some > typing. No. "Unless you know what you're doing and why, use the defaults" is the best advice. Do you need to comply with older versions of the EMV standards? Use 3DES. Need to comply with Japanese government standards? Use Camellia256. Need a 128-bit-block cipher that works with PGP 7? Use Twofish. Need to interoperate with *really really old* GnuPG? Use Blowfish. Etc., etc. The other ciphers exist for special needs. There is no meaningful tradeoff matrix that could be written. Unless you know what you're doing and why, use the defaults. If you know what you're doing and why you need to change things, well, you have options. > Perfect answer. Plug it in the FAQ. To remind you, I am recovering from a major health crisis and I am not working on the FAQ very much right now. :) > Noted. Would also be a good column for that table: "One-way hash"; > "Asymmetric"; "Symmetric" Why? 'gpg --version' already does that. Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 > And, to me, that's largely a string of random characters. Again, > would be great if the major differences were summarised in a > comparison table or something. That's why unless you know what you're doing and why, you should use the defaults. :) > This is all fascinating, and I hope someone other than me found it > useful, but we've gone a bit off topic. The documentation > (particularly man pages) seems to have obvious errors and omissions. > Any chance of fixing those? I don't want to get too deep into the weeds with my health concerns, but here's the problem: I suffered internal bleeding which, coupled with my anemia, resulted in my practically bleeding to death internally. My blood's ability to carry oxygen was down to under 30% that of a healthy person, and stayed there for multiple days before my friends hauled me off to the emergency department and saved my life. Most people who suffer my level of internal bleeding die; I am grateful to have survived. Unfortunately, my entire body suffered from long-term oxygen deprivation. My body prioritized my heart and brain for blood delivery, which starved the rest of my body even more. My muscles, body-wide, wasted away to the point I was incapable of rolling over in bed, and just breathing left me utterly exhausted. I've spent months in physical therapy reacquiring the ability to move. I can now shuffle around my apartment for brief periods without a cane or other balance assists, but I'm still in intensive physical therapy. This is my way of explaining to you that when I say, "right now the FAQ is not a high priority for me," you understand that right now the FAQ is essentially zero priority for me. I will get around to it when I get around to it, and no sooner. :) -------------- 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 rjh at sixdemonbag.org Sun Sep 14 04:55:18 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 13 Sep 2025 22:55:18 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: <875xdmzxs7.fsf@gmail.com> References: <875xdmzxs7.fsf@gmail.com> Message-ID: <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> > Number 1 is a bad idea. Some services still support legacy ciphers for > backwards comparability. I disagree; I think #1 is essential. If I don't know what cipher suites the recipient supports, I have no way of knowing whether secure communications are even possible. Knowing what the recipient supports is essential -- as is keeping one's own set of supported ciphers to a known-strong set. The intersection of "what am I willing to use?" and "what does the recipient support?" results in a set of mutually agreeable ciphers, of which any one may be chosen. (This has an analogue in the algorithmic analysis and design community, where it's called the Stable Marriage Problem. GnuPG's algorithm for choosing which cipher to use is straight out of the weighted-preference SMP. https://en.wikipedia.org/wiki/Stable_matching_problem The stable marriage problem is a variant of the stable matching problem. And yes, I'm right about it being an instance of stable marriage, and that stable matching is the wrong way to think about it. And no, here is the wrong place to argue with me on it, because (a) you'll be wrong and (b) you'll be off-topic. Discussion about how GnuPG implements the SMP is quite okay, though!) > I think that is a bit technical for an FAQ. Quantum computing is still > an active field of research, and it will likely be quite some time > before current algorithms are broken. If ever. While in graduate school I did a fair bit of research into quantum computing. I'm in no way still current on the state of quantum engineering -- that's improved by leaps and bounds since I last looked at it -- but the limitations of quantum mathematics are a little more solid in their foundations. Breaking RSA by brute force requires what, 5n logical qubits for each bit of the modulus? Something like that. So breaking RSA-2048 with a quantum computer requires a minimum 10kqb ensemble. (*Minimum*. A logical qubit normally requires many more qubits for error correction. A 10n or 15n parameter is not unreasonable.) Our current ensembles are a minute fraction of that. Nobody knows how to scale it up. As of ... what, two years ago, I think ... Arqit Networks, a UK-based quantum cryptography firm, told me they expected RSA-2048 to be susceptible to Shor's algorithm within five years. I pointed out this would require doubling the current state-of-the-art in ensemble size every 78 days for five years straight. In the time since, I don't think the ensemble size has doubled more than once. RSA-2048 is under much greater risk from cloud computing and the general number field sieve than it is from quantum computing. (Friends don't let friends generate new RSA-2048 keys, incidentally. I'm not kidding about the cloud and GNFS risks.) For symmetric computing it's just as ridiculous. Grover's algorithm lets you search a database of N entries in root-N time. This means a 128-bit cipher with 2**128 possible keys can be brute-forced in 2**64 time. Assuming you've got the science fiction technology needed to implement Grover's, okay, 128-bit ciphers might be breakable. So what? This is why we use 256-bit ciphers like AES, Camellia, and Twofish. Yes, Grover's reduces the effective keyspace to 'merely' 2**128. That's still a completely impractical amount of computation: brute-forcing that would require (*require*: we can prove this using thermodynamics) you to liberate more heat than a nuclear bomb. This would have dire implications for your data center, so no, we're not particularly worried about quantum algorithms attacking modern 256-bit ciphers. > The worry about quantum computers is because of their theoretical > ability to efficiently perform integer factorization and solve the > discrete logarithm problem [4]. If anyone is wondering how they can tackle two different kinds of cryptographic problems simultaneously -- They're not really all that different. They're both instances of the hidden subgroup problem as applied to finite Abelian groups. You can convert one into the other in polynomial time. -------------- 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 borden_c at tutanota.com Sun Sep 14 05:22:18 2025 From: borden_c at tutanota.com (Borden) Date: Sun, 14 Sep 2025 05:22:18 +0200 (CEST) Subject: Multiple issues in GPG documentation In-Reply-To: <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> References: <875xdmzxs7.fsf@gmail.com> <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> Message-ID: I invite the project maintainers, whom I believe are Heike and Werner, if they want to talk about the documentation further. From rjh at sixdemonbag.org Mon Sep 15 05:20:34 2025 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sun, 14 Sep 2025 23:20:34 -0400 Subject: Multiple issues in GPG documentation In-Reply-To: <5411d8a7-9f73-4151-a508-9ea484a8904d@gmail.com> References: <875xdmzxs7.fsf@gmail.com> <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> <5411d8a7-9f73-4151-a508-9ea484a8904d@gmail.com> Message-ID: <3a20d393-6dcd-4ce7-9127-b57cd92ddf75@sixdemonbag.org> > I never looked that far into GNFS.? Is it sufficiently amenable to > parallelization to run on a GPU cluster? Theoretically, but I don't think it's been done yet in the public cryptanalysis world. The last time I talked with a serious cryptographer about it he described it as suitable for an exceptionally ambitious Ph.D thesis -- from which I conclude that it's possible but extremely daunting. -------------- 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 jcb62281 at gmail.com Mon Sep 15 04:57:16 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 14 Sep 2025 21:57:16 -0500 Subject: Multiple issues in GPG documentation In-Reply-To: <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> References: <875xdmzxs7.fsf@gmail.com> <1de338ed-55b2-429d-9afe-591a91d2ce02@sixdemonbag.org> Message-ID: <5411d8a7-9f73-4151-a508-9ea484a8904d@gmail.com> On 9/13/25 21:55, Robert J. Hansen via Gnupg-users wrote: > [...] > > RSA-2048 is under much greater risk from cloud computing and the > general number field sieve than it is from quantum computing. > > (Friends don't let friends generate new RSA-2048 keys, incidentally. > I'm not kidding about the cloud and GNFS risks.) I never looked that far into GNFS.? Is it sufficiently amenable to parallelization to run on a GPU cluster? -- Jacob From jb-gnumlists at wisemo.com Tue Sep 16 10:52:20 2025 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Tue, 16 Sep 2025 10:52:20 +0200 Subject: Multiple issues in GPG documentation In-Reply-To: References: Message-ID: <2071db29-7880-ca12-cbbf-8c3ac1642d15@wisemo.com> On 9/14/2025 1:25 AM, Borden via Gnupg-users wrote: >> The FAQ *does* recommend a couple of good ciphers. There is a recurriing line in the FAQ, words to the effect of "unless you know what you're doing and why, just use the defaults." >> > My point exactly. So why not streamline the documentation to explaining the defaults and offloading everything else to somewhere where keeners can go down the rabbit hole? > >> I can't answer that -- "best" is inherently subjective -- but I can give brief breakdowns on the different ciphers. And I was asked to do this often >> enough that I just threw it in the FAQ. >> > Fair. Which is why I suggest consolidating it all into one question that goes to the effect of "The 'best' cyphers are the ones we set to the defaults." > > I think the question people mean to ask - as it's one I often have - is "What's the difference between them?" or "What's the best for _my_ situation?" > > If people are anything like me (and fortunately almost all of them aren't), I think they come from believing that if one algorithm were universally the best, everyone would use it. But since we have different algorithms, there surely must be some reason why people went through all that extra effort. > > Again, advising to offload discussion onto other sources, I think the best response to that FAQ is to provide a layman's difference between them. Something to the effect of "Algo X is faster than Y, but Y produces more compact hashes than Z, but Z has higher resistance to side attacks than X, etc." > > Wikipedia has comparison pages that, often in a tabular format, summarise the differences in whatever - like database engines or text editors. A table like that should shut most people up (if they bother to read it). If Wikipedia, or somewhere else, has a page comparing cyphers, so much the better. Link to it and save some typing. 20+ years ago, the cryptographic community had some very reliable pages for each algorithm category called "lounges", each maintained by an expert in the field.? Pages like "the hash function lounge" by P. Barreto (Now gone, used to be at http://www.larc.usp.br/~pbarreto/hflounge.html ) Back then, the world was in a phase of algorithm transitions due to the introduction of 128 bit block ciphers by the AES competition. ? Nowadays, the biggest transition is the need to think about quantum attacks on stored files, such as intercepted GPG-encrypted mails. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From wk at gnupg.org Tue Sep 16 11:04:05 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 16 Sep 2025 11:04:05 +0200 Subject: Silent failure when keyboxd is not running, no error or warning In-Reply-To: <6ad3fd88-49e9-4f0a-8408-5ac2dff78cb4@zoo.dev> (Lee via Gnupg-users's message of "Fri, 5 Sep 2025 09:29:38 -0400") References: <6ad3fd88-49e9-4f0a-8408-5ac2dff78cb4@zoo.dev> Message-ID: <87frcm93ay.fsf@jacob.g10code.de> Hello! > gpg: DBG: chan_4 <- ERR 134217755 Not found This is debug output and no error. Itmmereley means, well, not found. > Behold, there was a `use-keyboxd` there. Deleting this line, I could > use my keys again. Pleasde let me quote a section from the README: Key database daemon Since version 2.3.0 it is possible to store the keys in an SQLite database instead of the keyring.kbx file. This is in particular useful for large keyrings or if many instances of gpg and gpgsm may run concurrently. This is implemented using another daemon process, the "keyboxd". To enable the use of the keyboxd put the option "use-keyboxd" into the configuration file ~/.gnupg/common.conf or the global /etc/gnupg/common.conf. See also doc/examples/common.conf. Only public keys and X.509 certificates are managed by the keyboxd; private keys are still stored as separate files. Since version 2.4.1 the keyboxd will be used by default for a fresh install; i.e. if a ~/.gnupg directory did not yet exist. Note the two lines above and the next paragraph: Note that there is no automatic migration; if the use-keyboxd option is enabled keys are not taken from pubring.kbx. To migrate existing keys to the keyboxd do this: 1. Disable the keyboxd (remove use-keyboxd from common.conf) 2. Export all public keys gpg --export --export-options backup > allkeys.gpg gpgsm --export --armor > allcerts.gpg 3. Enable the keyboxd (add use-keyboxd to common.conf) 4. Import all public keys gpg --import --import-options restore < allkeys.gpg gpgsm --import < allcerts.crt In case the keyboxd is not able to startup due to a stale lockfile created by another host, the command gpgconf --unlock pubring.db can be used to remove the lock file. Thus depending how you installed, updated or reverted a version of GnuPG you may end up with public keys either being in the keyboxd or in the usual pubring.kbx file. The private keys are always stored as separate files below the private-keys-v1.d directory. The way the list--secret-keys command works is that it walks over all public keys (pubring.kbx or keyboxd) and then print opnly those for which a matching private key is available. > It would have been really nice for gpg to report the internal error I > pasted above, as "Unable to communicate with keyboxd", instead of a > silent failure causing me to have a minor heart palpitation :) A too high debug level may have been the cause ;-). 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 oddeveneven at gmail.com Mon Sep 29 09:01:22 2025 From: oddeveneven at gmail.com (Evan Aad) Date: Mon, 29 Sep 2025 10:01:22 +0300 Subject: GPG is waiting for a lock held by a process that does not exist Message-ID: Hello, Working on a PC running Windows 11 Pro, I'm trying to verify a the signature of a file by running the following command in a GitBash console: gpg --verify THE_NAME_OF_THE_SIGNATURE_FILE In response, the following message appears: gpg: Note: database_open 134217901 waiting for lock (held by 1819) ... However, when I then run: ps The table that is shown contains no row whose PID value is 1819. Restarting the computer does not help. Google suggests that deleting C:\Users\\AppData\Roaming\gnupg\pubring.db.lock might clear the error, however I don't have a gnupg directory under directory \Users\\AppData\Roaming. I do have a .gnupg directory under C:\Users\, but there is no file whose name include the string lock in this directory. How can I resolve this problem? From andrewg at andrewg.com Mon Sep 29 10:11:39 2025 From: andrewg at andrewg.com (Andrew Gallagher) Date: Mon, 29 Sep 2025 09:11:39 +0100 Subject: GPG is waiting for a lock held by a process that does not exist In-Reply-To: References: Message-ID: On 29 Sep 2025, at 08:59, Evan Aad via Gnupg-users wrote: > > However, when I then run: > > ps > > The table that is shown contains no row whose PID value is 1819. Try `ps ax` instead? By default `ps` doesn?t show all processes. A From oddeveneven at gmail.com Mon Sep 29 10:46:41 2025 From: oddeveneven at gmail.com (Evan Aad) Date: Mon, 29 Sep 2025 11:46:41 +0300 Subject: GPG is waiting for a lock held by a process that does not exist In-Reply-To: References: Message-ID: `ps ax` does't show said PID either. On Mon, Sep 29, 2025 at 11:11?AM Andrew Gallagher wrote: > > On 29 Sep 2025, at 08:59, Evan Aad via Gnupg-users wrote: > > > > However, when I then run: > > > > ps > > > > The table that is shown contains no row whose PID value is 1819. > > Try `ps ax` instead? By default `ps` doesn?t show all processes. > > A From kloecker at kde.org Mon Sep 29 16:24:22 2025 From: kloecker at kde.org (Ingo =?UTF-8?B?S2zDtmNrZXI=?=) Date: Mon, 29 Sep 2025 16:24:22 +0200 Subject: Compiling error with pinentry In-Reply-To: <8734dglbda.fsf@lispclub.com> References: <8734dglbda.fsf@lispclub.com> Message-ID: <2319888.vFx2qVVIhK@daneel> A late update for this thread. On Mittwoch, 7. Mai 2025 16:54:41 Mitteleurop?ische Sommerzeit Daniel Cerqueira wrote: > I am having trouble compiling pinentry. I always compile all the GnuPG > suite, so I don't install any GnuPG program by my package manager (which > is pacman). > > My operating system is Parabola. > > Can someone tell me if they can reproduce this compiling error issue > below, and ways for me to solve this? > > Here is the compile error that I get: > > ``` > $ ./autogen.sh > autogen.sh: Running aclocal -I m4 ... > autogen.sh: Running autoheader... > autogen.sh: Running automake --gnu ... > autogen.sh: Running autoconf ... > configure.ac:341: warning: AC_LIB_PREPARE_PREFIX is m4_require'd but not > m4_defun'd m4/iconv.m4:10: AM_ICONV_LINKFLAGS_BODY is expanded from... > m4/iconv.m4:21: AM_ICONV_LINK is expanded from... > m4/iconv.m4:246: AM_ICONV is expanded from... After updating to gettext 0.26 (on openSUSE Tumbleweed) I got the same errors. It seems that since version 0.25 most of gettext's m4 files are no longer installed in /usr/share/aclocal and that one needs to add the required files to the project. This has now been done for pinentry. Regards, Ingo -------------- 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: