From anton.txt at gmail.com Wed Sep 9 02:16:31 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 03:16:31 +0300 Subject: GnuPG incompatible with the 80x25 terminal? Message-ID: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> Hello, all. I was surprised to learn that GnuPG is not fully compatible with the standard ISO screen of 80 columns and 25 rows. When I issue the `help' command in the --edit-key interface, GnuPG prints a list of 45 commands on 45 lines in one fell swoop[1]. Such long output cannot be read on a standard 25-row screen without some sort of scrollback functionality, be it from the SSH client, the terminal multiplexer, or the terminal emulator. Whereas the requirement for scrollback is way beyond basic accessiblity requirements, may I request to please add pagination to all output from --edit-key interactive sessions? ____________________ 1. I observed it by running GnuPG inside a GNU Screen session. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From anton.txt at gmail.com Wed Sep 9 02:29:56 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 03:29:56 +0300 Subject: GnuPG incompatible with the 80x25 terminal? Message-ID: <20260909032956.25899875d24fa5fdac28f53c@gmail.com> [sending message by e-mail after Gmane did not delive it] Hello, all. I was surprised to learn that GnuPG is not fully compatible with the standard ISO screen of 80 columns and 25 rows. When I issue the `help' command in the --edit-key interface, GnuPG prints a list of 45 commands on 45 lines in one fell swoop[1]. Such long output cannot be read on a standard 25-row screen without some sort of scrollback functionality, be it from the SSH client, the terminal multiplexer, or the terminal emulator. Whereas the requirement for scrollback is way beyond basic accessiblity requirements, may I request to please add pagination to all output from --edit-key interactive sessions? ____________________ 1. I observed it by running GnuPG inside a GNU Screen session. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From anton.txt at gmail.com Wed Sep 9 03:47:36 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 04:47:36 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909032956.25899875d24fa5fdac28f53c@gmail.com> Message-ID: <20260909044736.853ecd74d379d9eb347249e0@gmail.com> I wrote > [sending message by e-mail after Gmane did not delive it] Gmane has made it after all. Teaches one patience. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From mm at dorfdsl.de Wed Sep 9 08:25:13 2026 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 9 Sep 2026 08:25:13 +0200 Subject: handling bogus output of encrypted messages Message-ID: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Hello! I would like to ask how people handle potentially bogus output when encrypting messages on the terminal. They can contain control characters that change the terminal's behavior. What can be done to be protected against them? -- Gruß Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 9 10:41:40 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2026 10:41:40 +0200 Subject: GnuPG incompatible with the 80x25 terminal? In-Reply-To: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> (Anton Shepelev via Gnupg-users's message of "Wed, 9 Sep 2026 03:16:31 +0300") References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> Message-ID: <87se3iyfy3.fsf@jacob.g10code.de> On Wed, 9 Sep 2026 03:16, Anton Shepelev said: > beyond basic accessiblity requirements, may I request to > please add pagination to all output from --edit-key > interactive sessions? I can understand your request but it is not likley that this will be implemnted soon. But who knows. Feature request is https://dev.gnupg.org/T8445 (in case you can access our server) 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 wk at gnupg.org Wed Sep 9 10:44:11 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2026 10:44:11 +0200 Subject: handling bogus output of encrypted messages In-Reply-To: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> (Marco Moock via Gnupg-users's message of "Wed, 9 Sep 2026 08:25:13 +0200") References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Message-ID: <87o6e6yftw.fsf@jacob.g10code.de> On Wed, 9 Sep 2026 08:25, Marco Moock said: > Hello! > > I would like to ask how people handle potentially bogus output when > encrypting messages on the terminal. Never do this. Neither with gpg nor with any other tool which copies tainted input data to stdout. At least use cat -v (or -e) or use less. 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 anton.txt at gmail.com Wed Sep 9 13:14:05 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 14:14:05 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> Message-ID: <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> Werner Koch to Anton Shepelev: > > may I request to please add pagination to all output > > from --edit-key interactive sessions? > > I can understand your request but it is not likley that > this will be implemnted soon. But who knows. Feature > request is > > https://dev.gnupg.org/T8445 > > (in case you can access our server) Thank you, Werner. Yes, I can access the gnupg bug tracker server. There, you remark that > Of course this needs to be an option because for sure > there are scripts using canned command sequences (which > they actually should not do). I those commands are executed by invoking gpg with `--command-fd', then that option or `--batch' could be used to suppress pagination, assuming an interactive session by default. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From rjh at sixdemonbag.org Wed Sep 9 14:08:48 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Sep 2026 08:08:48 -0400 Subject: handling bogus output of encrypted messages In-Reply-To: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Message-ID: > I would like to ask how people handle potentially bogus output when > encrypting messages on the terminal. Don't do that. Seriously, it's a three-word solution. Don't do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From kopeter01 at proton.me Wed Sep 9 22:22:42 2026 From: kopeter01 at proton.me (=?utf-8?Q?Kov=C3=A1cs_T=2E_P=C3=A9ter?=) Date: Wed, 09 Sep 2026 20:22:42 +0000 Subject: GPG stores the password after encription? Message-ID: Hi, I am using GnuPG 2.4.7 under Linux. I encrypted a file with "gpg -c". I used a long password. Some minutes later, I tried to decrypt this encrypted file with "gpg -v". Decryption happened without asking a password. I think is GPG-agent stored the password (?) If this happened, how long it stores the password? Password stored in encrypted form? How can I disable to store the password?Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Sep 9 23:41:55 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Sep 2026 17:41:55 -0400 Subject: GPG stores the password after encription? In-Reply-To: References: Message-ID: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> Please only send plain text to the list. > I am using GnuPG 2.4.7 under Linux. Please upgrade. :( 2.4.7 is about two years old now. > I think is GPG-agent stored the password (?) If this happened, how long > it stores the password? Password stored in encrypted form? How can I > disable to store the password? The duration is user-configurable and is found in ~/.ssh/gpg-agent.conf. Note: if you're using GNOME or some other graphical desktop, it may have its own credential manager that's doing this. GnuPG has no control over that. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From collin.funk1 at gmail.com Thu Sep 10 00:08:51 2026 From: collin.funk1 at gmail.com (Collin Funk) Date: Wed, 09 Sep 2026 15:08:51 -0700 Subject: GPG stores the password after encription? In-Reply-To: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> References: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> Message-ID: "Robert J. Hansen via Gnupg-users" writes: > Please only send plain text to the list. > >> I am using GnuPG 2.4.7 under Linux. > > Please upgrade. :( 2.4.7 is about two years old now. They are probably using a gnupg version that receives patches from the distributor. Whether or not the distributor catches every relevant fix is another question. :) Collin From borden_c at tutanota.com Thu Sep 10 03:09:26 2026 From: borden_c at tutanota.com (Borden) Date: Thu, 10 Sep 2026 03:09:26 +0200 (CEST) Subject: GPG stores the password after encription? In-Reply-To: References: Message-ID: In case the life advice was unhelpful, I'll try to finish Hansen's comment: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html says the --pinentry-timeout default is indefinite, but whatever front-end handles pinentries on your system may set a different limit. You can change the limit in ~/.gnupg/gpg-agent.conf, or %appdata%\gnupg\gpg-agent.conf on Windows. Before the timeout, I can only guess that gpg holds at least some of your decrypted keyring in RAM. How resilient that is against a RAM sniffer I can't say, but would probably depend on your OS. I've only ever seen it store a file lock placeholders on the hard disk during en/decryption. So you probably don't have to worry about someone recovering an encrypted keyring after you shut off the computer. I'm sure at least some of what I said is wrong as I'm working from the documentation and not the source. From jb-gnumlists at wisemo.com Thu Sep 10 07:20:47 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Thu, 10 Sep 2026 07:20:47 +0200 Subject: GnuPG incompatible with the 80x25 terminal? In-Reply-To: <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> Message-ID: <03cd1ac7-06f1-f508-fc2b-680803589ac6@wisemo.com> On 09/09/2026 13:14, Anton Shepelev via Gnupg-users wrote: > Werner Koch to Anton Shepelev: > >>> may I request to please add pagination to all output >>> from --edit-key interactive sessions? >> I can understand your request but it is not likley that >> this will be implemnted soon. But who knows. Feature >> request is >> >> https://dev.gnupg.org/T8445 >> >> (in case you can access our server) > Thank you, Werner. Yes, I can access the gnupg bug tracker > server. There, you remark that > >> Of course this needs to be an option because for sure >> there are scripts using canned command sequences (which >> they actually should not do). > I those commands are executed by invoking gpg with > `--command-fd', then that option or `--batch' could be used > to suppress pagination, assuming an interactive session by > default. Another condition for dealing with this portably is to check isatty(stdout_fd) . If stdout is a tty and there is a way to read back pager responses, pager logic can be used by default (subject to options like --batch). Another solution is to reformat and rephrase the help screen to fit in 24 lines (25 lines minus 1 used for the next prompt). This may involve creative use of columns and word choices. 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 Thu Sep 10 09:59:33 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Sep 2026 09:59:33 +0200 Subject: GPG stores the password after encription? In-Reply-To: (Borden via Gnupg-users's message of "Thu, 10 Sep 2026 03:09:26 +0200 (CEST)") References: Message-ID: <87jyoty1sq.fsf@jacob.g10code.de> On Thu, 10 Sep 2026 03:09, Borden said: > Before the timeout, I can only guess that gpg holds at least some of > your decrypted keyring in RAM. How resilient that is against a RAM No. gpg-agent has a cache for passphrases which are for example used to unprotect a key. It does not hold any other sensitive data in RAM longer than needed for processing. The memory allocator even wipes the memory right before the free() and at some places we even do an extra wipememory. The passphrases in the cache are actually stored encrypted in the RAM but obviously the symmetric key for tha is still hold in the clear in the RAM .-) 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 jcb62281 at gmail.com Fri Sep 11 06:32:02 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 10 Sep 2026 23:32:02 -0500 Subject: GPG stores the password after encription? In-Reply-To: <87jyoty1sq.fsf@jacob.g10code.de> References: <87jyoty1sq.fsf@jacob.g10code.de> Message-ID: On 9/10/26 02:59, Werner Koch via Gnupg-users wrote: > [...] > > The passphrases in the cache are actually stored encrypted in the RAM > but obviously the symmetric key for tha is still hold in the clear in > the RAM .-) Suggestion/feature request:  store /N/ shadows that must be XORed together to recover the symmetric key.  Periodically "shuffle" the shadows by XORing the same random value into all of them.  (/N/ must be even; 2 is the simplest case.)  Initially generate the key by simply randomly generating the shadows. This addresses the tail risk of memory cells "taking a set" which I understand can happen if the same data is stored for a very long time.  The effect is that the state of those cells upon powerup is biased towards (or away---I forget which...) from the pattern that was stored in them. As far as I know, the attack is theoretical, but it could be addressed for extra paranoia points.  :-) -- Jacob From wk at gnupg.org Fri Sep 11 11:28:11 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Sep 2026 11:28:11 +0200 Subject: GPG stores the password after encription? In-Reply-To: (Jacob Bachmeyer via Gnupg-users's message of "Thu, 10 Sep 2026 23:32:02 -0500") References: <87jyoty1sq.fsf@jacob.g10code.de> Message-ID: <87qzj0w310.fsf@jacob.g10code.de> On Thu, 10 Sep 2026 23:32, Jacob Bachmeyer said: > As far as I know, the attack is theoretical, but it could be addressed > for extra paranoia points.  :-) https://www.xkcd.com/538/ The reason why we have this in-RAM encryption is that it may eventually allow us to store the key on some special device (SecureEnclave, TPM, whatever). 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 anton.txt at gmail.com Fri Sep 11 14:49:09 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Fri, 11 Sep 2026 15:49:09 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> <03cd1ac7-06f1-f508-fc2b-680803589ac6@wisemo.com> Message-ID: <20260911154909.1658bb07487eece0f5cb050b@gmail.com> Jakob Bohm: > Another solution is to reformat and rephrase the help > screen to fit in 24 lines (25 lines minus 1 used for the > next prompt). This may involve creative use of columns > and word choices. I don't think it is a good solution of GnuPG, because it is hard to maintain, is not scalable, and is not always actually possible, e.g as the number of commands grows. With potentially long key listsings, it is already the case, cf. the undocumeted `list' command. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From anton.txt at gmail.com Wed Sep 9 02:16:31 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 03:16:31 +0300 Subject: GnuPG incompatible with the 80x25 terminal? Message-ID: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> Hello, all. I was surprised to learn that GnuPG is not fully compatible with the standard ISO screen of 80 columns and 25 rows. When I issue the `help' command in the --edit-key interface, GnuPG prints a list of 45 commands on 45 lines in one fell swoop[1]. Such long output cannot be read on a standard 25-row screen without some sort of scrollback functionality, be it from the SSH client, the terminal multiplexer, or the terminal emulator. Whereas the requirement for scrollback is way beyond basic accessiblity requirements, may I request to please add pagination to all output from --edit-key interactive sessions? ____________________ 1. I observed it by running GnuPG inside a GNU Screen session. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From anton.txt at gmail.com Wed Sep 9 02:29:56 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 03:29:56 +0300 Subject: GnuPG incompatible with the 80x25 terminal? Message-ID: <20260909032956.25899875d24fa5fdac28f53c@gmail.com> [sending message by e-mail after Gmane did not delive it] Hello, all. I was surprised to learn that GnuPG is not fully compatible with the standard ISO screen of 80 columns and 25 rows. When I issue the `help' command in the --edit-key interface, GnuPG prints a list of 45 commands on 45 lines in one fell swoop[1]. Such long output cannot be read on a standard 25-row screen without some sort of scrollback functionality, be it from the SSH client, the terminal multiplexer, or the terminal emulator. Whereas the requirement for scrollback is way beyond basic accessiblity requirements, may I request to please add pagination to all output from --edit-key interactive sessions? ____________________ 1. I observed it by running GnuPG inside a GNU Screen session. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From anton.txt at gmail.com Wed Sep 9 03:47:36 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 04:47:36 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909032956.25899875d24fa5fdac28f53c@gmail.com> Message-ID: <20260909044736.853ecd74d379d9eb347249e0@gmail.com> I wrote > [sending message by e-mail after Gmane did not delive it] Gmane has made it after all. Teaches one patience. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From mm at dorfdsl.de Wed Sep 9 08:25:13 2026 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 9 Sep 2026 08:25:13 +0200 Subject: handling bogus output of encrypted messages Message-ID: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Hello! I would like to ask how people handle potentially bogus output when encrypting messages on the terminal. They can contain control characters that change the terminal's behavior. What can be done to be protected against them? -- Gruß Marco Junk-Mail bitte an trashcan at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Wed Sep 9 10:41:40 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2026 10:41:40 +0200 Subject: GnuPG incompatible with the 80x25 terminal? In-Reply-To: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> (Anton Shepelev via Gnupg-users's message of "Wed, 9 Sep 2026 03:16:31 +0300") References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> Message-ID: <87se3iyfy3.fsf@jacob.g10code.de> On Wed, 9 Sep 2026 03:16, Anton Shepelev said: > beyond basic accessiblity requirements, may I request to > please add pagination to all output from --edit-key > interactive sessions? I can understand your request but it is not likley that this will be implemnted soon. But who knows. Feature request is https://dev.gnupg.org/T8445 (in case you can access our server) 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 wk at gnupg.org Wed Sep 9 10:44:11 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 09 Sep 2026 10:44:11 +0200 Subject: handling bogus output of encrypted messages In-Reply-To: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> (Marco Moock via Gnupg-users's message of "Wed, 9 Sep 2026 08:25:13 +0200") References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Message-ID: <87o6e6yftw.fsf@jacob.g10code.de> On Wed, 9 Sep 2026 08:25, Marco Moock said: > Hello! > > I would like to ask how people handle potentially bogus output when > encrypting messages on the terminal. Never do this. Neither with gpg nor with any other tool which copies tainted input data to stdout. At least use cat -v (or -e) or use less. 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 anton.txt at gmail.com Wed Sep 9 13:14:05 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 9 Sep 2026 14:14:05 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> Message-ID: <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> Werner Koch to Anton Shepelev: > > may I request to please add pagination to all output > > from --edit-key interactive sessions? > > I can understand your request but it is not likley that > this will be implemnted soon. But who knows. Feature > request is > > https://dev.gnupg.org/T8445 > > (in case you can access our server) Thank you, Werner. Yes, I can access the gnupg bug tracker server. There, you remark that > Of course this needs to be an option because for sure > there are scripts using canned command sequences (which > they actually should not do). I those commands are executed by invoking gpg with `--command-fd', then that option or `--batch' could be used to suppress pagination, assuming an interactive session by default. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From rjh at sixdemonbag.org Wed Sep 9 14:08:48 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Sep 2026 08:08:48 -0400 Subject: handling bogus output of encrypted messages In-Reply-To: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> Message-ID: > I would like to ask how people handle potentially bogus output when > encrypting messages on the terminal. Don't do that. Seriously, it's a three-word solution. Don't do that. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From kopeter01 at proton.me Wed Sep 9 22:22:42 2026 From: kopeter01 at proton.me (=?utf-8?Q?Kov=C3=A1cs_T=2E_P=C3=A9ter?=) Date: Wed, 09 Sep 2026 20:22:42 +0000 Subject: GPG stores the password after encription? Message-ID: Hi, I am using GnuPG 2.4.7 under Linux. I encrypted a file with "gpg -c". I used a long password. Some minutes later, I tried to decrypt this encrypted file with "gpg -v". Decryption happened without asking a password. I think is GPG-agent stored the password (?) If this happened, how long it stores the password? Password stored in encrypted form? How can I disable to store the password?Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjh at sixdemonbag.org Wed Sep 9 23:41:55 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Wed, 9 Sep 2026 17:41:55 -0400 Subject: GPG stores the password after encription? In-Reply-To: References: Message-ID: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> Please only send plain text to the list. > I am using GnuPG 2.4.7 under Linux. Please upgrade. :( 2.4.7 is about two years old now. > I think is GPG-agent stored the password (?) If this happened, how long > it stores the password? Password stored in encrypted form? How can I > disable to store the password? The duration is user-configurable and is found in ~/.ssh/gpg-agent.conf. Note: if you're using GNOME or some other graphical desktop, it may have its own credential manager that's doing this. GnuPG has no control over that. -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From collin.funk1 at gmail.com Thu Sep 10 00:08:51 2026 From: collin.funk1 at gmail.com (Collin Funk) Date: Wed, 09 Sep 2026 15:08:51 -0700 Subject: GPG stores the password after encription? In-Reply-To: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> References: <270fb9fb-4daa-4ea4-bce3-a2c63f336227@sixdemonbag.org> Message-ID: "Robert J. Hansen via Gnupg-users" writes: > Please only send plain text to the list. > >> I am using GnuPG 2.4.7 under Linux. > > Please upgrade. :( 2.4.7 is about two years old now. They are probably using a gnupg version that receives patches from the distributor. Whether or not the distributor catches every relevant fix is another question. :) Collin From borden_c at tutanota.com Thu Sep 10 03:09:26 2026 From: borden_c at tutanota.com (Borden) Date: Thu, 10 Sep 2026 03:09:26 +0200 (CEST) Subject: GPG stores the password after encription? In-Reply-To: References: Message-ID: In case the life advice was unhelpful, I'll try to finish Hansen's comment: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html says the --pinentry-timeout default is indefinite, but whatever front-end handles pinentries on your system may set a different limit. You can change the limit in ~/.gnupg/gpg-agent.conf, or %appdata%\gnupg\gpg-agent.conf on Windows. Before the timeout, I can only guess that gpg holds at least some of your decrypted keyring in RAM. How resilient that is against a RAM sniffer I can't say, but would probably depend on your OS. I've only ever seen it store a file lock placeholders on the hard disk during en/decryption. So you probably don't have to worry about someone recovering an encrypted keyring after you shut off the computer. I'm sure at least some of what I said is wrong as I'm working from the documentation and not the source. From jb-gnumlists at wisemo.com Thu Sep 10 07:20:47 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Thu, 10 Sep 2026 07:20:47 +0200 Subject: GnuPG incompatible with the 80x25 terminal? In-Reply-To: <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> Message-ID: <03cd1ac7-06f1-f508-fc2b-680803589ac6@wisemo.com> On 09/09/2026 13:14, Anton Shepelev via Gnupg-users wrote: > Werner Koch to Anton Shepelev: > >>> may I request to please add pagination to all output >>> from --edit-key interactive sessions? >> I can understand your request but it is not likley that >> this will be implemnted soon. But who knows. Feature >> request is >> >> https://dev.gnupg.org/T8445 >> >> (in case you can access our server) > Thank you, Werner. Yes, I can access the gnupg bug tracker > server. There, you remark that > >> Of course this needs to be an option because for sure >> there are scripts using canned command sequences (which >> they actually should not do). > I those commands are executed by invoking gpg with > `--command-fd', then that option or `--batch' could be used > to suppress pagination, assuming an interactive session by > default. Another condition for dealing with this portably is to check isatty(stdout_fd) . If stdout is a tty and there is a way to read back pager responses, pager logic can be used by default (subject to options like --batch). Another solution is to reformat and rephrase the help screen to fit in 24 lines (25 lines minus 1 used for the next prompt). This may involve creative use of columns and word choices. 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 Thu Sep 10 09:59:33 2026 From: wk at gnupg.org (Werner Koch) Date: Thu, 10 Sep 2026 09:59:33 +0200 Subject: GPG stores the password after encription? In-Reply-To: (Borden via Gnupg-users's message of "Thu, 10 Sep 2026 03:09:26 +0200 (CEST)") References: Message-ID: <87jyoty1sq.fsf@jacob.g10code.de> On Thu, 10 Sep 2026 03:09, Borden said: > Before the timeout, I can only guess that gpg holds at least some of > your decrypted keyring in RAM. How resilient that is against a RAM No. gpg-agent has a cache for passphrases which are for example used to unprotect a key. It does not hold any other sensitive data in RAM longer than needed for processing. The memory allocator even wipes the memory right before the free() and at some places we even do an extra wipememory. The passphrases in the cache are actually stored encrypted in the RAM but obviously the symmetric key for tha is still hold in the clear in the RAM .-) 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 jcb62281 at gmail.com Fri Sep 11 06:32:02 2026 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 10 Sep 2026 23:32:02 -0500 Subject: GPG stores the password after encription? In-Reply-To: <87jyoty1sq.fsf@jacob.g10code.de> References: <87jyoty1sq.fsf@jacob.g10code.de> Message-ID: On 9/10/26 02:59, Werner Koch via Gnupg-users wrote: > [...] > > The passphrases in the cache are actually stored encrypted in the RAM > but obviously the symmetric key for tha is still hold in the clear in > the RAM .-) Suggestion/feature request:  store /N/ shadows that must be XORed together to recover the symmetric key.  Periodically "shuffle" the shadows by XORing the same random value into all of them.  (/N/ must be even; 2 is the simplest case.)  Initially generate the key by simply randomly generating the shadows. This addresses the tail risk of memory cells "taking a set" which I understand can happen if the same data is stored for a very long time.  The effect is that the state of those cells upon powerup is biased towards (or away---I forget which...) from the pattern that was stored in them. As far as I know, the attack is theoretical, but it could be addressed for extra paranoia points.  :-) -- Jacob From wk at gnupg.org Fri Sep 11 11:28:11 2026 From: wk at gnupg.org (Werner Koch) Date: Fri, 11 Sep 2026 11:28:11 +0200 Subject: GPG stores the password after encription? In-Reply-To: (Jacob Bachmeyer via Gnupg-users's message of "Thu, 10 Sep 2026 23:32:02 -0500") References: <87jyoty1sq.fsf@jacob.g10code.de> Message-ID: <87qzj0w310.fsf@jacob.g10code.de> On Thu, 10 Sep 2026 23:32, Jacob Bachmeyer said: > As far as I know, the attack is theoretical, but it could be addressed > for extra paranoia points.  :-) https://www.xkcd.com/538/ The reason why we have this in-RAM encryption is that it may eventually allow us to store the key on some special device (SecureEnclave, TPM, whatever). 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 anton.txt at gmail.com Fri Sep 11 14:49:09 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Fri, 11 Sep 2026 15:49:09 +0300 Subject: GnuPG incompatible with the 80x25 terminal? References: <20260909031631.4bee0c3ba75a5068f1b53393@gmail.com> <87se3iyfy3.fsf@jacob.g10code.de> <20260909141405.555f79f215f1ad3c8dd6ec40@gmail.com> <03cd1ac7-06f1-f508-fc2b-680803589ac6@wisemo.com> Message-ID: <20260911154909.1658bb07487eece0f5cb050b@gmail.com> Jakob Bohm: > Another solution is to reformat and rephrase the help > screen to fit in 24 lines (25 lines minus 1 used for the > next prompt). This may involve creative use of columns > and word choices. I don't think it is a good solution of GnuPG, because it is hard to maintain, is not scalable, and is not always actually possible, e.g as the number of commands grows. With potentially long key listsings, it is already the case, cf. the undocumeted `list' command. -- () ascii ribbon campaign -- against html e-mail /\ www.asciiribbon.org -- against proprietary attachments From arawson at proton.me Tue Sep 15 01:44:22 2026 From: arawson at proton.me (Andrew) Date: Mon, 14 Sep 2026 23:44:22 +0000 Subject: Issues with libgcrypt 1.12.4-1 with pre-existing keys Message-ID: <6e1bf868-2bc0-4bf9-9046-11862f6d6df3@proton.me> Hello, I created some gpg keys not too long ago to use for signing/auth on github. I presume the keys were created under libgcrypt 1.12.3-1 because it wasn't very far back that I did it. However, when I upgraded to libgcrypt 1.12.4-1, my gpg keys were corrupted. I had to downgrade the package back to 1.12.3-1 and re-import the keys from backup. I am currently holding the package from updating until I know what to do. I am using Arch Linux with KDE Plasma, and using keyboxd. I don't know if keyboxd is a factor or not. But that's all I can think of. Is it possible to re-import the keys after upgrading to 1.12.4-1 and regenerating the gnupg directory? Or do I need to wait for 1.12.5-1? I suppose if I had to I could generate new keys and update my Github. But if there is an alternative I'd be open to it. Thank you, -- Andrew "Dru" Rawson Certified Secure Infrastructure Specialist (207)-344-4867 dru at drudoestech.com drudoestech.com [CompTIA Certification Badge](https://www.credly.com/badges/63268fb4-b8c6-40fd-82f9-c68515ed2001/public_url) [OpenPGP key](https://drudoestech.com/resources/arawson at proton.me-public.asc) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm at dorfdsl.de Wed Sep 16 14:41:57 2026 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 16 Sep 2026 14:41:57 +0200 Subject: handling bogus output of encrypted messages In-Reply-To: <87o6e6yftw.fsf@jacob.g10code.de> References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> <87o6e6yftw.fsf@jacob.g10code.de> Message-ID: <195009e8-d637-4626-b0ea-d1baad358810@dorfdsl.de> Am 09.09.26 um 10:44 schrieb Werner Koch: > Never do this. Neither with gpg nor with any other tool which copies > tainted input data to stdout. At least use cat -v (or -e) or use less. Is using gpg --decrypt | cat -v safe to use? -- Gruß Marco Muell und Spam bitte an abfalleimer2002 at stinkedores.dorfdsl.de -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 665 bytes Desc: OpenPGP digital signature URL: From guru at unixarea.de Wed Sep 16 16:02:35 2026 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 16 Sep 2026 16:02:35 +0200 Subject: OpenPGP card in Android 15 Message-ID: Hello, My Son uses an Android 15 with Linux kernel: $ uname -a Linux localhost 5.10.226-android12-9-00047-g4968e29b7f92-ab12786767 #1 SMP PREEMPT Wed Dec 11 21:50:47 UTC 2024 aarch64 Android and wants to use the following OpenPGP card (output is from my FreeBSD laptop): $ gpg2 --card-status Reader ...........: 04E6:5816:55512030610911:0 Application ID ...: D27600012401030400050000CDED0000 Application type .: OpenPGP Version ..........: 3.4 Manufacturer .....: ZeitControl Serial number ....: 0000CDED Name of cardholder: [no establecido] Language prefs ...: de Salutation .......: URL of public key : [no establecido] Login data .......: [no establecido] Signature PIN ....: forzado Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 64 64 64 PIN retry counter : 3 0 3 Signature counter : 4 KDF setting ......: off Signature key ....: 4752 B3D7 7438 4887 BB31 73F1 F2A3 6C0D EDF7 41E4 created ....: 2026-07-16 23:05:56 Encryption key....: DAFB 4F52 27CE D09F C91E E29D 0719 A62E 4D5D 147F created ....: 2026-07-16 23:05:56 Authentication key: 8E46 9474 1C97 6469 F333 36EE 313B 5318 76A7 28D4 created ....: 2026-07-16 23:05:56 General key info..: [none] How is this to be done in Android? Thanks matthias -- Matthias Apitz, ✉ guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub UN votes for Sec Council: Portugal:134 Austria:131 Germany:104. No further comment From wk at gnupg.org Mon Sep 21 10:55:41 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2026 10:55:41 +0200 Subject: Test for the archive Message-ID: <87tsnjrnjm.fsf@jacob.g10code.de> Hi! we still seem to have problems with the mail archive. Thus this test mail. 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 Mon Sep 21 14:03:57 2026 From: wk at gnupg.org (Werner Koch) Date: Mon, 21 Sep 2026 14:03:57 +0200 Subject: handling bogus output of encrypted messages In-Reply-To: <195009e8-d637-4626-b0ea-d1baad358810@dorfdsl.de> (Marco Moock via Gnupg-users's message of "Wed, 16 Sep 2026 14:41:57 +0200") References: <3771d806-86e6-4d70-9ff9-9d91781f2c42@dorfdsl.de> <87o6e6yftw.fsf@jacob.g10code.de> <195009e8-d637-4626-b0ea-d1baad358810@dorfdsl.de> Message-ID: <87h5jistea.fsf@jacob.g10code.de> On Wed, 16 Sep 2026 14:41, Marco Moock said: > Is using gpg --decrypt | cat -v > safe to use? It avoids manipulations of the TTY using crontrol characters. However, there is still some room left for social engineering. 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 anton.txt at gmail.com Mon Sep 21 17:44:30 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 21 Sep 2026 18:44:30 +0300 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir Message-ID: <20260921184430.07d61349de536f4e2b6631bb@gmail.com> Hello, all. I observe this problem with GnuPG 2.42 -- the last version that works on my Windows XP. gpg-agent does not seem to work with any home directory except the default one, e.g.: rem Change to my home directory: > cd C:\Documents and Settings\Anton\Application Data\ rem Connect with the default homedir: > gpg-connect-agent --homedir gnupg /bye gpg-connect-agent: no running gpg-agent - starting 'C:\Program Files\gnupg\bin\gpg-agent.exe' gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-connect-agent: connection to agent established rem Duplicate the default directory to a location nearby: > xcopy /S /E gnupg gnupg1 rem Connect with a non-default homedir: > gpg-connect-agent --homedir gnupg1 /bye gpg-connect-agent: no running gpg-agent - starting 'C:\Program Files\gnupg\bin\gpg-agent.exe' gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-connect-agent: waiting for the agent to come up ... (4s) gpg-connect-agent: waiting for the agent to come up ... (3s) gpg-connect-agent: waiting for the agent to come up ... (2s) gpg-connect-agent: waiting for the agent to come up ... (1s) gpg-connect-agent: can't connect to the agent: Filename too long gpg-connect-agent: error sending standard options: No agent running It says "no running gpg-agent" even though a gpg-agent.exe process remains from the previous invocation. Killing it does not help. How does ^gpg-connect-agent test whether an agent is running, and how is that test related to the homedir? Can it be looking at the wrong place because the home location is somehow hardcoded somewhere, or must be additionally specified somewhere else? I fully realise that Windows XP and GnuPG 2.42 are both unsupported, and ask this question in the hope that someone remembers encoutering and solving this problem. Any suggestions on how to investigate and troubleshoot this situation are welcome. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From anton.txt at gmail.com Mon Sep 21 18:54:42 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Mon, 21 Sep 2026 19:54:42 +0300 Subject: Test for the archive References: <87tsnjrnjm.fsf@jacob.g10code.de> Message-ID: <20260921195442.5a39d902b3d185eaf021a550@gmail.com> Werner Koch: > we still seem to have problems with the mail archive. > Thus this test mail. Perhaps this is good occasion to recommend Gmane[1] as an alternative method participate in mailing lists. It provides an NNTP interface for reading and posting to mailling lists via a newsreader. It has advantages and disadvantages comapred to using the e-mail client. Additionally, the GnuPG mailinsg lists are independently archived at MARC, e.g.: . -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From arawson at proton.me Tue Sep 15 19:26:04 2026 From: arawson at proton.me (Andrew Rawson) Date: Tue, 15 Sep 2026 17:26:04 +0000 Subject: Disregard last message Message-ID: Hi, I previously reported what I suspected was an issue with libgcrypt 1.12.4-1. It was a red herring. I was experiencing a regression in Linux-firmware-amdgpu that was recently fixed. I suspect the boot errors from that resulted in the key corruption. After upgrading the GPU firmware I reinstalled libgcrypt 1.12.4-1 and the keys did not corrupt. Thanks, Andrew "Dru" Rawson Certified Secure Infrastructure Specialist (207)344-4867 dru at drudoestech.com drudoestech.com [CompTIA Certification Verification](https://www.credly.com/badges/63268fb4-b8c6-40fd-82f9-c68515ed2001/public_url) Sent from [Proton Mail](https://proton.me/mail/home) for iOS. -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Tue Sep 22 11:01:02 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Sep 2026 11:01:02 +0200 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir In-Reply-To: <20260921184430.07d61349de536f4e2b6631bb@gmail.com> (Anton Shepelev via Gnupg-users's message of "Mon, 21 Sep 2026 18:44:30 +0300") References: <20260921184430.07d61349de536f4e2b6631bb@gmail.com> Message-ID: <87y0ctr775.fsf@jacob.g10code.de> On Mon, 21 Sep 2026 18:44, Anton Shepelev said: > I observe this problem with GnuPG 2.42 -- the last > version that works on my Windows XP. gpg-agent does not Although 42 is in general a good answer, you probably mean GnuPG 2.4.2 released 3 years ago ;-) I think that even the current GnuPG version will work on XP SP3. > invocation. Killing it does not help. How does > ^gpg-connect-agent test whether an agent is running, and > how is that test related to the homedir? Can it be I think the problem you have is that you also copied the lock files maybe even with active locks and thus the stale lock file detection did not work. gpg-connect-agent, like all other components, opens the file given by "gpgconf -L agent-socket", read the port number and the magic cookie, connect to that port on localhost and the agent checks that the cookie matches. There are several ways to get the homedir, either using the envvar GNUPGHOME, a Registry entry, using the standard %APPDATA%\gnupg, or using what an optional gpgconf.ctl side-by-side to the gpgconf.exe specifies. gpg --debug ipc -K also shows how the agent is accessed. 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 22 11:05:31 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Sep 2026 11:05:31 +0200 Subject: Issues with libgcrypt 1.12.4-1 with pre-existing keys In-Reply-To: <6e1bf868-2bc0-4bf9-9046-11862f6d6df3@proton.me> (Andrew via Gnupg-users's message of "Mon, 14 Sep 2026 23:44:22 +0000") References: <6e1bf868-2bc0-4bf9-9046-11862f6d6df3@proton.me> Message-ID: <87tsnhr6zo.fsf@jacob.g10code.de> Hi! On Mon, 14 Sep 2026 23:44, Andrew said: > However, when I upgraded to libgcrypt 1.12.4-1, my gpg keys were > corrupted. I had to downgrade the package back to 1.12.3-1 and > re-import the keys from backup. I am currently holding the package Please describe in more detail how the keys are corrupted and what kind of keys you created? Plain *PGP keys, X.509, or ssh keys? Which algorithm, which GnuPG version using which patches? I dounbt that this is in any way related to the Libgcrypt version. The only open bug we have for 1.12.4 is that it does not nuild out of the box on macOS with an M4 CPU. 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 wk at gnupg.org Tue Sep 22 11:06:23 2026 From: wk at gnupg.org (Werner Koch) Date: Tue, 22 Sep 2026 11:06:23 +0200 Subject: Disregard last message In-Reply-To: (Andrew Rawson via Gnupg-users's message of "Tue, 15 Sep 2026 17:26:04 +0000") References: Message-ID: <87pky5r6y8.fsf@jacob.g10code.de> On Tue, 15 Sep 2026 17:26, Andrew Rawson said: > I previously reported what I suspected was an issue with libgcrypt > 1.12.4-1. It was a red herring. Ooops. I should read all mails before replying ;-). 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 kimblekabrain42 at gmail.com Tue Sep 22 05:48:35 2026 From: kimblekabrain42 at gmail.com (kabrain kimble) Date: Tue, 22 Sep 2026 03:48:35 +0000 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir Message-ID: Hi, I’m following up about an issue with GnuPG 2.42 on Windows XP. When I use a non-default home directory, GPG cannot connect to gpg-agent. Could you advise whether this is a known issue and what diagnostics or configuration details would be most useful for troubleshooting? Thank you. Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Sep 23 10:01:38 2026 From: wk at gnupg.org (Werner Koch) Date: Wed, 23 Sep 2026 10:01:38 +0200 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir In-Reply-To: (kabrain kimble via Gnupg-users's message of "Tue, 22 Sep 2026 03:48:35 +0000") References: Message-ID: <874ifgqtul.fsf@jacob.g10code.de> Hi! Please see the mail by Anton Shepelev and my reply. 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 guru at unixarea.de Wed Sep 23 11:23:13 2026 From: guru at unixarea.de (Matthias Apitz) Date: Wed, 23 Sep 2026 11:23:13 +0200 Subject: USB OpenPGP card in Android 15 Message-ID: Hello, Sorry if you receive this mail a 2nd time, but due to the fault with the list server I'm unsure if it was delivered. My Son uses an Android 15 mobile phone with this Linux kernel: $ uname -a Linux localhost 5.10.226-android12-9-00047-g4968e29b7f92-ab12786767 #1 SMP PREEMPT Wed Dec 11 21:50:47 UTC 2024 aarch64 Android and wants to use the following USB OpenPGP card (the output below is from my FreeBSD laptop): $ gpg2 --card-status Reader ...........: 04E6:5816:55512030610911:0 Application ID ...: D27600012401030400050000CDED0000 Application type .: OpenPGP Version ..........: 3.4 Manufacturer .....: ZeitControl Serial number ....: 0000CDED Name of cardholder: [no establecido] Language prefs ...: de Salutation .......: URL of public key : [no establecido] Login data .......: [no establecido] Signature PIN ....: forzado Key attributes ...: rsa2048 rsa2048 rsa2048 Max. PIN lengths .: 64 64 64 PIN retry counter : 3 0 3 Signature counter : 4 KDF setting ......: off Signature key ....: 4752 B3D7 7438 4887 BB31 73F1 F2A3 6C0D EDF7 41E4 created ....: 2026-07-16 23:05:56 Encryption key....: DAFB 4F52 27CE D09F C91E E29D 0719 A62E 4D5D 147F created ....: 2026-07-16 23:05:56 Authentication key: 8E46 9474 1C97 6469 F333 36EE 313B 5318 76A7 28D4 created ....: 2026-07-16 23:05:56 General key info..: [none] How is this to be done in Android? Thanks matthias -- Matthias Apitz, ✉ guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub I do not want to and will not become fit for war. Merz, go to the Eastern Front yourself! From anton.txt at gmail.com Wed Sep 23 12:36:48 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 23 Sep 2026 13:36:48 +0300 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir References: <20260921184430.07d61349de536f4e2b6631bb@gmail.com> <87y0ctr775.fsf@jacob.g10code.de> Message-ID: <20260923133648.b7aac7bfd8fcab4596168bdf@gmail.com> Werner Koch: > Anton Shepelev: > > > I observe this problem with GnuPG 2.42 -- the last > > version that works on my Windows XP. > > Although 42 is in general a good answer, you probably > mean GnuPG 2.4.2 released 3 years ago ;-) Beg pardon for misinforming you, Werner. I meant GnuPG 2.2.42. It is the last version in which invoking gpg.exe without parameters does /not/ fail with: > gpg gpg: WARNING: no command supplied. Trying to guess what you mean ... gpg: Go ahead and type your message ... gpg: [stdin]: read error: Exec format error (ec=8) gpg: processing message failed: Unknown system error Now I see that many later versions seems to work as well, except for this bug when expecting stdin from the console, which is rarely needed (if ever). It still can generate and edit keys interactively, after all. > I think that even the current GnuPG version will work > on XP SP3. I cannot test it, having the 32-bit version of Windows XP SP3. Both the installer gnupg-w32-2.5.22_20260831.exe and the binaries it contains require a 64-bit OS. A few older versions seem to be 32-bit however, but they fail to locate functions in DLLs: 2.4.8: KERNEL32.dll:DeleteProcThreadAttributeList 2.4.5: msvctrl.dll:_putenv Could the absence of these functions on Windows XP be handled gracefully? While working on pixel-perfect display for DOSBox, I had to support High-DPI awareness in newer Windowses in order to prevent blurry interpolaiton, while keeping the program compatible with Windows XP. IIRC, I achieved that with GetProcAddress()[1], which returns the address of a function is the DLL if it exports it, and NULL otherwise. Could something similar be used in GnuPG? Simply checking the OS version is not so reliable, because OneCore API[2] and other tricks can be used to upgrade the API of Windows XP. ...That said, 2.4.4 works, except the aforementioned stdin bug. It also breaks when used with the pager, however, as well as 2.2.42: C:\TEMP>gpg --version | more Not enough memory. :: ^ Who wrote the latter line -- gpg.exe or more.exe ? C:\TEMP>gpg --version > ver.txt C:\TEMP>type ver.txt | more gpg (GnuPG) 2.4.4 libgcrypt 1.10.3 Copyright (C) 2024 g10 Code GmbH ... Ah, and gpg-agent is still unavaialble with a non- standard home directory for 2.4.4. References to this error I have been able to find all agree that it occurs when the GPGHOME environment variable is longer that eighty-nine characters, e.g.: But in my case it is only sixty-six characters long: C:\Documents and Settings\Anton.GIT\Application Data\gnupg_test > I think the problem you have is that you also copied > the lock files maybe even with active locks and thus > the stale lock file detection did not work. I have tried creating a new homedir with `gpg --homedir gnupg1 -k' instead of copyng my real one, and the error persists. Anyway, please instruct me how to copy a GnuPG homedir to keep it working: shall I exclude the .lock files? Shall I test at some point that there are no active locks? If I shall, then how? > gpg-connect-agent, like all other components, opens > the file given by "gpgconf -L agent-socket", read the > port number and the magic cookie, connect to that port > on localhost and the agent checks that the cookie > matches. Although gpg respects my specified homedir gnupg_test: > gpg -k C:\Documents and Settings\Anton.GIT\Application Data\gnupg_test\work.kbx [...] gpgconf still uses the default one: > gpgconf -L agent-socket C:\Documents and Settings\Anton.GIT\Local Settings\Application Data\gnupg\d.amintiqo51rit39k\S.gpg-agent Can this be causing my problem? Shall I restart the computer after changing the home location? Hardly... > There are several ways to get the homedir, either > using the envvar GNUPGHOME, a Registry entry, using > the standard %APPDATA%upg, or using what an optional > gpgconf.ctl side-by-side to the gpgconf.exe specifies. I had already tried setting the registry entry for GnuPG 2.2.24, and it didn't work. I don't have a copy of the manual for that version (does not seem included in the distubution!) so maybe it was not yet implemented. I am using the environment variable now. > gpg --debug ipc -K > > also shows how the agent is accessed. Here is what it prints for me, with a non-standard homedir: > gpg --debug ipc -K gpg: reading options from 'C:/Documents and Settings/Anton.GIT/Application Data/gnupg_test/gpg.conf' gpg: reading options from '[cmdline]' gpg: enabled debug flags: ipc gpg: enabled compatibility flags: gpg: using pgp trust model gpg: no running gpg-agent - starting 'C:\\Program Files\\gnupg\\bin\\gpg-agent.exe' gpg: waiting for the agent to come up ... (5s) gpg: waiting for the agent to come up ... (4s) gpg: waiting for the agent to come up ... (3s) gpg: waiting for the agent to come up ... (2s) gpg: waiting for the agent to come up ... (1s) gpg: can't connect to the gpg-agent: Filename too long No gpg-agent.exe appeared. ____________________ 1. 2. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From anton.txt at gmail.com Wed Sep 23 12:54:33 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 23 Sep 2026 13:54:33 +0300 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir References: <20260921184430.07d61349de536f4e2b6631bb@gmail.com> <87y0ctr775.fsf@jacob.g10code.de> <20260923133648.b7aac7bfd8fcab4596168bdf@gmail.com> Message-ID: <20260923135433.ad835b2c89bf697a65e930f9@gmail.com> I wrote: > Shall I restart the computer after changing the home > location? No, it did not help, and the error persists: gpg-connect-agent: can't connect to the agent: Filename too long -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From anton.txt at gmail.com Wed Sep 23 17:59:59 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Wed, 23 Sep 2026 18:59:59 +0300 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir References: Message-ID: <20260923185959.caf9bcd7baadee3031aa2742@gmail.com> kabrain kimble: > I'm following up about an issue with GnuPG 2.42 on > Windows XP. I have to update my statement about the last version of GnuPG (mostly) working on Windows XP SP3. It is GnuPG 2.4.4. One prominent problem is that it cannot accept interactive input of payload from the terminal, but --edit-key and --gen-key work. Version 2.2.42 does not have that problem. > When I use a non-default home directory, GPG cannot > connect to gpg-agent. May I ask why you need to use GnuPG with a non-default home directory? In my case, I wanted to store it on a drive encrypted with VeraCrypt 1.25.7, because it is a work PC in an office. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From mario.hoberg at iserv.eu Wed Sep 23 21:26:05 2026 From: mario.hoberg at iserv.eu (Mario Hoberg) Date: Wed, 23 Sep 2026 21:26:05 +0200 Subject: scdaemon on macOS resolves legacy SCardControl, preventing PIN-pad use Message-ID: <7d37d99e-ea9f-4061-a208-64f46cb6e920@iserv.eu> Hello! Disclosure: This report and patch were developed by a ChatGPT AI agent. I manually sanity-checked both and manually tested the patch’s effectiveness with the reader. On macOS, scdaemon resolves SCardControl with dlsym() but calls it through a seven-argument function pointer. Apple’s PC/SC framework exports SCardControl as the legacy five-argument function; its seven-argument function is named SCardControl132. The header’s macro mapping of SCardControl to SCardControl132 does not affect a dlsym() lookup. OpenSC selects SCardControl132 explicitly on macOS. Test environment: macOS 27.2 (build 26B5091g), arm64 GnuPG 2.5.22, tested both unpatched and patched against the same reader and driver Cherry ST-2000 (USB 046a:003e) with an OpenPGP card, accessed through macOS PC/SC with CCID disabled in scdaemon In a read-only SERIALNO openpgp test, unpatched GnuPG 2.5.22 reads the card but logs: pcsc_control failed: not transacted (0x80100016) pcsc_vendor_specific_init: GET_FEATURE_REQUEST failed: 65547 With the proposed patch, the same GnuPG version and reader complete the feature request and detect FEATURE_VERIFY_PIN_DIRECT. I then entered the PIN on the ST-2000 keypad, created a test signature, and verified that signature successfully. The original symptom—PIN entry on the Mac instead of the reader—was also observed with MacGPG 2.2.44. Proposed patch against GnuPG 2.5.22: --- a/scd/apdu.c +++ b/scd/apdu.c @@ -1182,7 +1182,13 @@ pcsc_end_transaction = dlsym (handle, "SCardEndTransaction"); pcsc_transmit = dlsym (handle, "SCardTransmit"); pcsc_set_timeout = dlsym (handle, "SCardSetTimeout"); +#ifdef __APPLE__ + /* The 7-argument PC/SC API is exported under this name on macOS. + * SCardControl is the incompatible, older 5-argument API. */ + pcsc_control = dlsym (handle, "SCardControl132"); +#else pcsc_control = dlsym (handle, "SCardControl"); +#endif if (!pcsc_establish_context || !pcsc_release_context Could you review this macOS-specific lookup? I have tested it on the environment above, but not on older macOS releases. -- Best regards Mario Hoberg E-Mail: mario.hoberg at iserv.de Internet: iserv.de Zentrale: IServ GmbH, Vossenkamp 6, 38104 Braunschweig Niederlassungen: IServ GmbH, Girardetstr. 6, 45131 Essen IServ GmbH, Fanningerstraße 13, 10365 Berlin USt-IdNr. DE265149425 | Amtsgericht Braunschweig | HRB 201822 Geschäftsführer: Benjamin Heindl, Martin Hüppe, Jörg Ludwig Grundsätze zum Datenschutz: iserv.de/privacy IServ - aus der Schule für die Schule -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg-2.5.22-macos-scardcontrol132.patch Type: text/x-diff Size: 640 bytes Desc: not available URL: From gniibe at fsij.org Thu Sep 24 10:04:43 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 24 Sep 2026 17:04:43 +0900 Subject: scdaemon on macOS resolves legacy SCardControl, preventing PIN-pad use In-Reply-To: <7d37d99e-ea9f-4061-a208-64f46cb6e920@iserv.eu> References: <7d37d99e-ea9f-4061-a208-64f46cb6e920@iserv.eu> Message-ID: <87jyobt6qs.fsf@haruna.fsij.org> Hello, Thank you for your report. Mario Hoberg wrote: > On macOS, scdaemon resolves SCardControl with dlsym() but calls it > through a seven-argument function pointer. Apple’s PC/SC framework > exports SCardControl as the legacy five-argument function; its > seven-argument function is named SCardControl132. I have looked around PC/SC-lite and OpenSC, and this is a kind of old problem. It seems that pinpad feature is not used on macOS. I think that it is better to follow what OpenSC does; Try to find the function by the symbol "ScardControl132" and then the symbol "ScardControl" if "ScardControl132" fails. If Apple will change to follow new API, it will still work. Attached is a patch candidate: -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-Fix-pinpad-handling-for-macOS.patch Type: text/x-diff Size: 1687 bytes Desc: not available URL: From anton.txt at gmail.com Thu Sep 24 10:48:29 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Thu, 24 Sep 2026 11:48:29 +0300 Subject: scdaemon on macOS resolves legacy SCardControl, preventing PIN-pad use References: <7d37d99e-ea9f-4061-a208-64f46cb6e920@iserv.eu> <87jyobt6qs.fsf@haruna.fsij.org> Message-ID: <20260924114829.bac625df08b1001554f326c8@gmail.com> NIIBE Yutaka: > I think that it is better to follow what OpenSC does; > Try to find the function by the symbol > "ScardControl132" and then the symbol "ScardControl" > if "ScardControl132" fails. Here the function name's suffix is 132, but in your actual patch it is 123: > pcsc_control = dlsym (handle, "SCardControl123"); Which is correct? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From anton.txt at gmail.com Thu Sep 24 15:31:00 2026 From: anton.txt at gmail.com (Anton Shepelev) Date: Thu, 24 Sep 2026 16:31:00 +0300 Subject: GnuPG 2.42 on Windows XP: cannot connect to gpg-agent with a non-default homedir References: <20260923185959.caf9bcd7baadee3031aa2742@gmail.com> Message-ID: <20260924163100.40ef3ad6bcf480c6c54ad9a1@gmail.com> I wrote: > May I ask why you need to use GnuPG with a non-default > home directory? In my case, I wanted to store it on a > drive encrypted with VeraCrypt 1.25.7, because it is a > work PC in an office. I have been able to work around this issue with Junction[*] 1.06: junction C:\Documents and Settings\Anton.GIT\Application Data\gnupg A:\.gnupg where A:\ is my VeraCrypt encrypted volume. ____________________ * The latest version (now 1.07), and is available at . if it does not for you, I can share version 1.06. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From gniibe at fsij.org Fri Sep 25 03:11:07 2026 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 25 Sep 2026 10:11:07 +0900 Subject: scdaemon on macOS resolves legacy SCardControl, preventing PIN-pad use In-Reply-To: <20260924114829.bac625df08b1001554f326c8@gmail.com> References: <7d37d99e-ea9f-4061-a208-64f46cb6e920@iserv.eu> <87jyobt6qs.fsf@haruna.fsij.org> <20260924114829.bac625df08b1001554f326c8@gmail.com> Message-ID: <878q4qw2xg.fsf@haruna.fsij.org> Hello, Thank you very much for your review. Anton Shepelev wrote: > Here the function name's suffix is 132, but in your > actual patch it is 123: > >> pcsc_control = dlsym (handle, "SCardControl123"); My bad. It's a typo of mine. I think that it comes from the version 1.3.2 of the PC/SC implementation. Attached is the revised patch. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-scd-Fix-pinpad-handling-for-macOS.patch Type: text/x-diff Size: 1699 bytes Desc: not available URL: From rms at gnu.org Sat Sep 26 05:41:44 2026 From: rms at gnu.org (Richard Stallman) Date: Fri, 25 Sep 2026 23:41:44 -0400 Subject: GnuPG 2.5.24 and Gpg4win 5.1.1 released In-Reply-To: <87zex8nhdj.fsf@jacob.g10code.de> (message from Werner Koch on Wed, 23 Sep 2026 16:59:20 +0200) References: <87zex8nhdj.fsf@jacob.g10code.de> Message-ID: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] Congratulations on the new release. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From rjh at sixdemonbag.org Mon Sep 28 17:15:20 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Mon, 28 Sep 2026 11:15:20 -0400 Subject: Shea-Haller: LibrePGP not at risk Message-ID: A new paper has been published[1] presenting attacks on RSA signatures. The paper is legitimately interesting, but not panic-worthy. Shea-Haller (as I'm calling the paper, after the leading two authors) is interesting but not without fault. The first sentence in their abstract has a claim the field cannot quite support. They claim, "[t]he security of RSA is generally understood to be based on the complexity of factoring." Well, that's just not true, the security of RSA has never been proven equivalent to factoring. More to the point, there are good reasons to think it can't be. Cryptographers call the task of breaking RSA "the RSA problem," or RSAP. The problem of factoring large composites is "the integer factorization problem," or IFP. The RSA conjecture — and be sure to call it that — is RSAP = IFP.[2] We'll call this conjecture RSAC. We've had strong hints as far back as 1998 that RSAC was not strictly true. At EUROCRYPT '98 Dan Boneh, one of the smartest cryppies of his generation, presented with Ram Venkatesan a fairly strong bit of evidence[3] RSAC was false. Unfortunately, the Boneh-Venkatesan result didn't really lend itself well to follow-up papers. It took a few years to see more published results related to RSAC, such as a 2007 paper by Joux, Naccache, and Thomé[4]. The Shea-Haller paper builds on the Joux, Naccache, and Thomé paper. It's legitimately good work: it's going to have cryppies the world over talking. At the same time, it's not something working nerds need to worry about. The overwhelming majority of computer systems that use RSA add a little special seasoning[5] to the mix that foils this kind of attack. Neither LibrePGP nor OpenPGP are susceptible to this attack. Don't panic. You're probably not at risk. RSAC is probably false, but that's okay. 1 https://eprint.iacr.org/2026/2131.pdf 2 Sigh, okay, fine: "polynomial-time reductions exist between instances of RSAP and IFP." 3 https://crypto.stanford.edu/~dabo/papers/no_rsa_red.pdf 4 https://eprint.iacr.org/2007/424 5 Okay, fine: it's a mix of cayenne pepper, salt, and MSG. Happy? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From jb-gnumlists at wisemo.com Tue Sep 29 16:18:47 2026 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Tue, 29 Sep 2026 16:18:47 +0200 Subject: Shea-Haller: LibrePGP not at risk In-Reply-To: References: Message-ID: On 28/09/2026 17:15, Robert J. Hansen via Gnupg-users wrote: > A new paper has been published[1] presenting attacks on RSA signatures. > The paper is legitimately interesting, but not panic-worthy. > > Shea-Haller (as I'm calling the paper, after the leading two authors) is > interesting but not without fault. The first sentence in their abstract > has a claim the field cannot quite support. They claim, "[t]he security > of RSA is generally understood to be based on the complexity of factoring." > > Well, that's just not true, the security of RSA has never been proven > equivalent to factoring. More to the point, there are good reasons to > think it can't be. > > Cryptographers call the task of breaking RSA "the RSA problem," or RSAP. > The problem of factoring large composites is "the integer factorization > problem," or IFP. The RSA conjecture — and be sure to call it that — is > RSAP = IFP.[2] We'll call this conjecture RSAC. > > We've had strong hints as far back as 1998 that RSAC was not strictly > true. At EUROCRYPT '98 Dan Boneh, one of the smartest cryppies of his > generation, presented with Ram Venkatesan a fairly strong bit of > evidence[3] RSAC was false. > > Unfortunately, the Boneh-Venkatesan result didn't really lend itself > well to follow-up papers. It took a few years to see more published > results related to RSAC, such as a 2007 paper by Joux, Naccache, and > Thomé[4]. > > The Shea-Haller paper builds on the Joux, Naccache, and Thomé paper. > It's legitimately good work: it's going to have cryppies the world over > talking. > > At the same time, it's not something working nerds need to worry about. > The overwhelming majority of computer systems that use RSA add a little > special seasoning[5] to the mix that foils this kind of attack. > > Neither LibrePGP nor OpenPGP are susceptible to this attack. > > Don't panic. You're probably not at risk. RSAC is probably false, but > that's okay. > > > 1 https://eprint.iacr.org/2026/2131.pdf > 2 Sigh, okay, fine: "polynomial-time reductions exist between > instances of RSAP and IFP." > 3 https://crypto.stanford.edu/~dabo/papers/no_rsa_red.pdf > 4 https://eprint.iacr.org/2007/424 > 5 Okay, fine: it's a mix of cayenne pepper, salt, and MSG. Happy? Dear Mr. Hansen, As a working nerd who also deals with other uses of the RSA algorithm, it would be nice to know which seasonings counteract this new poison and the old results that it builds upon. I happen to be the designer of at least one non-public protocol that touches RSA, and thus had to do my own seasoning back in the day, thus this is not just curiousity. 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 rjh at sixdemonbag.org Tue Sep 29 18:04:51 2026 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Tue, 29 Sep 2026 12:04:51 -0400 Subject: Shea-Haller: LibrePGP not at risk In-Reply-To: References: Message-ID: > As a working nerd who also deals with other uses of the RSA algorithm, it > would be nice to know which seasonings counteract this new poison and the > old results that it builds upon. Basically, "don't use raw RSA". Using any sane kind of signature padding scheme, like PKCS#1-1.5 or RSA-PSS, foils the attack. From bwalzer at 59.ca Tue Sep 29 19:59:42 2026 From: bwalzer at 59.ca (Bruce Walzer) Date: Tue, 29 Sep 2026 12:59:42 -0500 Subject: Shea-Haller: LibrePGP not at risk In-Reply-To: References: Message-ID: On Tue, Sep 29, 2026 at 12:04:51PM -0400, Robert J. Hansen via Gnupg-users wrote: > > As a working nerd who also deals with other uses of the RSA algorithm, it > > would be nice to know which seasonings counteract this new poison and the > > old results that it builds upon. > > Basically, "don't use raw RSA". Using any sane kind of signature padding > scheme, like PKCS#1-1.5 or RSA-PSS, foils the attack. Or don't provide an attacker with an unlimited RSA signature oracle and then withdraw access to the oracle later. In any sort of imaginable PGP context, for example, that wouldn't even make sense. Any bad stuff that the attacker might do could be done when the oracle is available. Bruce