From lee4hom at gmail.com Sat Oct 1 16:39:48 2022 From: lee4hom at gmail.com (Tony Lee) Date: Sat, 1 Oct 2022 15:39:48 +0100 Subject: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG Message-ID: On Aug 27 I submitted a query to this mailing list on the same Subject as headed here, with further details on the software used. Specifically, I timed the encryption (primarily the KDF aspect) of alternative cleartext_files with various legal count_value values (1024, 131072, 2097152, 65011712) as: time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \ --s2k-count count_value cleartext_file I was surprised to find that count_value of 1024 gave a timing nearly as long as that for 65011712. I was pleased to receive a rapid response from Werner Koch, who explained that the nominated count_value of 1024 actually used a default count_value compatible with gpg 1.4, and then went on to explain that OpenPGP used an SHA1-based Key Distribution Function (KDF). However, in my Aug 30 response, I noted that I had carefully followed the gpg man pages in specifying my wish to use an AES256 cipher, and an SHA256 hash function. The count_value of 1024 clearly ignored my wishes on hash function (for gpg 1.4 compatibility), and --- I must assume --- also used AES128 cipher for the same reason. As I noted, both AES-128 and SHA-1 are generally deprecated functions in cryptography. So I am left wondering whether my specified AES-256 and SHA-256 were used with my other count_value values. My Aug 27 submission highlighted a Spectra Secure YouTube which noted that the --s2k parameters were ignored for key export without warning, and that this "bug" had been the case since 2017. Do we now discover that the --s2k parameters are similarly ignored for _all_ symmetric encryption procedures, in contradiction to the man-page instructions on use? My earlier submissions noted that KeePass (password safe) gave an encouraging oversight of how areas of memory were secured from other applications while KeePass is in use, giving a degree of protection from malware etc., or having critical data finding its way onto disk storage --- ready for scrutiny my a later hacker. I sought a similar oversight on gpg --- perhaps based on the KeePass template. I noted the possibility that such techniques were so obviously necessary that (perhaps) there was little point in describing them. The response that I have seen merely implied that such oversight would take a lot of effort to write, and may be less helpful than expected. This suggests to me that these "obviously necessary" techniques were _not_ being implemented (or even attempted), and that the only solution was to fully ensure the security of your entire system. I see this as a "Counsel of Perfection" that may only be practical with an air-gapped system that has had no data input from the internet. My understanding is that Security is something typically applied in layers, with the full knowledge that any single layer is unlikely to be perfect. The concept that no thought may be given within gpg to the protection of passwords, and that deprecated cryptographic functions may be in use (despite commands to the contrary), seems to me to be highly disturbing. Tony From steffen at sdaoden.eu Sat Oct 1 18:23:19 2022 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 01 Oct 2022 18:23:19 +0200 Subject: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG In-Reply-To: References: Message-ID: <20221001162319.7iIl1%steffen@sdaoden.eu> Tony Lee wrote in : |On Aug 27 I submitted a query to this mailing list on the same Subject ... |The concept that no thought may be given within gpg to the protection of |passwords, and that deprecated cryptographic functions may be in use |(despite commands to the contrary), seems to me to be highly disturbing. Highly disturbing to me are such poisoning emails like you write continuously. The software you talk about is classified to be used by governments to some extend, and i rather have Werner and his team work on improving this big software suite than answering mails of stinking piles. Just my one cent. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From jcb62281 at gmail.com Mon Oct 3 02:31:57 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 02 Oct 2022 19:31:57 -0500 Subject: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG In-Reply-To: References: Message-ID: <633A2D7D.2080004@gmail.com> Tony Lee via Gnupg-users wrote: > [...] > > I was pleased to receive a rapid response from Werner Koch, who > explained that the nominated count_value of 1024 actually used a default > count_value compatible with gpg 1.4, and then went on to explain that > OpenPGP used an SHA1-based Key Distribution Function (KDF). KDF here is "Key Derivation Function", not "Key Distribution Function". > However, in my Aug 30 response, I noted that I had carefully followed > the gpg man pages in specifying my wish to use an AES256 cipher, and > an SHA256 hash function. If I understand correctly, it probably did: your data was encrypted using AES256 using a key derived from your passphrase using the OpenPGP KDF and an integrity check value using SHA256 was included with the encrypted data. > [...] As I noted, both AES-128 and SHA-1 are generally deprecated > functions in cryptography. This is completely irrelevant to a KDF. The only purpose of a KDF is to expend considerable computational power to derive a key from a passphrase, to partially compensate for the expected low entropy of a passphrase by making a search dramatically more expensive. > So I am left wondering whether my specified AES-256 and SHA-256 were > used with my other count_value values. Most probably yes, although you would need to examine the source code to be certain. GPG 1.4 *did* support AES256 and SHA256, so compatibility would not be an excuse to fail to use them. > My Aug 27 submission highlighted a Spectra Secure YouTube which noted > that the --s2k parameters were ignored for key export without warning, > and that this "bug" had been the case since 2017. Do we now discover > that the --s2k parameters are similarly ignored for _all_ symmetric > encryption procedures, in contradiction to the man-page instructions > on use? If so, that would be a very serious bug, but you would need to examine the sources to make sure. -- Jacob From lee4hom at gmail.com Mon Oct 3 18:45:48 2022 From: lee4hom at gmail.com (Tony Lee) Date: Mon, 3 Oct 2022 17:45:48 +0100 Subject: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG In-Reply-To: References: Message-ID: TL > I was pleased to receive a rapid response from Werner Koch, who explained that the nominated count_value of 1024 actually used a default count_value compatible with gpg 1.4, and then went on to explain that OpenPGP used an SHA1-based Key Distribution Function (KDF). Jacob B > KDF here is "Key Derivation Function", not "Key Distribution Function". You are correct: not sure how this happened. My original submission reflected a "Notes" paper I had been writing (for my own clarification) which included an acronyn list with the correct expansion. I guess this confirms my status as a non-expert, which is why I "Seek Assurance"! Jacob B > If I understand correctly, it probably did: your data was encrypted using AES256 using a key derived from your passphrase using the OpenPGP KDF and an integrity check value using SHA256 was included with the encrypted data. That was certainly my intention, using: time gpg2 -c --s2k-cipher-algo AES256 --s2k-digest-algo SHA256 \ --s2k-count count_value cleartext_file where the man gpg states: --s2k-cipher-algo name Use name as the cipher algorithm for symmetric encryption with a passphrase --s2k-digest-algo name Use name as the digest algorithm used to mangle the passphrases for symmetric encryption. The default is SHA-1. --s2k-count n Specify how many times the passphrases mangling for symmetric encryption is repeated. This value may range between 1024 and 65011712 inclusive. Werner noted [for Count 1024] For backward compatibility reasons with 1.4 the default count value is used in this case [and] You can't compare some AES-KDF to the SHAl based KDF of OpenPGP. The --s2k options mention "mangling passphrases" which sounds exactly like a KDF, but a default SHA-1 was used in one case, at least. TL > My Aug 27 submission highlighted a Spectra Secure YouTube (dated 29 Nov 2021) which noted that the --s2k parameters were ignored for key export without warning, and that this "bug" had been the case since 2017. Jacob B > ... that would be a very serious bug ... The Spectra Secure YouTube was: https://www.youtube.com/watch?v=j-qBChKG15Y "Password Managers: The Case Against GNU pass (feat gpg)". Around minute 4:31 it explains very clearly that the --s2k settings do not work (when exporting a key), showing screen evidence. In a later comment, Spectra Secure quotes "additional context on reddit" from skeeto at: https://www.reddit.com/r/commandline/comments/r4ndi9/comment/hmjbkmc/ , which states: "The exported S2K protection is different than than the protection used on the keyring, so you can't infer anything about GnuPG keys at rest unless you're storing them in exported format rather than on your keyring. This changed in GnuPG 2.1, and that's why the S2K options are silently ignored as of GnuPG 2.1. I'm the person who filed the bug report discussed in the video, and the responses to that report are how I learned what's going on.". This implies the "silent ignoring" is correct for exported keys, but may not be relevant to other functions. We now seem to find it can be relevant to other activities as well. In fact, all I can really infer is that practice does not match the man gpg, so it is difficult to decide what is (or should be) going on. I am not really in a position to examine the sources with any confidence, but would welcome suggestions for software which would permit me to check what was set up. Does John the Ripper (gpg-opencl), plus hashcat, detail the algorithms used, having broken a password? Tony From gnupg-users at spodhuis.org Tue Oct 4 01:14:49 2022 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Mon, 3 Oct 2022 23:14:49 +0000 Subject: WKD: conveying intent of encrypt-by-default? Message-ID: Folks, I setup WKD for work a while back, to publish the PGP keys for those who had them. Then in November I removed the first key because it was causing Protonmail users to keep sending encrypted to the recipient and a lot of his communications turned out to be with Protonmail users. Now we've had this happening again, with someone else, and one very plausible outcome at this point is that we remove almost everyones' keys from WKD, leaving only those who sign security advisories, because WKD and the ecosystem right now is causing bigger problems than it solves. I think that there's a perfectly reasonable conflation of semantic intent. I'm not sure what the solution is, although I'm thinking that _perhaps_ the answer is to extend the allowed values in the "policy" file, to convey intent to a different audience than those uploading keys. Problem: we use PGP for signing and for certain transactions which need high confidentiality, but for the most part, for most of our staff, setting up a PGP-capable mail client with our mail-provider is a pain and we're not interested. We want the PGP keys _available_ for people to have a trusted path to the key, but that does _not_ mean that we want people to default to using PGP for all communications with us. While Protonmail is the triggering party here, I don't think that they're at fault: for their model, what they've set up is probably a reasonable implementation. So please, no rants about Protonmail. Am I right in thinking that WKD was not really intended to be a trigger for opportunistic upgrade to PGP-encryption for messaging? Does it seem reasonable to add a directive to WELLKNOWN/policy, so that any WKD client can see what a general domain policy is? I could see individual users having other preferences, and I guess there's no reason that an additional binary PGP packet, not signed by the key, couldn't be served up together with the key from the WKD server. But that's more extensive coding to handle and interpret. Tentatively, perhaps: email-encrypt-by-default: yes email-encrypt-by-default: no and then if not present, then the intent is unspecified. We would then add "email-encrypt-by-default: no" and then the WKD draft could clarify as an implementation consideration that "availability of the key does not imply routine use of the key is desired". -Phil -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From gnupg at eckner.net Tue Oct 4 07:00:48 2022 From: gnupg at eckner.net (Erich Eckner) Date: Tue, 4 Oct 2022 07:00:48 +0200 (CEST) Subject: WKD: conveying intent of encrypt-by-default? In-Reply-To: References: Message-ID: <90af41cd-9779-6088-7d8b-67750625c170@eckner.net> On Mon, 3 Oct 2022, Phil Pennock via Gnupg-users wrote: > Folks, > > I setup WKD for work a while back, to publish the PGP keys for those who > had them. Then in November I removed the first key because it was > causing Protonmail users to keep sending encrypted to the recipient and > a lot of his communications turned out to be with Protonmail users. > > Now we've had this happening again, with someone else, and one very > plausible outcome at this point is that we remove almost everyones' keys > from WKD, leaving only those who sign security advisories, because WKD > and the ecosystem right now is causing bigger problems than it solves. > > I think that there's a perfectly reasonable conflation of semantic > intent. I'm not sure what the solution is, although I'm thinking that > _perhaps_ the answer is to extend the allowed values in the "policy" > file, to convey intent to a different audience than those uploading > keys. > > Problem: we use PGP for signing and for certain transactions which need > high confidentiality, but for the most part, for most of our staff, > setting up a PGP-capable mail client with our mail-provider is a pain > and we're not interested. We want the PGP keys _available_ for people > to have a trusted path to the key, but that does _not_ mean that we want > people to default to using PGP for all communications with us. > > While Protonmail is the triggering party here, I don't think that > they're at fault: for their model, what they've set up is probably a > reasonable implementation. So please, no rants about Protonmail. > > Am I right in thinking that WKD was not really intended to be a trigger > for opportunistic upgrade to PGP-encryption for messaging? > > Does it seem reasonable to add a directive to WELLKNOWN/policy, so that > any WKD client can see what a general domain policy is? > > I could see individual users having other preferences, and I guess > there's no reason that an additional binary PGP packet, not signed by > the key, couldn't be served up together with the key from the WKD > server. But that's more extensive coding to handle and interpret. > > Tentatively, perhaps: > > email-encrypt-by-default: yes > email-encrypt-by-default: no > > and then if not present, then the intent is unspecified. We would then > add "email-encrypt-by-default: no" and then the WKD draft could clarify > as an implementation consideration that "availability of the key does > not imply routine use of the key is desired". > > -Phil > Hi Phil, ignoring your proposal (it sounds valid to me), would it be an option to make the key a pure signing key? What's the use case to have an encryption key but not receive encrypted email by default? regards, Erich From jcb62281 at gmail.com Tue Oct 4 06:39:04 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Mon, 03 Oct 2022 23:39:04 -0500 Subject: WKD: conveying intent of encrypt-by-default? In-Reply-To: References: Message-ID: <633BB8E8.90403@gmail.com> Phil Pennock via Gnupg-users wrote: > [...] > > Problem: we use PGP for signing and for certain transactions which need > high confidentiality, but for the most part, for most of our staff, > setting up a PGP-capable mail client with our mail-provider is a pain > and we're not interested. We want the PGP keys _available_ for people > to have a trusted path to the key, but that does _not_ mean that we want > people to default to using PGP for all communications with us. > Simple option if most users at your site will be generating PGP signatures but not running PGP-capable MUAs: generate sign-only keys and put those in WKD. You would need a second mechanism for distributing the encryption-permitted keys for those users who need them, but the encryption keys could in turn be signed with the WKD sign-only keys to prevent a man-in-the-middle attack. -- Jacob From wk at gnupg.org Tue Oct 4 09:56:38 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 04 Oct 2022 09:56:38 +0200 Subject: WKD: conveying intent of encrypt-by-default? In-Reply-To: (Phil Pennock via Gnupg-users's message of "Mon, 3 Oct 2022 23:14:49 +0000") References: Message-ID: <87bkqsc98p.fsf@wheatstone.g10code.de> Hi Phil, To clarify: Why do you put keys intended only for signing into the WKD? The only purpose of the WKD is to discover keys used to encrypt outgoing data/mail. To verify a signature the WKD does not really help because there is no way to look up the key by fingerprint. Well, one of the fallbacks is: /* If the above methods didn't work, our next try is to retrieve the * key from the WKD. This requires that WKD is in the AKL and the * Signer's UID is in the signature. */ However, to be able to do this, the signer needs to specify the signing key by NAME (e.g. wk at gnupg.org) and not key fingerprint or keyid (e.g. AEA84EDCF01AD86C4701C85C63113AE866587D0A) as suggested. Or to use the --sender option. Is this your use-case? Makes some sense to me. Summary of options: 1. Upload sign-only keys (strip the encryption subkey). You can't use the Web Key Service in this case. You have to resort to another mechanism like build a local mirror and rsync it. 2. Add a notation to the key not to use the encryption key without asking. This requires all clients to understand this notation and act acordingly. 3. Add a WKD policy not to use the key for opportunistic encryption. Also needs cleint changes. 4. A variant of 1 which strips the encryption subkey after the publication has been confirmed. This can be done with a WKS protocol extension. Advantage is that it can be done on a key by key base. 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From s7r at sky-ip.org Tue Oct 4 23:21:19 2022 From: s7r at sky-ip.org (s7r) Date: Wed, 5 Oct 2022 00:21:19 +0300 Subject: Pass expiration date param to subkey only via unattended key generation Message-ID: <869265c7-8274-b067-8463-3991dbdc726f@sky-ip.org> Dear All, Context: https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html A script will create on demand GPG keys unattended that will be further used to automatically sign a document, but the requirement is that they must also include an Encryption subkey to receive feedback securely. Question is: keys can be generated unattended just fine, except I did not find a clear way to pass an Expire date param to the encryption subkey only, and not the primary key as well. The requirement is that the primary key must NEVER expire and the encryption subkey MUST expire in 2 years. Example: Key-Type: eddsa Key-Curve: ed25519 Key-Usage: sign, cert, auth Name-Real: Test Name-Email: test at test.com Expire-Date: 0 Subkey-Type: ecdh Subkey-Curve: cv25519 Subkey-Usage: encrypt How to pass an expiration date ONLY for the encryption subkey while leaving the primary key with no expiration date? (I know that this goal can be later achieved by using $ gpg --edit-key but I am looking for a solution within the unattended key generation itself) -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From mahmutcvdr at gmail.com Wed Oct 5 02:16:37 2022 From: mahmutcvdr at gmail.com (Mahmut Cavdar) Date: Wed, 5 Oct 2022 03:16:37 +0300 Subject: Pass expiration date param to subkey only via unattended key Message-ID: Hi s7r, I don't know whether updating source code is an option for you or not. Since it's the only way I can think, let me point the related line in old commit: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=g10/keygen.c;h=9c371bd1afb6a88a950c358f90df494b7d4a4564;hb=402aa0f94854bb00475c934be5ca6043a4632126#l3086 Mahmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Oct 5 15:09:03 2022 From: wk at gnupg.org (Werner Koch) Date: Wed, 05 Oct 2022 15:09:03 +0200 Subject: Pass expiration date param to subkey only via unattended key generation In-Reply-To: <869265c7-8274-b067-8463-3991dbdc726f@sky-ip.org> (s7r's message of "Wed, 5 Oct 2022 00:21:19 +0300") References: <869265c7-8274-b067-8463-3991dbdc726f@sky-ip.org> Message-ID: <87o7uqa040.fsf@wheatstone.g10code.de> On Wed, 5 Oct 2022 00:21, s7r said: > Question is: keys can be generated unattended just fine, except I did > not find a clear way to pass an Expire date param to the encryption > subkey only, and not the primary key as well. The requirement is that Use gpg --quick-gen-key --batch test at test.com ed25519 sign,cert and then gpg --quick-add-key --batch FINGERPRINT cv25519 encr sign,cert 2y Use --status-fd to get status lines which will return you the fingerprint from the first command. You might also want to use --yes to allow creating a key with an already existing name or --passphrase "mysecret" to avoid the pinentry. (commands typed from memory so you may nned to consult the man page.) 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From s7r at sky-ip.org Wed Oct 5 17:13:21 2022 From: s7r at sky-ip.org (s7r) Date: Wed, 5 Oct 2022 18:13:21 +0300 Subject: Pass expiration date param to subkey only via unattended key generation In-Reply-To: <87o7uqa040.fsf@wheatstone.g10code.de> References: <869265c7-8274-b067-8463-3991dbdc726f@sky-ip.org> <87o7uqa040.fsf@wheatstone.g10code.de> Message-ID: <1744f6f1-d24f-0503-1890-a81c10d853ad@sky-ip.org> > Use > > gpg --quick-gen-key --batch test at test.com ed25519 sign,cert > > and then > > gpg --quick-add-key --batch FINGERPRINT cv25519 encr sign,cert 2y > Thank you very much! I will see how I can apply this, in a single sh script with the unattended key generation as well. The thing is I "feed" the private key material to gnupg for generation, the key is not generated randomly. Isn't it wise to add a "Subkey-Expire-Date:" param that will map to pSUBKEYEXPIRE (I can see there is a pSUBKEYEXPIRE from browsing the code)? That will only touch the subkey itself, without caring about the primary key? Or it doesn't work like this? -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 495 bytes Desc: OpenPGP digital signature URL: From christian.roy3 at retraitequebec.gouv.qc.ca Thu Oct 6 21:01:15 2022 From: christian.roy3 at retraitequebec.gouv.qc.ca (Roy Christian (DAIT-SITL)) Date: Thu, 6 Oct 2022 19:01:15 +0000 Subject: gpg-agent refuse to start Message-ID: Hello, Our applications called the GNUPG 1.4.2 executable and it worked without issue. We upgraded to GNUPG version 2.2.27 and now we have problems with the gpg-agent. This sometimes refuses to start. The log looks like this: gpg-connect-agent: pas d'instance de gpg-agent en cours d'ex,cution -?d,marrage de ??C:\Program Files (x86)\GnuPG\bin\gpg-agent.exe?? gpg-connect-agent: waiting for the agent to come up ... (5s) gpg-agent[3580]: Attention : ? --use-standard-socket ? est une option obsol?te - non prise en compte gpg-agent[3580]: erreur de lien de la socket ? ? C:/ProgRRQ/GnuPG/RRQGnuPG02E/S.gpg-agent ? : Unknown error 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: ?chec de l'appel IPC connect gpg-connect-agent: erreur d'envoi d'options standards?: Pas d'agent en cours d'ex,cution - We are on Windows Server 2016 with gpg4win 3.1.15. - We have seventeen directories (homedir) each containing the keys of a communication partner. So there can be up to 17 agents running. - For now, after each restart of the server, I do a manual start of the seventeen agents. The starting problem is also present in manual. I use this command: "C:\Program Files (x86)\GnuPG\bin\gpg-connect-agent" --homedir C:/ProgRRQ/GnuPG/RRQGnuPG01E /bye - I have experimented with version 2.3.7 and the problem occurs much less often, but it is still present. - Is our use of GNUPG 2 correct? Should we go back to the latest version 1.4? - Here is an example of a call by one of our applications: "C:\Program Files (x86)\GnuPG\bin\gpg.exe" --batch --yes --display-charset utf-8 --passphrase-fd 0 --pinentry-mode loopback --verbose --ignore-mdc-error --homedir C:\ProgRRQ\GnuPG\RRQGnuPG15P -r "RQ Prod" -o "\\siaechpcq02\depotsys\EE5\EE5N731_Temp\urh1vftx.scs" -d "\\siaechpcq02\depotsys\EE5\EE5N731_Temp\nfbxl3yo.4nb" C. Roy From d.iskandarov at gmail.com Fri Oct 7 16:20:11 2022 From: d.iskandarov at gmail.com (Denis Iskandarov) Date: Fri, 7 Oct 2022 18:20:11 +0400 Subject: How to batch generate ed25519 keys ? Message-ID: How to generate ed25519 keys using "gpg --full-generate-key --batch" command? This is the command from one of the latest my at: gpg --full-generate-key --batch << EOF > %no-protection > Key-Type: ecc > Key-Curve: ed25519 > Subkey-Type: ecc > Subkey-Length: cv25519 > Expire-Date: 0 > Name-Real: demo-cluster > Name-Comment: secrets encryption > EOF > > gpg: signing failed: Invalid digest algorithm > gpg: make_keysig_packet failed: Invalid digest algorithm > gpg: key generation failed: Invalid digest algorithm What are the correct values or config for such a standard case? Where is it possible to see the correct list of available algorithms and their settings (curve) for such configurations? I thought that (sub)key-type accepts the same numbers as seen in interactive non-batch "gpg --full-generate-key". Using interactive "--full-generate-key" works, of course, flawlessly, but I was not able to get enough hints from it on how to build config for batch operations. Why one algo is ed25519 and the other one is cv25519? Sad that there are no clear instructions/docs for that, or it is required to learn all docs by heart and make PhD for all related crypto libs and apps. But if you give me some info I hopefully will be able to compile some little article. Just tired that 99% of all examples on the internet use RSA and "--quick-gen-key". (I've been reading your docs and trying to google answers for quite some time :) ) (Cursed XXI century, why do some applications can't add a little bit more convenience and stop trying to look like crap from the 1990s) -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Fri Oct 7 23:11:57 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 07 Oct 2022 23:11:57 +0200 Subject: How to batch generate ed25519 keys ? In-Reply-To: References: Message-ID: <5612456.DvuYhMxLoT@breq> On Freitag, 7. Oktober 2022 16:20:11 CEST Denis Iskandarov via Gnupg-users wrote: > How to generate ed25519 keys using "gpg --full-generate-key --batch" > command? [...] > Sad that there are no clear instructions/docs for that, or it is required > to learn all docs by heart and make PhD for all related crypto libs and > apps. But if you give me some info I hopefully will be able to compile some > little article. Just tired that 99% of all examples on the internet use RSA > and "--quick-gen-key". The instructions are pretty clear: Use --quick-gen-key instead of --full- generate-key. If you use gpg 2.3, then you won't even have to specify the algorithm because ed25519/cv25519 will be used by default. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From bosdan at protonmail.com Sat Oct 8 17:01:46 2022 From: bosdan at protonmail.com (Daniel Bossert) Date: Sat, 08 Oct 2022 15:01:46 +0000 Subject: How to create v4 key Message-ID: Hi all, thanks for beeing in this group. It might be a beginner questions: How can I create a v4-key with Windows/Kleopatra or gpg on LinuxMint? When I choose a RSA3076 key, keyserver.pgp.com will accept it. When i choose an ed25519 key, keyserver.pgp.com tells me it is a v3-key. Somewhere I read that nowadays no program should create v3-keys per default. I hardly found useful information on v3/v4 keys. Could someone kindly assist? Many thanks! Regards, Daniel? Sent with Proton Mail secure email. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - bosdan at protonmail.com - 0x1B2DA6F2.asc Type: application/pgp-keys Size: 657 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 249 bytes Desc: OpenPGP digital signature URL: From rjh at sixdemonbag.org Sun Oct 9 00:46:43 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 8 Oct 2022 18:46:43 -0400 Subject: How to create v4 key In-Reply-To: References: Message-ID: <66efb566-f691-d96a-7a98-15342307cb4e@sixdemonbag.org> > When I choose a RSA3076 key, keyserver.pgp.com will accept it. > When i choose an ed25519 key, keyserver.pgp.com tells me it is a v3-key. keyserver.pgp.com is *old* and doesn't understand how to use ed25519 keys. It is erroneously telling you it's a v3 key, when the reality is keyserver.pgp.com is in desperate need of upgrades to support new algorithm types. From bynect at gmail.com Tue Oct 11 17:23:49 2022 From: bynect at gmail.com (nect) Date: Tue, 11 Oct 2022 17:23:49 +0200 Subject: Subkeys renewing/expiring strategy In-Reply-To: References: Message-ID: Hello, I started using gpg relatively recently (1 year or so), mainly for signing git commits, and I am far from mastering it. Since I was struggling to choose a strategy for expiring/renewing my subkeys (more details below) I decided to seek expert advice (hopefully this is the right place). At the moment, I have my primary key (with no expiry) stored on a offline drive. I created the key 1 year ago, alongside a set of subkeys whose expiry was due in 1 year. Since they recently expired, I created another triplet of subkeys (sign, author, encrypt) and started using them instead of the old ones. Now, when I was doing this I realized that this strategy is not particularly good, especially in the long run, since you have to recreate every year (or 2) the new subkeys and let the old ones expire (losing some trust?). Also, uploading the new keys to every website that you use (eg GitLab) is quite the annoying chore. So, I was wondering what's the best strategy I can use to keep my (sub)keys valid without compromising on security. Is bumping the expiry date every year or so a better solution? Also, are subkeys with unlimited expiry bad, or am I just being carried away? Regards PS: I would also like to add that is not related to any professional setting, I am just trying to learn how to use gpg correctly (mainly to satisfy my curiosity). -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Tue Oct 11 19:44:19 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Tue, 11 Oct 2022 19:44:19 +0200 Subject: Subkeys renewing/expiring strategy In-Reply-To: References: Message-ID: <8171810.NyiUUSuA9g@daneel> On Dienstag, 11. Oktober 2022 17:23:49 CEST nect via Gnupg-users wrote: > I started using gpg relatively recently (1 year or so), mainly for > signing git commits, and I am far from mastering it. > > Since I was struggling to choose a strategy for expiring/renewing my > subkeys (more details below) I decided to seek expert advice (hopefully > this is the right place). I'm far from being an expert. > At the moment, I have my primary key (with no expiry) stored on a > offline drive. > I created the key 1 year ago, alongside a set of subkeys whose expiry > was due in 1 year. > Since they recently expired, I created another triplet of subkeys (sign, > author, encrypt) and started using them instead of the old ones. For signing git commits I recently created an OpenPGP key with a certify-only primary key (with long validity period) and a signing subkey (which expires next year). Encryption and authentication subkeys are useless for a commit signing key, but you may of course use your key also for other purposes. This commit signing key is certified with my main key. > Now, when I was doing this I realized that this strategy is not > particularly good, especially in the long run, > since you have to recreate every year (or 2) the new subkeys and let the > old ones expire (losing some trust?). "Trust" is usually bound to the primary key. Expired subkeys shouldn't matter. > Also, uploading the new keys to every website that you use (eg GitLab) > is quite the annoying chore. > > So, I was wondering what's the best strategy I can use to keep my > (sub)keys valid without compromising on security. > Is bumping the expiry date every year or so a better solution? You will still have to upload the updated key to every website you use. So, you don't gain much if anything with this approach. > Also, are subkeys with unlimited expiry bad, or am I just being carried > away? The advantage of an expiring key is that you can simply let it expire to make it invalid (for signatures created after the expiration date). On the other hand, if you don't lose access to the primary key, then you can still change the expiry of a subkey with unlimited validity if you decide to expire it. The downside of setting the expiration date in retrospect is that you need to send the updated key everywhere. And people may still use the outdated version without expiry. I'm going to experiment with 1-year-validity of the signing subkeys of my commit signing key. Since I use this key exclusively for commit signing, I can simply replace it with a completely different key if I change my mind. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From bosdan at protonmail.com Wed Oct 12 13:56:12 2022 From: bosdan at protonmail.com (Daniel Bossert) Date: Wed, 12 Oct 2022 11:56:12 +0000 Subject: Keysigining Party Switzerland/Zurich Message-ID: Hello everybody Sadly there doesn't seem to exist PGP Keysigning-partys anymore. Who of you would be interested in a such one around Zurich? Regards Daniel From bynect at gmail.com Thu Oct 13 11:39:41 2022 From: bynect at gmail.com (nect) Date: Thu, 13 Oct 2022 11:39:41 +0200 Subject: Subkeys renewing/expiring strategy In-Reply-To: <8171810.NyiUUSuA9g@daneel> References: <8171810.NyiUUSuA9g@daneel> Message-ID: Hello Ingo, Thank you for your reply. >You will still have to upload the updated key to every website you use. So, > you don't gain much if anything with this approach. You are totally right, I didn't think of that. In any case, this begs the question: is it better (best practice if you want) to have many expired subkeys in your keyring or constantly bumping the expiry date of one of your subkeys (without creating new ones every time)? > Encryption and authentication subkeys are useless for a commit > signing key, but you may of course use your key also for other purposes I made those just to be sure in case I will need them. Is it better to have authoring and encrypting subkeys with an unlimited expiry? Or is it better to not create them at all until you need them? >"Trust" is usually bound to the primary key. Expired subkeys shouldn't matter. Thank you for clarifying that. > Since I use this key exclusively for commit signing, I can > simply replace it with a completely different key if I change my mind. About this, how do you deal-or plan of dealing- with past commits signed with a now expired key? I created on year ago a test repo with only one commit, signed with my now expired subkey. Checking that commit's signature now shows an alert saying that the key is expired (in red). While this is correct, I guess that some users or services may see expired signatures as invalid, even though they are valid and I just superseded them with newer subkeys. I can think of two choices: either resign all your past commits every time your subkey expires, or ignore the fact that old commits were signed with expired subkeys. So, I was wondering if extending the expiry is the better way to deal with this, since you avoid showing any alert for old commits. Regards On Tue, Oct 11, 2022, 7:44 PM Ingo Kl?cker wrote: > On Dienstag, 11. Oktober 2022 17:23:49 CEST nect via Gnupg-users wrote: > > I started using gpg relatively recently (1 year or so), mainly for > > signing git commits, and I am far from mastering it. > > > > Since I was struggling to choose a strategy for expiring/renewing my > > subkeys (more details below) I decided to seek expert advice (hopefully > > this is the right place). > > I'm far from being an expert. > > > At the moment, I have my primary key (with no expiry) stored on a > > offline drive. > > I created the key 1 year ago, alongside a set of subkeys whose expiry > > was due in 1 year. > > Since they recently expired, I created another triplet of subkeys (sign, > > author, encrypt) and started using them instead of the old ones. > > For signing git commits I recently created an OpenPGP key with a > certify-only > primary key (with long validity period) and a signing subkey (which > expires > next year). Encryption and authentication subkeys are useless for a commit > signing key, but you may of course use your key also for other purposes. > > This commit signing key is certified with my main key. > > > Now, when I was doing this I realized that this strategy is not > > particularly good, especially in the long run, > > since you have to recreate every year (or 2) the new subkeys and let the > > old ones expire (losing some trust?). > > "Trust" is usually bound to the primary key. Expired subkeys shouldn't > matter. > > > Also, uploading the new keys to every website that you use (eg GitLab) > > is quite the annoying chore. > > > > So, I was wondering what's the best strategy I can use to keep my > > (sub)keys valid without compromising on security. > > Is bumping the expiry date every year or so a better solution? > > You will still have to upload the updated key to every website you use. > So, > you don't gain much if anything with this approach. > > > Also, are subkeys with unlimited expiry bad, or am I just being carried > > away? > > The advantage of an expiring key is that you can simply let it expire to > make > it invalid (for signatures created after the expiration date). On the > other > hand, if you don't lose access to the primary key, then you can still > change > the expiry of a subkey with unlimited validity if you decide to expire it. > The > downside of setting the expiration date in retrospect is that you need to > send > the updated key everywhere. And people may still use the outdated version > without expiry. > > I'm going to experiment with 1-year-validity of the signing subkeys of my > commit signing key. Since I use this key exclusively for commit signing, I > can > simply replace it with a completely different key if I change my mind. > > Regards, > Ingo > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > https://lists.gnupg.org/mailman/listinfo/gnupg-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlikonen at iki.fi Thu Oct 13 15:42:04 2022 From: tlikonen at iki.fi (Teemu Likonen) Date: Thu, 13 Oct 2022 16:42:04 +0300 Subject: Subkeys renewing/expiring strategy In-Reply-To: References: Message-ID: <87wn93lu1f.fsf@iki.fi> * 2022-10-11 17:23:49+0200, nect via Gnupg-users wrote: > Since I was struggling to choose a strategy for expiring/renewing my > subkeys [...] We should ask why do you want to expire (and rotate) your subkeys? Maybe you have good reasons but I'll remind of the basic question: why not use the default simple strategy? Keep secret keys secret so there is no need to rotate (sub)keys. Subkeys don't need expiry date at all. The primary key should (!) have expiry date which is updated as needed. That's it. No? -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 251 bytes Desc: not available URL: From kloecker at kde.org Thu Oct 13 19:05:33 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 13 Oct 2022 19:05:33 +0200 Subject: Subkeys renewing/expiring strategy In-Reply-To: References: <8171810.NyiUUSuA9g@daneel> Message-ID: <2123697.irdbgypaU6@daneel> On Donnerstag, 13. Oktober 2022 11:39:41 CEST nect via Gnupg-users wrote: > > Since I use this key exclusively for commit signing, I can > > simply replace it with a completely different key if I change my mind. > > About this, how do you deal-or plan of dealing- with past commits signed > with a now expired key? > I created on year ago a test repo with only one commit, signed with my now > expired subkey. > Checking that commit's signature now shows an alert saying that the key is > expired (in red). > While this is correct, I guess that some users or services may see expired > signatures as invalid, even though they are valid and I just superseded > them with newer subkeys. > I can think of two choices: either resign all your past commits every time > your subkey expires, I don't think that's an option (at least not for a repo shared with others) because it would rewrite the history of the git repo. > or ignore the fact that old commits were signed with > expired subkeys. > So, I was wondering if extending the expiry is the better way to deal with > this, since you avoid showing any alert for old commits. The best option is probably to follow Teemu's advice and use a signing subkey with unlimited validity. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From gnupg-users at spodhuis.org Thu Oct 13 23:50:33 2022 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Thu, 13 Oct 2022 17:50:33 -0400 Subject: WKD: conveying intent of encrypt-by-default? In-Reply-To: <87czb7xhpj.fsf@fifthhorseman.net> References: <87czb7xhpj.fsf@fifthhorseman.net> Message-ID: On 2022-10-04 at 20:00 -0400, Daniel Kahn Gillmor wrote: > Autocrypt's focus is ubiquitous deployment of keying material (in the > form of OpenPGP certificates) so that people *can* encrypt when sending > mail. We found that one of the big risks is that a peer might > *automatically* encrypt when a cert is available, which becomes > burdensome for a user who does not have the ability to easily decrypt > messages. We don't want burdened users to stop distributing their cert > entirely because of this annoyance or frustration. This. > Getting clients to respect this setting if published in WKD (or that the > lack of it means "do not encrypt by default") is an entirely different > subject, of course. And i know you said "no Protonmail rants" so i > won't call them out specifically here, but MUA developers generally > really do need to take the ecosystem effects of their choices seriously. > Any MUA that promiscuously encrypts *by default* to someone who has not > clearly indicated that they are comfortable with every inbound message > being encrypted is inviting that user to see encrypted e-mail as a > hindrance and an annoyance. That's not a great way to spread the > capability of people actually being able to use encrypted mail when it > matters, or to help people through a process of gradual adoption. Exactly this. We need encryption _available_, but culturally "encrypt-by-default" is not going to fly. Almost all email usage locally is Gmail, with the browser app or the official Gmail mobile apps. That is not going to change. We have to have a sensible means of key discovery for exchanging encrypted mail _when the situation warrants it_, such as distributing sensitive data or receiving security reports. This is not about signing. This is about using encrypted content being a PITA for most people. The clients encrypting all mail by default are killing the use of OpenPGP and MIME-integrated PGP-encrypted email locally. It's another hammer in the coffin-lid of PGP's reputation as a reasonable technical solution for the problem spaces we care about. It is not hyperbole to say that this one issue has done more to drive the use of "age" encryption (with copy/paste into and out of emails as intact ASCII-armored blobs) than anything else. And age armored ciphertext pasted into Slack. It might seem clunky, but it works reliably and it aligns with cultural expectation of "only use this for things which really need the protection, otherwise just rely upon TLS and professional service operators". TLS for SMTP is not end-to-end, but it turns out to be "good enough" for most daily usage, particularly within a domain or with a few business partners. -Phil From bosdan at protonmail.com Fri Oct 14 07:47:07 2022 From: bosdan at protonmail.com (Daniel Bossert) Date: Fri, 14 Oct 2022 05:47:07 +0000 Subject: WKD: conveying intent of encrypt-by-default? In-Reply-To: References: <87czb7xhpj.fsf@fifthhorseman.net> Message-ID: <5668e422-6493-b7c7-34a3-a879e99774d3@protonmail.com> Hello > Getting clients to respect this setting if published in WKD (or that the > lack of it means "do not encrypt by default") is an entirely different > subject, of course. And i know you said "no Protonmail rants" so i > won't call them out specifically here, but MUA developers generally > really do need to take the ecosystem effects of their choices seriously. > Any MUA that promiscuously encrypts *by default* to someone who has not > clearly indicated that they are comfortable with every inbound message > being encrypted is inviting that user to see encrypted e-mail as a > hindrance and an annoyance. That's not a great way to spread the > capability of people actually being able to use encrypted mail when it > matters, or to help people through a process of gradual adoption. Yes, I use protonmail, beside others. I opened an testaccount with mailbox.org, which offers you to encrypt all incoming messages with your public key if you specify it in the settings with their no-reply at mailbox.org private key. I have also tutanota, as it offers easily to send encrypted emails through an agreed password. Still searching the best way to go where I have all sent emails encrypted locally as well even they the mail to the receiver can't be encrypted. At which point are you willing to compromise? If course it is not ideal if proton has even the private key even without entering a passphrase for it. But they do it with the intention to get more encrypted mails on the transport. Oh dear I should meet you guys and discuss in person. Many questions around, I certainly do not best-practice but take it more and more easier this topic. If I allow mailbox.org to encrypt all my messages then i do so intentionally. protonmails are encrypted too, but I always see them cleartext as the pgp-stuff as handled in the background unknowingly to the user. > We have to have a sensible means of key discovery for exchanging > encrypted mail _when the situation warrants it_, such as distributing > sensitive data or receiving security reports. This is not about > signing. This is about using encrypted content being a PITA for most > people. Thunderbird has an autodiscovery feature to search for public keys. > It is not hyperbole to say that this one issue has done more to drive > and professional service operators". TLS for SMTP is not end-to-end, > but it turns out to be "good enough" for most daily usage, particularly > within a domain or with a few business partners. I just had cryptography in my bachelor and the teacher said the way to go is not TLS between servers as the mails still could be read. And that it's likely not gonna be implemented. Yes, right in the sense as the mail still can be read on the mailserver, but it would still help so they can't just get read. But first the servers should shut down TLS1.0/1.1; still too many with that protocol around. My two cents.. From 400thecat at gmx.ch Sat Oct 15 07:36:08 2022 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Sat, 15 Oct 2022 07:36:08 +0200 Subject: symmetric encryption of '[stdin]' failed Message-ID: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> Hello, I am trying to pipe output of tar command to gpg, and encrypt symmetrically: tar --zstd -cf - zz/ | gpg -c -o /tmp/zz.tar.zstd.gpg this fails with following errors: gpg: problem with the agent: Inappropriate ioctl for device gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of '[stdin]' failed: Operation cancelled The same command works when I change symmetric to public key encryption: tar --zstd -cf - zz/ | gpg -e -o /tmp/zz.tar.zstd.gpg Why does gpg-agent interject itself into symmetric encryption at all? What role does it want to play? Does it want to remember the passphrase? Anyways, how can I encrypt with symmetric when input comes from pipe? thank you, From rjh at sixdemonbag.org Sat Oct 15 14:36:40 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 15 Oct 2022 08:36:40 -0400 Subject: symmetric encryption of '[stdin]' failed In-Reply-To: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> References: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> Message-ID: > Why does gpg-agent interject itself into symmetric encryption at all? Where in that command line do you specify a passphrase? You don't. gpg-agent is getting fired up in order to ask you what passphrase to use for the symmetric encryption. From 400thecat at gmx.ch Sat Oct 15 16:37:36 2022 From: 400thecat at gmx.ch (Fourhundred Thecat) Date: Sat, 15 Oct 2022 16:37:36 +0200 Subject: symmetric encryption of '[stdin]' failed In-Reply-To: References: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> Message-ID: <6289a137-c254-da60-f2fb-154640c66868@gmx.ch> > On 15/10/2022 14.36, Robert J. Hansen via Gnupg-users wrote: >> Why does gpg-agent interject itself into symmetric encryption at all? > > Where in that command line do you specify a passphrase? > > You don't. > > gpg-agent is getting fired up in order to ask you what passphrase to use > for the symmetric encryption. why can't gpg accept passphrase in the terminal? Why does it need to start a daemon? gpg-agent is supposed to be used for managing private and public keys. At least that's what the man page says. Besides, when I use "gpg -c file", it works fine. I =get asked for passphrase (via pinentry, I think) so I am not sure what you mean by "Where in that command line do you specify a passphrase" From rjh at sixdemonbag.org Sat Oct 15 18:50:49 2022 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Sat, 15 Oct 2022 12:50:49 -0400 Subject: symmetric encryption of '[stdin]' failed In-Reply-To: <6289a137-c254-da60-f2fb-154640c66868@gmx.ch> References: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> <6289a137-c254-da60-f2fb-154640c66868@gmx.ch> Message-ID: > why can't gpg accept passphrase in the terminal? Depending on how you invoke GnuPG, it can. It supports a lot of different ways of providing the passphrase. The one that might work best for your purposes is to put the passphrase in a file, passphrase.txt, and then invoke GnuPG like this: gpg -c --pinentry-mode loopback --passphrase-file passphrase.txt -o [myfile].tar.zstd.gpg > Why does it need to start a daemon? Because GnuPG 2.x already starts the daemon. It should be running by the time you finish logging into your system. > Besides, when I use "gpg -c file", it works fine. I =get asked for > passphrase (via pinentry, I think) And what do you think launches pinentry? > so I am not sure what you mean by "Where in that command line do you > specify a passphrase" Really simple. Where in that command line did you specify a passphrase? You didn't tell GnuPG a passphrase file to use, a passphrase file descriptor to use, or an actual passphrase to use. So the only thing GnuPG could do was ask you for one, and that means using gpg-agent to facilitate the interaction with the user. From wk at gnupg.org Mon Oct 17 07:39:05 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Oct 2022 07:39:05 +0200 Subject: symmetric encryption of '[stdin]' failed In-Reply-To: (Robert J. Hansen via Gnupg-users's message of "Sat, 15 Oct 2022 12:50:49 -0400") References: <5e9460c3-7d60-c5db-5186-08c70e922423@gmx.ch> <6289a137-c254-da60-f2fb-154640c66868@gmx.ch> Message-ID: <875ygjf1qe.fsf@wheatstone.g10code.de> On Sat, 15 Oct 2022 12:50, Robert J. Hansen said: > Because GnuPG 2.x already starts the daemon. It should be running by > the time you finish logging into your system. Further the gpg-agent is responsible to compute the iteration count for our KDF. That takes at least 100ms and thus either a long running process needs to do that or we would need to store it somewhere with all the troubles to keep it in sync in case the GNUPGHOME is on shared drive (usually not a good idea but sometimes required) 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From wk at gnupg.org Mon Oct 17 09:43:56 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Oct 2022 09:43:56 +0200 Subject: [Announce] [CVE-2022-3515] GnuPG / Libksba Security Advisory Message-ID: <87v8oievyb.fsf@wheatstone.g10code.de> __________________________________________________ SECURITY ADVISORY FOR LIBKSBA/GNUPG (CVE-2022-3515) g10 Code GmbH __________________________________________________ 2022-10-17 Integer Overflow in LibKSBA / GnuPG =================================== A severe bug has been found in [Libksba] , the library used by GnuPG for parsing the ASN.1 structures as used by S/MIME. The bug affects all versions of [Libksba] before 1.6.2 and may be used for remote code execution. *Updating this library is thus important*. Who is affected ~~~~~~~~~~~~~~~ The major user of Libksba is /gpgsm/, the S/MIME cousin of /gpg/. There it is used to parse all kind of input data, in particular signed or encrypted data in files or in mails. Feeding a user with malicious data can thus be easily achieved. A second user of Libksba is /dirmngr/, which is responsible for loading and parsing Certificate Revocation Lists (CRLs) and for verifying certificates used by TLS (i.e. https connections). Mounting an attack is a bit more complex but can anyway be easily done using a rogue web server to serve a Web Key Directory, certificates, or CRLs. An exploit is not yet publicly known but very straightforward to create for experienced crooks. Affected to our knowledge are: - Most software using /Libksba/ versions up to 1.6.1 - All /Gpg4win/ versions from version 2.0.0 up to 4.0.3 - All /GnuPG VS-Desktop/ versions from 3.1.16 up to 3.1.24 - All /GnuPG installers for Windows/ from version 2.3.0 up to 2.3.7 - All /GnuPG LTS installers for Windows/ from version 2.1.0 up to 2.2.39 How to fix ~~~~~~~~~~ If you are on a Unix or Linux system you should get the latest version of Libksba (1.6.2 or newer), build the software and install the new shared library. Restart any background processes (e.g. `gpgconf --kill all' for GnuPG). In the rare case that Libksba is statically linked remember to rebuild those binaries. If your are on Windows or if you use an AppImage of GnuPG VS-Desktop update to the latest version: - Gpgwin version 4.0.4 or newer - GnuPG VS-Desktop version 3.1.25 or newer (MSI or AppImage) - GnuPG installer for Windows version 2.3.8 - GnuPG LTS installer for Windows version 2.2.40 In case you are not yet ready to deploy a new version, please extract `libksba-8.dll' from the respective package and replace the original one by this one. This is sufficient to fix the security issue. See https://gnupg.org/download for links to the latest packages. For Gpg4win see https://gpg4win.org How to check whether GnuPG has been fixed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ GnuPG is the most prominent user of Libksba and it is not immediately visible whether a fixed version of Libksba is used. To check this run: ,---- | gpgconf --show-versions `---- and watch out for a line like ,---- | * KSBA 1.6.2 (xxxxx) `---- If you see a version number of 1.6.2 or newer, you got the fix. CVE ~~~ GnuPG-bug-id: 6230 (https://dev.gnupg.org/T6230) CVE ........: CVE-2022-3515 CVSS .......: 8.1: AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H Other-IDs ..: ZDI-CAN-18927, ZDI-CAN-18928, ZDI-CAN-18927 CVSS taken from the Trend Micro Zero Day Initiative report. Technical background ==================== The task of Libksba is to parse and build ASN.1 objects as used by S/MIME, X.509, and CMS. The used encoding (BER, DER) is based on tag-length-value objects. The function /_ksba_ber_read_tl/ parses such data and returns the tag and associated information in this structure: ,---- | struct tag_info { | enum tag_class class; | int is_constructed; | unsigned long tag; | unsigned long length; /* Length part of the TLV */ | int ndef; /* It is an indefinite length */ | size_t nhdr; /* Number of bytes in the TL */ | unsigned char buf[10]; /* Buffer for the TL */ | const char *err_string; | int non_der; | }; `---- At several places we need to copy the objects to a local buffer. For example we copy OIDs to a statically encoded buffer for further processing: ,---- | struct tag_info ti; | unsigned char tmpbuf[500]; /* for OID or algorithmIdentifier */ | [...] | if (ti.nhdr + ti.length >= DIM(tmpbuf)) | return gpg_error (GPG_ERR_TOO_LARGE); | memcpy (tmpbuf, ti.buf, ti.nhdr); | err = read_buffer (crl->reader, tmpbuf+ti.nhdr, ti.length); `---- It is obvious that the sum of the header length (although less than 10 bytes) and the announced length of the value can easily wrap around and pass the check. The result is then an overflow of /tmpbuf/ with all the usual consequences. The code has been there for ages and it seems that the audits missed this because, well, there is some overflow check and a too brief check may have only noticed that the memcpy if fine. The fix for this is easy because we can check for an overflow right away in the parser. Thus /_ksba_ber_read_tl/ finally does this extra check: ,---- | if (ti->length > ti->nhdr && (ti->nhdr + ti->length) < ti->length) | { | ti->err_string = "header+length would overflow"; | return gpg_error (GPG_ERR_EOVERFLOW); | } `---- Thanks ~~~~~~ This vulnerability was discovered by: Anonymous working with Trend Micro Zero Day Initiative The report was received on 2022-10-04, fix pushed 2022-10-05, new source code release 2002-10-07, binary releases and announcement on 2022-10-17. [Libksba] https://gnupg.org/software/libksba/ -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 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 wk at gnupg.org Mon Oct 17 14:58:22 2022 From: wk at gnupg.org (Werner Koch) Date: Mon, 17 Oct 2022 14:58:22 +0200 Subject: [Announce] GnuPG 2.3.8 released Message-ID: <87h702ehe9.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: version 2.3.8. This release comes with a lot of new features and the binary releases come with the fix for the Libksba vulnerability CVE-2022-3515 (https://gnupg.org/blog/20221017-pepe-left-the-ksba.html). 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. Three different series of GnuPG are actively maintained: - Version 2.3 is the current stable version with a lot of new features compared to 2.2. This announcement is about the latest release of this series. - Version 2.2 is our LTS (long term support) version and guaranteed to be maintained at least until the end of 2024. Only a small subset of features from 2.3 has been back-ported to this series. See https://gnupg.org/download/index.html#end-of-life - Version 1.4 is only maintained to allow decryption of very old data which is, for security reasons, not anymore possible with other GnuPG versions. Noteworthy changes in version 2.3.8 =================================== * gpg: Do not consider unknown public keys as non-compliant while decrypting. [T6205] * gpg: Avoid to emit a compliance mode line if Libgcrypt is non-compliant. [T6221] * gpg: Improve --edit-key setpref command to ease c+p. [rG1908fa8b83] * gpg: Emit an ERROR status if --quick-set-primary-uid fails and allow to pass the user ID by hash. [T6126] * gpg: Actually show symmetric+pubkey encrypted data as de-vs compliant. Add extra compliance checks for symkey_enc packets. [T6119] * gpg: In de-vs mode use SHA-256 instead of SHA-1 as implicit preference. [T6043] * gpgsm: Fix reporting of bad passphrase error during PKCS#11 import. [T5713,T6037] * agent: Fix a regression in "READKEY --format=ssh". [T6012] * agent: New option --need-attr for KEYINFO. [rG989eae648c] * agent: New attribute "Remote-list" for use by KEYINFO. [r1383aa4750] * scd: Fix problem with Yubikey 5.4 firmware. [T6070] * dirmngr: Fix CRL Distribution Point fallback to other schemes. [rG0c8299e2b5] * dirmngr: New LDAP server flag "areconly" (A-record-only). [rGd65a0335e5] * dirmngr: Fix upload of multiple keys for an LDAP server specified using the colon format. [rG536b5cd663] * dirmngr: Use LDAP schema v2 when a Base DN is specified. [T6047] * dirmngr: Avoid caching expired certificates. [T6142] * wkd: Fix path traversal attack in gpg-wks-server. Add the mail address to the pending request data. [rG8a63a8c825,T6098] * wkd: New command --mirror for gpg-wks-client. [T6224] * gpg-auth: New tool for authentication. [T5862] * New common.conf option no-autostart. [rG203dcc19eb] * Silence warnings from AllowSetForegroundWindow unless GNUPG_EXEC_DEBUG_FLAGS is used. [rG4ef8516a79] Release-info: https://dev.gnupg.org/T6106 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 FTP 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.3.8.tar.bz2 (7465k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.3.8.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.3.8_20221013.exe (4797k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.3.8_20221013.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new release of Gpg4win (version 4.0.4) including this version of GnuPG is available at https://gpg4win.org We will shortly announce a Linux AppImage of this version featuring Kleopatra as graphical user interface. 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.3.8.tar.bz2 you would use this command: gpg --verify gnupg-2.3.8.tar.bz2.sig gnupg-2.3.8.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.3.8.tar.bz2, you run the command like this: sha1sum gnupg-2.3.8.tar.bz2 and check that the output matches the next line: 1f31b7b4c9c9adad97f94ea3acf1aa64c0424bcc gnupg-2.3.8.tar.bz2 014aa20eb1ac677736d0c2e056adc55304e12679 gnupg-w32-2.3.8_20221013.tar.xz 6cfabadbaf15a27988a11e811e9eabb20077b4ff gnupg-w32-2.3.8_20221013.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, 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/T6106 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. Three full-time employed developers as well as two contractors exclusively work on GnuPG and closely related software like Libgcrypt, GPGME and Gpg4win. Fortunately, and this is still not common with free software, we have now 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 trademark 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 helping 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: rsa3072 2017-03-17 [expires: 2027-03-15] 5B80 C575 4298 F0CB 55D8 ED6A BCEF 7E29 4B09 2E28 Andre Heinecke (Release Signing Key) ed25519 2020-08-24 [expires: 2030-06-30] 6DAA 6E64 A76D 2840 571B 4902 5288 97B8 2640 3ADA Werner Koch (dist signing 2020) ed25519 2021-05-19 [expires: 2027-04-04] AC8E 115B F73E 2D8D 47FA 9908 E98E 9B2D 19C6 C8BD Niibe Yutaka (GnuPG Release Key) brainpoolP256r1 2021-10-15 [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. -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 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 vesely at tana.it Tue Oct 18 08:59:50 2022 From: vesely at tana.it (Alessandro Vesely) Date: Tue, 18 Oct 2022 08:59:50 +0200 Subject: [Announce] [CVE-2022-3515] GnuPG / Libksba Security Advisory In-Reply-To: <87v8oievyb.fsf@wheatstone.g10code.de> References: <87v8oievyb.fsf@wheatstone.g10code.de> Message-ID: <9e75ae0b-7f67-9f7f-8885-1e7e6b4aee9e@tana.it> On Mon 17/Oct/2022 09:43:56 +0200 Werner Koch via Gnupg-users wrote: > How to check whether GnuPG has been fixed > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > GnuPG is the most prominent user of Libksba and it is not immediately > visible whether a fixed version of Libksba is used. To check this run: > > ,---- > | gpgconf --show-versions > `---- > > and watch out for a line like > > ,---- > | * KSBA 1.6.2 (xxxxx) > `---- > > If you see a version number of 1.6.2 or newer, you got the fix. Debian fix kept the old version number 1.5.0-3, though: -------- Forwarded Message -------- Subject: [SECURITY] [DSA 5255-1] libksba security update Resent-Date: Mon, 17 Oct 2022 20:13:43 +0000 (UTC) Resent-From: debian-security-announce at lists.debian.org Date: Mon, 17 Oct 2022 20:13:16 +0000 From: Salvatore Bonaccorso Reply-To: debian-security-announce-request at lists.debian.org To: debian-security-announce at lists.debian.org ------------------------------------------------------------------------- Debian Security Advisory DSA-5255-1 security at debian.org https://www.debian.org/security/ Salvatore Bonaccorso October 17, 2022 https://www.debian.org/security/faq ------------------------------------------------------------------------- Package : libksba CVE ID : CVE-2022-3515 Debian Bug : 1021928 An integer overflow flaw was discovered in the CRL parser in libksba, an X.509 and CMS support library, which could result in denial of service or the execution of arbitrary code. Details can be found in the upstream advisory at https://gnupg.org/blog/20221017-pepe-left-the-ksba.html For the stable distribution (bullseye), this problem has been fixed in version 1.5.0-3+deb11u1. We recommend that you upgrade your libksba packages. For the detailed security status of libksba please refer to its security tracker page at: https://security-tracker.debian.org/tracker/libksba Further information about Debian Security Advisories, how to apply these updates to your system and frequently asked questions can be found at: https://www.debian.org/security/ Mailing list: debian-security-announce at lists.debian.org From wk at gnupg.org Tue Oct 18 09:55:12 2022 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Oct 2022 09:55:12 +0200 Subject: [Announce] [CVE-2022-3515] GnuPG / Libksba Security Advisory In-Reply-To: <9e75ae0b-7f67-9f7f-8885-1e7e6b4aee9e@tana.it> (Alessandro Vesely via Gnupg-users's message of "Tue, 18 Oct 2022 08:59:50 +0200") References: <87v8oievyb.fsf@wheatstone.g10code.de> <9e75ae0b-7f67-9f7f-8885-1e7e6b4aee9e@tana.it> Message-ID: <87h701d0rj.fsf@wheatstone.g10code.de> On Tue, 18 Oct 2022 08:59, Alessandro Vesely said: > Debian fix kept the old version number 1.5.0-3, though: FWIW: Debian thus misses * Allow an OCSP server not to return the sent nonce. [rK24992a4a7a] * Limited support for the Authenticated-Enveloped-Data content type. [rK81fdcd680c12] * Support password based decryption. [rKcb7f2484a09c] * Support Brainpool curves specified by ECDomainParameters. All of them fixes practical problems found in the real world. 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ralph at ml.seichter.de Tue Oct 18 08:51:26 2022 From: ralph at ml.seichter.de (Ralph Seichter) Date: Tue, 18 Oct 2022 08:51:26 +0200 Subject: [Announce] GnuPG for OS X 2.3.8 released Message-ID: <87o7u98w0h.fsf@ra.horus-it.com> GnuPG for OS X / macOS release 2.3.8 is now available for download via https://sourceforge.net/p/gpgosx/docu/Download/ . The disk image signature key was uploaded to keyservers in July 2022 and should now be widely available. It can also be downloaded using the URL https://www.seichter.de/pgp/gpgosx-signing.asc . pub ed25519/FD56297D9833FF7F 2022-07-07 [SC] [expires: 2027-07-06] Key fingerprint = EAB0 FE4F F793 D9E7 028E C8E2 FD56 297D 9833 FF7F uid [ultimate] Ralph Seichter (GnuPG for OS X signing key) Important: GnuPG 2.3.x is installed in /usr/local/gnupg-2.3 instead of the previously hardcoded directory /usr/local/gnupg-2.2. This enables installing both stable and LTS releases of GnuPG for OS X side by side, for advanced users' needs. The one caveat is that the latest installation will replace existing soft links in /usr/local/{bin,lib}. Please use absolute paths like /usr/local/gnupg-2.2/bin/gpg2 if necessary. -Ralph From wk at gnupg.org Fri Oct 21 08:57:59 2022 From: wk at gnupg.org (Werner Koch) Date: Fri, 21 Oct 2022 08:57:59 +0200 Subject: AppImage of GnuPG 2.3.8 Message-ID: <87tu3xacjs.fsf@wheatstone.g10code.de> Hello! For the first time we published an AppImage of GnuPG along with Kleopatra as its GUI. An AppImage may be used on any Linux version without the need to build new libraries and to remove the GnuPG already installed on the system. It comes with the latest libraries and is useful to try out new feature or to use a modern GnuPG if your system only provides the LTS version of GnuPG. This AppImage is named /GnuPG Desktop?/ and should give you a similar experience as users of /Gpg4win/. In fact the source code is currently nearly identical. If you want to build your own version see the README in the source tarball and please take care to remove our trademarked name. Links can be found at https://gnupg.org or here: https://download.gnupg.com/files/gnupg/gnupg-desktop-2.3.8.0-x86_64.AppImage https://download.gnupg.com/files/gnupg/gnupg-desktop-2.3.8.0-x86_64.AppImage.sig Please download both files, make sure that the App9mage is executable ("chmod +x gnupg-desktop-2.3.8.0-x86_64.AppImage" if not), check the signature as usual or compare the sha1sum: 7651072d7cecedb38b55c533544507b73e770934 gnupg-desktop-2.3.8.0-x86_64.AppImage After that you may run it: ./gnupg-desktop-2.3.8.0-x86_64.AppImage will start the GUI ./gnupg-desktop-2.3.8.0-x86_64.AppImage -c will drop you in a shell where you can use this version of GnuPG on the command line, start the GUI by running "kleopatra", or use a mail client which then should pick up the new gpg. You may also use --help or --version. For closer inspection of what is running in the AppImage, give a "cd $APPDIR" and look around. There are certainly some inconsistencies like Gpg4win version numbers etc but, we will fix that over time. Note that the AppImage takes over any running gpg-agent but that should in general not be a problem because all gpg-agent's are upward compatible. If you need to start another AppImage while the first is still running, you may want to use the option --keep-socket. To detect whether you are running a GnuPG AppImage test for the environment variable "_gnupg_appimage". In case you want to use option which are only available in gnupg 2.3.8 you either need to use a separate GNUPGHOME like in GNUPGHOME=/home/foo/mygpg23 ./gnupg-desktop-2.3.8.0-x86_64.AppImage of you can use in all configuration files the meat option "ignore-invalid-option". For example ignore-invalid-option crazy-new-option another-new-option which won't error out of one of these options is used but not supported. If you are system installed version of gnupg is at lease 2.2.26 you may also use a construct like [if $_version -v3ge 2.3.8] no-user-trustlist [fi] If a GnuPG 2.3 version is already installed on your system and you want to have a different configuration for the AppImage you may use [getenv appimage _gnupg_appimage] [if $appimage] # Options for the Appimage [fi] in your configuration files. To see what configuration files are read you may invoke gpg with "--debug 0". 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: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From guru at unixarea.de Fri Oct 21 11:20:13 2022 From: guru at unixarea.de (Matthias Apitz) Date: Fri, 21 Oct 2022 11:20:13 +0200 Subject: GnuPG on Macbook Pro Message-ID: Hello, In the company I'm working for I can't use anymore a Virtual Machine with FreeBSD and had to elect between Win and a Macbook Pro. No need to discuss this further. I'm actively used to use GnuPG on all my private FreeBSD and L5 mobile devices. Can I use GnuPG (and passwordstore, the latter is only a shell script) on Mac? The shell looks nearly like a normal Linux system (behind a colorful desktop) and the kernel is this: $ uname -a Darwin APITZM-1MBPOH 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:20:07 PDT 2022; root:xnu-8020.140.49~2/RELEASE_ARM64_T8110 arm64 also a compiler seems to be installed: $ gcc -v Apple clang version 14.0.0 (clang-1400.0.29.102) Target: arm64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin Any hints are welcome. Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub From ralph at ml.seichter.de Fri Oct 21 11:30:46 2022 From: ralph at ml.seichter.de (Ralph Seichter) Date: Fri, 21 Oct 2022 11:30:46 +0200 Subject: GnuPG on Macbook Pro In-Reply-To: References: Message-ID: <87edv1bk1l.fsf@ra.horus-it.com> * Matthias Apitz: > Can I use GnuPG (and passwordstore, the latter is only a shell > script) on Mac? The shell looks nearly like a normal Linux system https://sourceforge.net/projects/gpgosx/ should do the trick. I use it on all my Macs (High Sierra and newer versions), and it integrates with the macOS Keychain application, if you so desire. -Ralph From dclarke at blastwave.org Sat Oct 22 19:12:23 2022 From: dclarke at blastwave.org (Dennis Clarke) Date: Sat, 22 Oct 2022 17:12:23 +0000 Subject: Problem regarding dirmngr on Debian stable Message-ID: <12c7fe94-964c-acc1-0b33-0b74601b32d9@blastwave.org> Good day. I saw that the version of GnuPG on Debian stable was not really up to date and thus decided to build my own local copy from recent sources. This went really well and I end up with : $ uname -a Linux styx 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux $ $ which gpg /home/dclarke/local/bin/gpg $ $ gpg --version gpg (GnuPG) 2.3.8 libgcrypt 1.10.1 Copyright (C) 2021 Free Software Foundation, Inc. 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/dclarke/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 AEAD: EAX, OCB Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2 $ I was careful to ensure the linker set RUNPATH to a correct location : $ readelf -delV $HOME/local/bin/gpg | grep -E 'NEED|NAME|PATH' [ 8] .gnu.version_r VERNEED 0000000000004548 00004548 0x0000000000000001 (NEEDED) Shared library: [libz.so.1] 0x0000000000000001 (NEEDED) Shared library: [libbz2.so.1.0] 0x0000000000000001 (NEEDED) Shared library: [libgcrypt.so.20] 0x0000000000000001 (NEEDED) Shared library: [libgpg-error.so.0] 0x0000000000000001 (NEEDED) Shared library: [libassuan.so.0] 0x0000000000000001 (NEEDED) Shared library: [libnpth.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0] 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000001d (RUNPATH) Library runpath: [/home/dclarke/local/lib] 0x000000006ffffffe (VERNEED) 0x4548 0x000000006fffffff (VERNEEDNUM) 6 $ $ ls /home/dclarke/local/lib/libgpg-error.so.0* /home/dclarke/local/lib/libgpg-error.so.0 /home/dclarke/local/lib/libgpg-error.so.0.33.1 $ readelf -delV $HOME/local/lib/libgpg-error.so.0.33.1 | grep -E 'NEED|NAME|PATH' [ 7] .gnu.version_r VERNEED 0000000000003068 00003068 0x0000000000000001 (NEEDED) Shared library: [libc.so.6] 0x000000000000000e (SONAME) Library soname: [libgpg-error.so.0] 0x000000000000001d (RUNPATH) Library runpath: [/home/dclarke/local/lib] 0x000000006ffffffe (VERNEED) 0x3068 0x000000006fffffff (VERNEEDNUM) 1 $ Also I did configure with --enable-all-tests and the test suite ran perfectly. However I see messages about some dirmngr issue : $ $ gpg --keyserver pgp.mit.edu --search-keys blah-blah-blah-keyid gpg: WARNING: server 'dirmngr' is older than us (2.2.27 < 2.3.8) gpg: Note: Outdated servers may lack important security fixes. gpg: Note: Use the command "gpgconf --kill all" to restart them. gpg: data source .... There is no dirmngr binary on this machine anywhere. $ su - Password: styx# styx# cd /usr styx# find . -type f | grep 'dirmngr' | wc -l 0 styx# Why am I seeing this strange message ? -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional From sp_xie at yahoo.com Sun Oct 23 14:58:37 2022 From: sp_xie at yahoo.com (Shaoping Xie) Date: Sun, 23 Oct 2022 12:58:37 +0000 (UTC) Subject: Fw: GPG problem In-Reply-To: <1095c59037b540339509c32ea66c8388@wexmbnyc507.corp.oproot.opco.com> References: <1095c59037b540339509c32ea66c8388@wexmbnyc507.corp.oproot.opco.com> Message-ID: <1231331993.1269522.1666529917996@mail.yahoo.com> Good Morning Everyone, ? I have recently been working on a new Linux system with GPG 2.2.20. ? I have had no problem generating the key pair. Then I have used the new public key to encrypt a file without problem. However, the decryption attempt has failed due to no secret key error. ? I have tried to look around for an answer and fix but failed. ? I was puzzled at the output from ?gpg ?export-secret-key?. ? I have posted all the related information at inline text attachement. ? Any help for clue and fix will be greatly appreciated. ? Thank you, Shaoping ? ? ? (sfgadmin at nyvmapc20)> sx_DecryptionCML TestFile01.pgp The decrypted file is name by default as ./TestFile01 gpg: encrypted with 4096-bit RSA key, ID 8E39ACE53BF145A8, created 2022-10-21 ????? "GFDS OpCo (OpCo PROD PGP KEY) " gpg: public key decryption failed: Permission denied gpg: decryption failed: No secret key TestFile01.pgp has failed to be decrypted as ./TestFile01 Please log on the account of? and check the process. Aborting... (sfgadmin at nyvmapc20)> gpg --version gpg (GnuPG) 2.2.20 libgcrypt 1.8.5 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 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: /export/home/sfgadmin/.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 ? ? ? (sfgadmin at nyvmapc20)> cd .gnupg (sfgadmin at nyvmapc20)> ls -al * -rw-rw-r--. 1 sfgadmin sfgadmin 3147 Oct 20 23:26 OpCoProd_PGP_PublicKey.20221020.asc -rw-rw-r--. 1 sfgadmin sfgadmin 2487 Oct 20 22:10 pubring.kbx -rw-------. 1 sfgadmin sfgadmin?? 32 Oct 20 22:07 pubring.kbx~ -rw-------. 1 sfgadmin sfgadmin? 600 Oct 21 21:14 random_seed srwx------. 1 sfgadmin sfgadmin??? 0 Oct 22 04:52 S.gpg-agent srwx------. 1 sfgadmin sfgadmin??? 0 Oct 21 22:28 S.gpg-agent.browser srwx------. 1 sfgadmin sfgadmin??? 0 Oct 21 22:28 S.gpg-agent.extra srwx------. 1 sfgadmin sfgadmin??? 0 Oct 21 22:28 S.gpg-agent.ssh -rw-------. 1 sfgadmin sfgadmin 1280 Oct 20 22:11 trustdb.gpg ? openpgp-revocs.d: total 8 drwx------. 2 sfgadmin sfgadmin?? 58 Oct 20 22:10 . drwx------. 4 sfgadmin sfgadmin 4096 Oct 22 05:11 .. -rw-------. 1 sfgadmin sfgadmin 1798 Oct 20 22:10 A920E42C97EB0173F8A98A8B0209E20DD685B6D1.rev ? private-keys-v1.d: total 12 drwx------. 2 sfgadmin sfgadmin? 110 Oct 20 22:10 . drwx------. 4 sfgadmin sfgadmin 4096 Oct 22 05:11 .. -rw-------. 1 sfgadmin sfgadmin 2055 Oct 20 22:10 81E9A09A83A2D4F254194177446787C9D5269569.key -rw-------. 1 sfgadmin sfgadmin 2071 Oct 20 22:10 F5EB2EBCDEDCB08B4DC1468F473DDFAF3A2A28C0.key ? ? ? (sfgadmin at nyvmapc20)> gpg --list-secret-keys /export/home/sfgadmin/.gnupg/pubring.kbx ---------------------------------------- sec?? rsa4096 2022-10-21 [SC] ????? A920E42C97EB0173F8A98A8B0209E20DD685B6D1 uid?????????? [ultimate] GFDS OpCo (OpCo PROD PGP KEY) ssb?? rsa4096 2022-10-21 [E] ? (sfgadmin at nyvmapc20)> gpg --list-keys /export/home/sfgadmin/.gnupg/pubring.kbx ---------------------------------------- pub?? rsa4096 2022-10-21 [SC] ????? A920E42C97EB0173F8A98A8B0209E20DD685B6D1 uid?????????? [ultimate] GFDS OpCo (OpCo PROD PGP KEY) sub?? rsa4096 2022-10-21 [E] ? ? (sfgadmin at nyvmapc20)> gpg --export-secret-key gpg: key 81E9A09A83A2D4F254194177446787C9D5269569: error receiving key from agent: Permission denied - skipped gpg: key F5EB2EBCDEDCB08B4DC1468F473DDFAF3A2A28C0: error receiving key from agent: Permission denied - skipped gpg: WARNING: nothing exported ? ? This communication and any attached files may contain information that is confidential or privileged. If this communication has been received in error, please delete or destroy it immediately. Please go to www.oppenheimer.com/legal/email-disclosure.aspx for important information and further disclosures pertaining to this transmission. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Sun Oct 23 19:13:19 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 23 Oct 2022 19:13:19 +0200 Subject: Problem regarding dirmngr on Debian stable In-Reply-To: <12c7fe94-964c-acc1-0b33-0b74601b32d9@blastwave.org> References: <12c7fe94-964c-acc1-0b33-0b74601b32d9@blastwave.org> Message-ID: <4781147.31r3eYUQgx@breq> On Samstag, 22. Oktober 2022 19:12:23 CEST Dennis Clarke via Gnupg-users wrote: > I saw that the version of GnuPG on Debian stable was not really up > to date and thus decided to build my own local copy from recent sources. [...] > $ gpg --keyserver pgp.mit.edu --search-keys blah-blah-blah-keyid > gpg: WARNING: server 'dirmngr' is older than us (2.2.27 < 2.3.8) > gpg: Note: Outdated servers may lack important security fixes. > gpg: Note: Use the command "gpgconf --kill all" to restart them. > gpg: data source .... > > There is no dirmngr binary on this machine anywhere. /usr/bin/dirmngr is part of the dirmngr package on Debian stable. https://packages.debian.org/search?searchon=contents&keywords=dirmngr&mode=path&suite=stable&arch=any > Why am I seeing this strange message ? Did you check whether there is an old dirmngr still running? Did you run `gpgconf --kill all` as recommended by the above message? Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From bernhard at intevation.de Mon Oct 24 17:29:51 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Mon, 24 Oct 2022 17:29:51 +0200 Subject: GPG problem In-Reply-To: <1231331993.1269522.1666529917996@mail.yahoo.com> References: <1095c59037b540339509c32ea66c8388@wexmbnyc507.corp.oproot.opco.com> <1231331993.1269522.1666529917996@mail.yahoo.com> Message-ID: <202210241729.52379.bernhard@intevation.de> Hello Shaoping Xie, > gpg: public key decryption failed: Permission denied if your keypair has a passphrase set, did an interactive pinentry come up? (If you want to run unattended, one method is to not set a passphrase and secure the system accordingly.) > I was puzzled at the output from ?gpg ?export-secret-key?. Probably the same problem. 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 sp_xie at yahoo.com Mon Oct 24 23:21:11 2022 From: sp_xie at yahoo.com (Shaoping Xie) Date: Mon, 24 Oct 2022 21:21:11 +0000 (UTC) Subject: GPG problem In-Reply-To: <202210241729.52379.bernhard@intevation.de> References: <1095c59037b540339509c32ea66c8388@wexmbnyc507.corp.oproot.opco.com> <1231331993.1269522.1666529917996@mail.yahoo.com> <202210241729.52379.bernhard@intevation.de> Message-ID: <1657520639.1603821.1666646471527@mail.yahoo.com> Hi Bernhard, ? ? It seems that the problem was caused by "sudo su":????? ? For some reason on Linux Redhad 8, "sodu su" does not behave as in the earlier version. ????????? ? There is no difference between "sudo su - XYZ" and "sudo su XYZ". ? ? Actually, I failed to generate the key pair when I logged on the system and then sudo-ed su to the working ID. I had to log on the system as the working ID to generate the key pair successfully. ? ? Again, I had to decrypt the files by logging on the system as the working ID. ? ? The behavior of sudo in Redhad 8 may be due to some configuration issues. ? ? Thank you for reply!? ? Shaoping ? On Monday, October 24, 2022 at 11:29:58 AM EDT, Bernhard Reiter wrote: Hello Shaoping Xie, > gpg: public key decryption failed: Permission denied if your keypair has a passphrase set, did an interactive pinentry come up? (If you want to run unattended, one method is to not set a passphrase and secure the system accordingly.) > I was puzzled at the output from ?gpg ?export-secret-key?. Probably the same problem. 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 -------------- An HTML attachment was scrubbed... URL: From bernhard at intevation.de Tue Oct 25 09:24:16 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 09:24:16 +0200 Subject: Debian Packages for [CVE-2022-3515] GnuPG / Libksba Security Advisory In-Reply-To: <87h701d0rj.fsf@wheatstone.g10code.de> References: <87v8oievyb.fsf@wheatstone.g10code.de> <9e75ae0b-7f67-9f7f-8885-1e7e6b4aee9e@tana.it> <87h701d0rj.fsf@wheatstone.g10code.de> Message-ID: <202210250924.33539.bernhard@intevation.de> Am Dienstag 18 Oktober 2022 09:55:12 schrieb Werner Koch via Gnupg-users: > On Tue, 18 Oct 2022 08:59, Alessandro Vesely said: > > > If you see a version number of 1.6.2 or newer, you got the fix. > > Debian fix kept the old version number 1.5.0-3, though: The libksba8 debian packages for Buster and Bullseye are 1.3.5-2+deb10u1 1.5.0-3+deb11u1 and yes, the proposed check with gpgconf --show-versions is not a test for Debian, check the package version instead. > FWIW: Debian thus misses For the upcoming version Debian of course has 1.6.2-3 and thus gets the new features. Thanks to the maintainers (Andres Metzler and Markus Koschany did the uploads). *wave* See https://security-tracker.debian.org/tracker/CVE-2022-3515 It seems Debian was quite fast to react. :) 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 Tue Oct 25 09:39:04 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 09:39:04 +0200 Subject: Subkeys renewing/expiring strategy In-Reply-To: <87wn93lu1f.fsf@iki.fi> References: <87wn93lu1f.fsf@iki.fi> Message-ID: <202210250939.18125.bernhard@intevation.de> Am Donnerstag 13 Oktober 2022 15:42:04 schrieb Teemu Likonen: > * 2022-10-11 17:23:49+0200, nect via Gnupg-users wrote: > > Since I was struggling to choose a strategy for expiring/renewing my > > subkeys [...] > > We should ask why do you want to expire (and rotate) your subkeys? For encryption subkeys, rotating them adds a layer of protection. If this is worth the effort, you have to answer from your own perspective. To give a scenario or two: If an attacker gets access to a lot of old communication from you, they might be able to brute force an encryption key in the future. Or I maybe forced to give out an encryption key. Personally I have used a primary key with 10 years expiration and encryption subkeys with 2 years. It would only be a fifth of the communication that would be revealed. Also I could use stronger algorithms over the ten years, so it is not just a factor of five to crack, but much more. The effort was doable, but then again, I'm a regular crypto user and can use the exercise. ;) 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 Tue Oct 25 09:43:49 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 09:43:49 +0200 Subject: gpg-agent refuse to start In-Reply-To: References: Message-ID: <202210250943.49520.bernhard@intevation.de> Hi Christian, Am Donnerstag 06 Oktober 2022 21:01:15 schrieb Roy Christian (DAIT-SITL) via Gnupg-users: > Our applications called the GNUPG 1.4.2 executable and it worked without > issue. We upgraded to GNUPG version 2.2.27 and now we have problems with > the gpg-agent. This sometimes refuses to start. have you had a look at the questions I've asked you in reponse to your question in https://wald.intevation.org/forum/forum.php?thread_id=2474&forum_id=21&group_id=11 ? (It is fine to have this discussion here on the mailinglist.) 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 Tue Oct 25 09:57:55 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 09:57:55 +0200 Subject: email culture (Re: WKD: conveying intent of encrypt-by-default?) In-Reply-To: References: <87czb7xhpj.fsf@fifthhorseman.net> Message-ID: <202210250958.01405.bernhard@intevation.de> Am Donnerstag 13 Oktober 2022 23:50:33 schrieb Phil Pennock via Gnupg-users: > ?We need encryption _available_, but culturally > "encrypt-by-default" is not going to fly. In some cultures I hope (and guess) that it will fly. > Almost all email usage locally is Gmail, with the browser app or the > official Gmail mobile apps. ?That is not going to change. I wonder what could be done (in your local culture but also in other environments) to make reading encrypted emails better. E.g. have your users tried Mailvelope? https://mailvelope.com/en/ > This is about using encrypted content being a PITA for most > people. Somehow this shows how local and good native email clients could be better. As a long term email user a good email client makes me more productive and those clients can usually deal with encrypted email nicely (so it is not a hump at all, just a bit of setup once every few years). How could be get there for more people? 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 Tue Oct 25 10:21:06 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 10:21:06 +0200 Subject: How to clarity a deep technical issue (Re: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG) In-Reply-To: <20221001162319.7iIl1%steffen@sdaoden.eu> References: <20221001162319.7iIl1%steffen@sdaoden.eu> Message-ID: <202210251021.26848.bernhard@intevation.de> Hi Steffen, Am Samstag 01 Oktober 2022 18:23:19 schrieb Steffen Nurpmeso: > Highly disturbing to me are such poisoning emails like you write > continuously. please be respectful and try to assume best intentions. > The software you talk about is classified to be > used by governments to some extend, and i rather have Werner and > his team work on improving this big software suite than answering > mails The people doing certifications, just like all developers, inkluding me, you and Werner do make mistakes sometimes. And it is a good property of Free Software that everyone can inspect it. So I do not mind questions, even if they point out to unlikely defects. Yes, maybe not Werner should answer them, but someone else can help to outline what the next steps are to understand what the software is doing for someone who really wants to know. 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 Tue Oct 25 10:57:42 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 10:57:42 +0200 Subject: Understanding KDF for symmetric encryption (was: Seeking Assurance on Security and Memory Leaks in SuSE GnuPG) In-Reply-To: References: Message-ID: <202210251057.49713.bernhard@intevation.de> Hi Tony, one way to make progress (here on the mailinglist) is to split up unrelated topics into single issues, so everyone can dig deeper, if needed. From your posts I focus on the KDF for symmetric encryption. (I believe other concerns have been answered, at least I've seen answers, if not please open a seperate topic for each question.) Am Montag 03 Oktober 2022 18:45:48 schrieb Tony Lee via Gnupg-users: > Werner noted [for Count 1024] For backward compatibility reasons with > 1.4 the default count value is used in this case [and] You can't compare > some AES-KDF to the SHAl based KDF of OpenPGP. The --s2k options mention > "mangling passphrases" which sounds exactly like a KDF, but a default > SHA-1 was used in one case, at least. As a far as I've understood, using SHA1 hash in a KDF maybe okay (depending on other properties of the KDF). As mentioned by Werner, the KDF is calibrated dynamically by gpg-agent, did you check the bottom of https://gnupg.org/documentation/manuals/gnupg/Agent-Options.html (with --s2k-calibration and --s2k-count ) those have to be given to gpg-agent (e.g. in the gpg-agent.conf). If you want to increase the difficulty of the KDF used, my understanding is that a good option to use would be --s2k-calibration to gpg-agent. > The Spectra Secure YouTube was: > https://www.youtube.com/watch?v=j-qBChKG15Y "Password Managers: The Case > Against GNU pass (feat gpg)". Around minute 4:31 it explains very > clearly that the --s2k settings do not work (when exporting a key), In the video description, there is a link to https://dev.gnupg.org/T1800 which explains that being able to set a few parameters for the export of secret key material directly from gpg is a wish and not a defect. It maybe that the documentation could be improved on this point as however this would only be a minor thing in my view as gpg-agent does a dynamic calibration that sounds reasonable. However T1800 still says that --s2k-count works for symmetric encryption, see https://gnupg.org/documentation/manuals/gnupg/OpenPGP-Options.html#index-s2k_002dcount-1 if it does not, it would be a defect. It would be a minor one, if the default is gotten from gpg-agent (as stated) and gpg-agent gets it right. So you can start seeking evidence for it or the contrary, either by measurements or by following the code. Have you compared runs of gpg -c with different --s2k-count values?) Following the code usually works by building gnupg (its libraries and tools) and then start at main() with the handling of the arguments and possibly add some debugging printing or other method to see if you get to the point where the value is used or or. It should be possible for a software-engineer without deep knowlede of C. 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 christian.roy3 at retraitequebec.gouv.qc.ca Tue Oct 25 14:48:27 2022 From: christian.roy3 at retraitequebec.gouv.qc.ca (Roy Christian (DAIT-SITL)) Date: Tue, 25 Oct 2022 12:48:27 +0000 Subject: gpg-agent refuse to start In-Reply-To: <202210250943.49520.bernhard@intevation.de> References: <202210250943.49520.bernhard@intevation.de> Message-ID: Hi Bernhard, Thank you for your very comprehensive reply on the forum. It is very appreciated. I am still collecting information on the GNUPG problem. I hope to be able to come back to you with more information this week. Regards Christian Roy -----Message d'origine----- De?: Bernhard Reiter Envoy??: 25 octobre 2022 03:44 ??: gnupg-users at gnupg.org Cc?: Roy Christian (DAIT-SITL) Objet?: Re: gpg-agent refuse to start Hi Christian, Am Donnerstag 06 Oktober 2022 21:01:15 schrieb Roy Christian (DAIT-SITL) via Gnupg-users: > Our applications called the GNUPG 1.4.2 executable and it worked without > issue. We upgraded to GNUPG version 2.2.27 and now we have problems with > the gpg-agent. This sometimes refuses to start. have you had a look at the questions I've asked you in reponse to your question in https://wald.intevation.org/forum/forum.php?thread_id=2474&forum_id=21&group_id=11 ? (It is fine to have this discussion here on the mailinglist.) 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 From bernhard at intevation.de Tue Oct 25 17:16:10 2022 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 25 Oct 2022 17:16:10 +0200 Subject: mutt locking In-Reply-To: References: <87h70yhboo.fsf@wheatstone.g10code.de> Message-ID: <202210251716.10726.bernhard@intevation.de> Am Freitag 23 September 2022 18:19:42 schrieb Louis Holbrook via Gnupg-users: > - I would like to use pinentry-tty during my normal gpg cli operations. > - I am fine with using pinentry-curses in the mutt context > > Is there a way to do this? FWIW: Probably not, as the pinentry is a configuration of gpg-agent. In theory you could start a new gpg-agent with a different configuration option, but pinentry-curses really so bad? :) 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 accounts-gnupg at holbrook.no Tue Oct 25 17:31:50 2022 From: accounts-gnupg at holbrook.no (accounts-gnupg at holbrook.no) Date: Tue, 25 Oct 2022 16:31:50 +0100 Subject: mutt locking In-Reply-To: <202210251716.10726.bernhard@intevation.de> References: <87h70yhboo.fsf@wheatstone.g10code.de> <202210251716.10726.bernhard@intevation.de> Message-ID: It's not very bad in a curses environment, but I don't like that it clears out my terminal when I use it from the command line, and I do that a LOT. On Tue, Oct 25, 2022 at 05:16:10PM +0200, Bernhard Reiter wrote: > Am Freitag 23 September 2022 18:19:42 schrieb Louis Holbrook via Gnupg-users: > > - I would like to use pinentry-tty during my normal gpg cli operations. > > - I am fine with using pinentry-curses in the mutt context > > > > Is there a way to do this? > > FWIW: Probably not, as the pinentry is a configuration of gpg-agent. > In theory you could start a new gpg-agent with a different configuration > option, but pinentry-curses really so bad? :) > > 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: 488 bytes Desc: not available URL: From gnupg at raf.org Wed Oct 26 01:14:31 2022 From: gnupg at raf.org (raf) Date: Wed, 26 Oct 2022 10:14:31 +1100 Subject: mutt locking In-Reply-To: <202210251716.10726.bernhard@intevation.de> References: <87h70yhboo.fsf@wheatstone.g10code.de> <202210251716.10726.bernhard@intevation.de> Message-ID: On Tue, Oct 25, 2022 at 05:16:10PM +0200, Bernhard Reiter wrote: > Am Freitag 23 September 2022 18:19:42 schrieb Louis Holbrook via Gnupg-users: > > - I would like to use pinentry-tty during my normal gpg cli operations. > > - I am fine with using pinentry-curses in the mutt context > > > > Is there a way to do this? > > FWIW: Probably not, as the pinentry is a configuration of gpg-agent. > In theory you could start a new gpg-agent with a different configuration > option, but pinentry-curses really so bad? :) > > Bernhard I find it to be really bad when used from within gvim. The display doesn't work at all (for me), and most of the time, I end up with a runaway process afterwards consuming all the CPU which I have to kill manually. I think pinentry-tty is the only pinentry program that works in all of the environments that I need it to. It might be possible to configure gpg-agent to use a local script as the pinentry program, and that script distinguishes between use in mutt and everything else (perhaps by setting an environment variable whenever mutt is launched), and then execs the preferred pinentry program for each environment. cheers, raf From dmytro.a.kovalov at globallogic.com Fri Oct 28 21:00:47 2022 From: dmytro.a.kovalov at globallogic.com (Dmytro Kovalov) Date: Fri, 28 Oct 2022 22:00:47 +0300 Subject: libgcrypt clang asm configure issue. Message-ID: Hello, I found a strange libgcrypt behavior on ARM with clang built. There is a big gap in performance of libgcrypt, built by clang, in comparison with gcc on my ARM target machine. The simple profile test shows 100-500% advantage of gcc gcrypt. I found an awkward workaround to beat this issue, but need your help to find the best way to fix it. The root cause is next: Due to clang strict assembler syntax rules the unified assembler ARM check doesn't pass. Assembler check fails while ./configure for flags: HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS HAVE_GCC_INLINE_ASM_NEON As a workaround I remove '%' from registers names in configure.ac, arm mips lib *.S files, cipher/*arm.S,*armv7-neon.S files. Could you please help with a more correct - polite way to compile libgcrypt with assembler code? Tested on: libgcrypt-1.8.6 libgcrypt-1.9.3 Equipment: build machine: intel based cpu x86_64 Ubnuntu-20.04 Software compiler : clang 11.1.0 linker lld : lld 11.1.0 assembler : llvm-as 11.1.0 cflags : "-m32 -march=armv7-a -mthumb -mfpu=vfpv3-d16 --target=arm-linux-gnueabihf" arm-linux-gnueabihf sysroot based on glibc 2.31 libgcrypt configuring: CC="arm-linux-gnueabihf-clang" \ ./configure \ --with-libgpg-error-prefix= \ --prefix= \ --host=arm-linux-gnueabihf \ --enable-static \ --disable-doc target machine: hardware: model name : ARMv7 Processor rev 4 (v7l) BogoMIPS : 2304.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae aes pmull sha1 sha2 crc32 Best Regards, Dmytro Kovalov Dmytro.a.kovalov at globallogic.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcb62281 at gmail.com Mon Oct 31 03:56:15 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Sun, 30 Oct 2022 21:56:15 -0500 Subject: libgcrypt clang asm configure issue. In-Reply-To: References: Message-ID: <635F394F.5010708@gmail.com> Dmytro Kovalov via Gnupg-users wrote: > Hello, > > I found a strange libgcrypt behavior on ARM with clang built. > > There is a big gap in performance of libgcrypt, built by clang, in > comparison with gcc on my ARM target machine. > The simple profile test shows 100-500% advantage of gcc gcrypt. > I found an awkward workaround to beat this issue, but need your help > to find the best way to fix it. > > The root cause is next: > Due to clang strict assembler syntax rules the unified assembler ARM > check doesn't pass. > Assembler check fails while ./configure for flags: > HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS > HAVE_GCC_INLINE_ASM_NEON > > As a workaround I remove '%' from registers names in > configure.ac , > arm mips lib *.S files, > cipher/*arm.S,*armv7-neon.S files. > > Could you please help with a more correct - polite way to compile > libgcrypt with assembler code? I would suggest using the GNU toolchain. :-) The problem is that the GNU assembler traditionally expects register names to be prefixed with %, using a syntax based on that of the old AT&T assembler and known (simply enough) as "AT&T syntax" while many vendor assemblers use a different syntax. Note that the configure tests in question are for GCC-or-strictly-compatible. If clang does not support the GNU assembler syntax, then it is not fully compatible with GCC, and libgcrypt is being compiled correctly. Since LLVM claims compatibility with GCC, you should direct your complaints there: CLang apparently claims compatibility with the GNU toolchain, but does not support GNU assembler syntax. -- Jacob From lawisking at gmail.com Mon Oct 31 10:23:10 2022 From: lawisking at gmail.com (K S) Date: Mon, 31 Oct 2022 04:23:10 -0500 Subject: Difference between versions--Question Message-ID: I decided to build 2.3.8 from source on my Hyper-V Ubuntu 22.04 VM. I have never built software from source before but I think I got it done successfully. Attached is screenshot of the gpg --version output. I also used Scoop to install a Windows version to see if there was any difference. See attached screenshot. Question: Why aren't those identical? I notice the source build has only Uncompressed as an option. Also the copyright is a little different. Is there something I missed in my build? Kevin Smith -------------- next part -------------- A non-text attachment was scrubbed... Name: ScoopVersion_Screenshot 2022-10-31 035100.png Type: image/png Size: 137066 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildFromSource_Screenshot 2022-10-31 034907.png Type: image/png Size: 847339 bytes Desc: not available URL: From lawisking at gmail.com Mon Oct 31 10:06:15 2022 From: lawisking at gmail.com (K S) Date: Mon, 31 Oct 2022 04:06:15 -0500 Subject: Difference between versions--Question Message-ID: I decided to build 2.3.8 from source on my Hyper-V Ubuntu 22.04 VM. I have never built software from source before but I think I got it done successfully. Attached is screenshot of the gpg --version output. I also used Scoop to install a Windows version to see if there was any difference. See attached screenshot. Question: Why aren't those identical? I notice the source build has only Uncompressed as an option. Also the copyright is a little different. Is there something I missed in my build? Kevin Smith -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BuildFromSource_Screenshot 2022-10-31 034907.png Type: image/png Size: 847339 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ScoopVersion_Screenshot 2022-10-31 035100.png Type: image/png Size: 137066 bytes Desc: not available URL: From dmytro.a.kovalov at globallogic.com Mon Oct 31 11:57:54 2022 From: dmytro.a.kovalov at globallogic.com (Dmytro Kovalov) Date: Mon, 31 Oct 2022 12:57:54 +0200 Subject: libgcrypt clang asm configure issue. In-Reply-To: <635F394F.5010708@gmail.com> References: <635F394F.5010708@gmail.com> Message-ID: Hello Jacob , Thanks for the fast response! So you mentioned the problem is in clang ATT compatibility. But could you please confirm the UAL supports ATT style , because I haven't found any information there. Thanks, Best Regards. On Mon, 31 Oct 2022, 04:56 Jacob Bachmeyer, wrote: > Dmytro Kovalov via Gnupg-users wrote: > > Hello, > > > > I found a strange libgcrypt behavior on ARM with clang built. > > > > There is a big gap in performance of libgcrypt, built by clang, in > > comparison with gcc on my ARM target machine. > > The simple profile test shows 100-500% advantage of gcc gcrypt. > > I found an awkward workaround to beat this issue, but need your help > > to find the best way to fix it. > > > > The root cause is next: > > Due to clang strict assembler syntax rules the unified assembler ARM > > check doesn't pass. > > Assembler check fails while ./configure for flags: > > HAVE_COMPATIBLE_GCC_ARM_PLATFORM_AS > > HAVE_GCC_INLINE_ASM_NEON > > > > As a workaround I remove '%' from registers names in > > configure.ac > >, > > arm mips lib *.S files, > > cipher/*arm.S,*armv7-neon.S files. > > > > Could you please help with a more correct - polite way to compile > > libgcrypt with assembler code? > > I would suggest using the GNU toolchain. :-) > > The problem is that the GNU assembler traditionally expects register > names to be prefixed with %, using a syntax based on that of the old > AT&T assembler and known (simply enough) as "AT&T syntax" while many > vendor assemblers use a different syntax. Note that the configure tests > in question are for GCC-or-strictly-compatible. If clang does not > support the GNU assembler syntax, then it is not fully compatible with > GCC, and libgcrypt is being compiled correctly. > > Since LLVM claims compatibility with GCC, you should direct your > complaints there: CLang apparently claims compatibility with the GNU > toolchain, but does not support GNU assembler syntax. > > > -- Jacob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kloecker at kde.org Mon Oct 31 15:43:24 2022 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Mon, 31 Oct 2022 15:43:24 +0100 Subject: Difference between versions--Question In-Reply-To: References: Message-ID: <1841143.CQOukoFCf9@daneel> On Montag, 31. Oktober 2022 10:23:10 CET K S via Gnupg-users wrote: > Question: > Why aren't those identical? I notice the source build has only > Uncompressed as an option. [...] > Is there something I missed in my build? configure most likely didn't find the development files of the compression libraries. Check the output of configure. Regards, Ingo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: This is a digitally signed message part. URL: From jcb62281 at gmail.com Mon Oct 31 20:46:41 2022 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Mon, 31 Oct 2022 14:46:41 -0500 Subject: libgcrypt clang asm configure issue. In-Reply-To: References: <635F394F.5010708@gmail.com> Message-ID: <63602621.1030508@gmail.com> Dmytro Kovalov wrote: > Hello Jacob , > > Thanks for the fast response! > > So you mentioned the problem is in clang ATT compatibility. But could > you please confirm the UAL supports ATT style , because I haven't > found any information there. UAL is ? The key hint here for me was that you mentioned removing '%' from register names; the use of '%' in that context is (as far as I know) characteristic of "AT&T syntax" assembler, which the GNU assembler generally supports, even for processors where the vendor assembler is radically different. (x86 is a good example, where GNU as has both AT&T syntax and Intel syntax modes.) -- Jacob