From gnupg at raf.org Wed Sep 1 08:20:05 2021 From: gnupg at raf.org (raf) Date: Wed, 1 Sep 2021 16:20:05 +1000 Subject: Request: --export-options export-dane-modern Message-ID: Hi, Is there any chance that a new export option could be added (alongside or instead of export-dane) to output "modern" Bind9 zonefile syntax (i.e. "OPENPGPKEY" rather than "TYPE61 \# 2193", and base64 rather than hexadecimal)? I suppose it's not important. It's just prettier. But since DNS query tools like host and dig output OPENPGPKEY records in base64, it would make it easier to compare their output against gpg's output. The reason I'm asking is that DNSSEC is so easy to implement these days (at least with the new debian-11 which has bind-9.16+), and I've just written a DANE management tool that makes DANE easy to implement. So far it only handles TLSA and SSHFP. I'd like to add support for OPENPGPKEY (i.e. calling gpg to produce the record, and calling host to check that it's published). I could (and probably will) get it to transform gpg's output itself, but I thought I'd ask. cheers, raf From gnupg at raf.org Wed Sep 1 07:55:21 2021 From: gnupg at raf.org (raf) Date: Wed, 1 Sep 2021 15:55:21 +1000 Subject: Why is --auto-key-locate only for encrypting? Message-ID: Hi, debian-11, gpg-2.2.27 Why is the --auto-key-locate only for encrypting (says the gpg(1) manpage)? Wouldn't it also be useful when receiving emails and verifying signatures? cheers, raf From kloecker at kde.org Wed Sep 1 13:50:36 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Wed, 01 Sep 2021 13:50:36 +0200 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: References: Message-ID: <2227534.beFA3AZiCX@daneel> On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > Why is the --auto-key-locate only for encrypting (says > the gpg(1) manpage)? Wouldn't it also be useful when > receiving emails and verifying signatures? --auto-key-locate looks up keys by email address. It makes no sense when verifying signatures because in this case you already know the key id the signature was made with, so that there's no reason to look up the key by email address (which is ambiguous). The equivalent for automatic look-up of keys when verifying signatures is --auto-key-retrieve. 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 Wed Sep 1 18:15:56 2021 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Wed, 1 Sep 2021 12:15:56 -0400 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: <2227534.beFA3AZiCX@daneel> References: <2227534.beFA3AZiCX@daneel> Message-ID: On 2021-09-01 at 13:50 +0200, Ingo Kl?cker wrote: > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > > Why is the --auto-key-locate only for encrypting (says > > the gpg(1) manpage)? Wouldn't it also be useful when > > receiving emails and verifying signatures? > > --auto-key-locate looks up keys by email address. It makes no sense when > verifying signatures because in this case you already know the key id the > signature was made with, so that there's no reason to look up the key by email > address (which is ambiguous). If you're looking up purely by key id, then you need a working global key-lookup facility. It doesn't federate. If you look up by email address, then federation becomes available and efforts such as WKD pay off. -Phil From gnupg at raf.org Thu Sep 2 01:28:42 2021 From: gnupg at raf.org (raf) Date: Thu, 2 Sep 2021 09:28:42 +1000 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: <2227534.beFA3AZiCX@daneel> References: <2227534.beFA3AZiCX@daneel> Message-ID: On Wed, Sep 01, 2021 at 01:50:36PM +0200, Ingo Kl?cker wrote: > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > > Why is the --auto-key-locate only for encrypting (says > > the gpg(1) manpage)? Wouldn't it also be useful when > > receiving emails and verifying signatures? > > --auto-key-locate looks up keys by email address. It makes no sense when > verifying signatures because in this case you already know the key id the > signature was made with, so that there's no reason to look up the key by email > address (which is ambiguous). Thanks. I don't understand why it makes no sense, but I'll take your word for it. But I can think of a reason to look up the key by email address even though you have the keyid from the signature: when the key is not on a keyserver or a WKD server, but is in a DNS OPENPGPKEY record (DANE). But perhaps that's not a thing. > The equivalent for automatic look-up of keys when verifying signatures is > --auto-key-retrieve. Thanks, but the manpage doesn't include DANE as one of the lookup methods for that option. That's what I was hoping for. Since this option does a WKD lookup if wkd is in the auto-key-locate list (and --disable-signer-uid isn't used), it seems that it would make sense to do a DANE lookup if dane is in the auto-key-locate list (and --disable-signer-uid isn't used). > Regards, > Ingo cheers, raf From kloecker at kde.org Thu Sep 2 12:57:47 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 02 Sep 2021 12:57:47 +0200 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: References: <2227534.beFA3AZiCX@daneel> Message-ID: <7317420.EsbIL7D5TR@daneel> On Mittwoch, 1. September 2021 18:15:56 CEST Phil Pennock via Gnupg-users wrote: > On 2021-09-01 at 13:50 +0200, Ingo Kl?cker wrote: > > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > > > Why is the --auto-key-locate only for encrypting (says > > > the gpg(1) manpage)? Wouldn't it also be useful when > > > receiving emails and verifying signatures? > > > > --auto-key-locate looks up keys by email address. It makes no sense when > > verifying signatures because in this case you already know the key id the > > signature was made with, so that there's no reason to look up the key by > > email address (which is ambiguous). > > If you're looking up purely by key id, then you need a working global > key-lookup facility. It doesn't federate. > > If you look up by email address, then federation becomes available and > efforts such as WKD pay off. I concur. That's why --auto-key-retrieve also does a WKD lookup if the signature has the Signer's UID set. 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 kloecker at kde.org Thu Sep 2 13:10:40 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 02 Sep 2021 13:10:40 +0200 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: References: <2227534.beFA3AZiCX@daneel> Message-ID: <2046178.hczzZopr1A@daneel> On Donnerstag, 2. September 2021 01:28:42 CEST raf via Gnupg-users wrote: > On Wed, Sep 01, 2021 at 01:50:36PM +0200, Ingo Kl?cker wrote: > > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > > > Why is the --auto-key-locate only for encrypting (says > > > the gpg(1) manpage)? Wouldn't it also be useful when > > > receiving emails and verifying signatures? > > > > --auto-key-locate looks up keys by email address. It makes no sense when > > verifying signatures because in this case you already know the key id the > > signature was made with, so that there's no reason to look up the key by > > email address (which is ambiguous). > > Thanks. I don't understand why it makes no sense, but > I'll take your word for it. But I can think of a reason > to look up the key by email address even though you > have the keyid from the signature: when the key is not > on a keyserver or a WKD server, but is in a DNS > OPENPGPKEY record (DANE). But perhaps that's not a thing. I retract my claim that is makes no sense. It can make sense and that's why --auto-key-retrieve also does a lookup by email address on WKD. > > The equivalent for automatic look-up of keys when verifying signatures is > > --auto-key-retrieve. > > Thanks, but the manpage doesn't include DANE as one of > the lookup methods for that option. That's what I was > hoping for. > > Since this option does a WKD lookup if wkd is in the > auto-key-locate list (and --disable-signer-uid isn't > used), it seems that it would make sense to do a DANE > lookup if dane is in the auto-key-locate list (and > --disable-signer-uid isn't used). So what you actually want is that --auto-key-retrieve also does a DANE lookup or in fact all kinds of lookup supported by --auto-key-locate. Did you check that it not already does this (even if the man page doesn't mention it)? If yes, then I'd say submit a request for this feature at https://dev.gnupg.org. 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 at raf.org Fri Sep 3 04:29:59 2021 From: gnupg at raf.org (raf) Date: Fri, 3 Sep 2021 12:29:59 +1000 Subject: Why is --auto-key-locate only for encrypting? In-Reply-To: <2046178.hczzZopr1A@daneel> References: <2227534.beFA3AZiCX@daneel> <2046178.hczzZopr1A@daneel> Message-ID: On Thu, Sep 02, 2021 at 01:10:40PM +0200, Ingo Kl?cker wrote: > On Donnerstag, 2. September 2021 01:28:42 CEST raf via Gnupg-users wrote: > > On Wed, Sep 01, 2021 at 01:50:36PM +0200, Ingo Kl?cker > wrote: > > > On Mittwoch, 1. September 2021 07:55:21 CEST raf via Gnupg-users wrote: > > > > Why is the --auto-key-locate only for encrypting (says > > > > the gpg(1) manpage)? Wouldn't it also be useful when > > > > receiving emails and verifying signatures? > > > > > > --auto-key-locate looks up keys by email address. It makes no sense when > > > verifying signatures because in this case you already know the key id the > > > signature was made with, so that there's no reason to look up the key by > > > email address (which is ambiguous). > > > > Thanks. I don't understand why it makes no sense, but > > I'll take your word for it. But I can think of a reason > > to look up the key by email address even though you > > have the keyid from the signature: when the key is not > > on a keyserver or a WKD server, but is in a DNS > > OPENPGPKEY record (DANE). But perhaps that's not a thing. > > I retract my claim that is makes no sense. It can make sense and that's why > --auto-key-retrieve also does a lookup by email address on WKD. > > > > The equivalent for automatic look-up of keys when verifying signatures is > > > --auto-key-retrieve. > > > > Thanks, but the manpage doesn't include DANE as one of > > the lookup methods for that option. That's what I was > > hoping for. > > > > Since this option does a WKD lookup if wkd is in the > > auto-key-locate list (and --disable-signer-uid isn't > > used), it seems that it would make sense to do a DANE > > lookup if dane is in the auto-key-locate list (and > > --disable-signer-uid isn't used). > > So what you actually want is that --auto-key-retrieve also does a DANE lookup > or in fact all kinds of lookup supported by --auto-key-locate. Did you check > that it not already does this (even if the man page doesn't mention it)? If > yes, then I'd say submit a request for this feature at https://dev.gnupg.org. > > Regards, > Ingo I didn't check. I just based it on the manpage. I just checked the NEWS file, and there's no mention of such functionality. I'll submit a feature request. Thanks. cheers, raf From borden_c at tutanota.com Sat Sep 4 12:11:34 2021 From: borden_c at tutanota.com (Borden) Date: Sat, 4 Sep 2021 12:11:34 +0200 (CEST) Subject: Error messages reconfiguring an OpenPGP smartcard Message-ID: I've tried to follow the patchwork documentation to reconfigure my OpenPGP card, but rather than continue wasting time, I thought I'd reach out for help. According to gpg --card-status, I have an OpenPGP card v. 2.1 made by LogoEmail (that's not from whom I bought it, so I'm not sure if the information is even correct). I'm trying to follow https://gnupg.org/howtos/card-howto/en/smartcard-howto.html . I get to part 3.3. When I type "generate" and enter the requested information, I get the following output after a brief pause: gpg: signing failed: Invalid value gpg: make_keysig_packet failed: Invalid value Key generation failed: Invalid value I've searched for these error messages and cannot find anything helpful. When I run gpg --card-status again, the signature and authentication keys seem to be updated, but the encryption key is not. Furthermore, General key info reads [none]. Again, if there's documentation to say whether this output is correct or not, I haven't found it in over two hours. I'm on Debian testing, if that's relevant. Can I get some troubleshooting guidance to understand this output and why I cannot generate a new encryption key? Also, I believe that, after generating the keys, I need to import them into my keyring. This isn't documented in the How-to, and it really should be. Could I get a brief explanation on how to do so if I don't generate an off-card backup of the encryption key? With thanks, From meator.dev at gmail.com Sun Sep 5 18:45:45 2021 From: meator.dev at gmail.com (meator meator) Date: Sun, 5 Sep 2021 18:45:45 +0200 Subject: What is the state of https://git.gnupg.org/? Message-ID: Hello, what's up with https://git.gnupg.org/? Is there some maintenance happening? From wk at gnupg.org Mon Sep 6 15:34:16 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 06 Sep 2021 15:34:16 +0200 Subject: What is the state of https://git.gnupg.org/? In-Reply-To: (meator meator via Gnupg-users's message of "Sun, 5 Sep 2021 18:45:45 +0200") References: Message-ID: <871r61rfon.fsf@wheatstone.g10code.de> On Sun, 5 Sep 2021 18:45, meator meator said: > Hello, what's up with https://git.gnupg.org/? Is there some > maintenance happening? The OOM kicked in and killed the TLS frontend. Its up again. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From meator.dev at gmail.com Mon Sep 6 19:25:34 2021 From: meator.dev at gmail.com (meator) Date: Mon, 6 Sep 2021 19:25:34 +0200 Subject: What is the state of https://git.gnupg.org/? In-Reply-To: <871r61rfon.fsf@wheatstone.g10code.de> References: <871r61rfon.fsf@wheatstone.g10code.de> Message-ID: Ok, thanks! On Mon, 6 Sept 2021 at 15:35, Werner Koch wrote: > > On Sun, 5 Sep 2021 18:45, meator meator said: > > Hello, what's up with https://git.gnupg.org/? Is there some > > maintenance happening? > > The OOM kicked in and killed the TLS frontend. Its up again. > > > Salam-Shalom, > > Werner > > -- > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Sep 7 10:33:54 2021 From: wk at gnupg.org (Werner Koch) Date: Tue, 07 Sep 2021 10:33:54 +0200 Subject: What is the state of https://git.gnupg.org/? In-Reply-To: (meator via Gnupg-users's message of "Mon, 6 Sep 2021 19:25:34 +0200") References: <871r61rfon.fsf@wheatstone.g10code.de> Message-ID: <87r1e0pyx9.fsf@wheatstone.g10code.de> On Mon, 6 Sep 2021 19:25, meator said: > Ok, thanks! Sorry for that. This is a sponsered VM and sometimes we run into OOM problems. We like to keep these repos on this different machine so that we can conitnue to collaborate even if other servers fail, or vice versa. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mwood at iupui.edu Wed Sep 8 18:53:45 2021 From: mwood at iupui.edu (Mark H. Wood) Date: Wed, 8 Sep 2021 12:53:45 -0400 Subject: Off-topic: standards for embedded signing of digital images? Message-ID: I didn't know where else to turn, for folks who might be able to point me at standards for or discussion of embedding crypto signatures in image formats, to detect tampering with the image. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From vuori at notcom.org Thu Sep 9 10:36:10 2021 From: vuori at notcom.org (Valtteri Vuorikoski) Date: Thu, 09 Sep 2021 11:36:10 +0300 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: (Mark H. Wood via Gnupg-users's message of "Wed, 8 Sep 2021 12:53:45 -0400") References: Message-ID: <871r5yno1x.fsf@notcom.org> "Mark H. Wood via Gnupg-users" writes: > I didn't know where else to turn, for folks who might be able to point > me at standards for or discussion of embedding crypto signatures in > image formats, to detect tampering with the image. While you can technically embed some kind of signature in pretty much any image format's XMP or EXIF metadata (and some cameras do), the only graphic format with a reasonably well-defined and supported signature scheme is probably PDF. Unfortunately PDF's complex structure makes correct implementation difficult and most vendors (including Adobe) have had numerous issues: https://www.ndss-symposium.org/wp-content/uploads/ndss2021_1B-4_24117_paper.pdf You may be interested in the Adobe et al. Content Authenticity Initiative, though that scheme's compatibility with open-source software seems dubious. -Valtteri -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From fred at silberberg.xyz Thu Sep 9 01:54:12 2021 From: fred at silberberg.xyz (Fredric Silberberg) Date: Wed, 8 Sep 2021 16:54:12 -0700 Subject: Windows Hello Interference on 2.3.X In-Reply-To: References: Message-ID: Hi GPG Mailing list, is there anything I can do to help someone look at this issue? Thanks, - Fred Silberberg On Wed, Aug 25, 2021 at 12:09 PM Fredric Silberberg wrote: > Hi folks, > > It appears some changes in the 2.3.X branch have broken my Yubikey OpenPGP > key on systems that also have a Windows Hello for Business PIN set up. > Here's the behavior I'm seeing: > > scdaemon.conf: > > debug-level guru > log-file "%APPDATA%\gnupg\scdaemon.log" > reader-port "Yubico YubiKey OTP+FIDO+CCID 0" > > 2.2.29: The above works, gpg --card-status returns info on my Yubikey. > > 2.3.0/1: gpg --card-status returns: > gpg: selecting card failed: End of file > gpg: OpenPGP card not available: End of file > > Log file: attached, scdaemon.2.3.1.log > > 2.3.2: gpg --card-status enters an infinite loop, never completing and > pegging a single CPU as hard as it can. The log file output is attached, > scdaemon.2.3.2.log. I've clipped it to not overwhelm inboxes, but the last > two lines will continuously repeat, making the file as big as you let it > run. > > I'd appreciate any help or insight into what's going on here. For the > moment, I'm still using 2.2.29 because the 2.3.X versions are totally > busted for me. > > Thanks, > - Fred Silberberg > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olikon at shaw.ca Thu Sep 9 12:43:05 2021 From: olikon at shaw.ca (Oli Kon) Date: Thu, 9 Sep 2021 10:43:05 +0000 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: References: Message-ID: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users - gnupg-users at gnupg.org wrote: > I didn't know where else to turn, for folks who might be able to point > me at standards for or discussion of embedding crypto signatures in > image formats, to detect tampering with the image. There are no standards that I have ever heard about that would be specific to ~image~ files; so I would ask this: Which particular image file type are you interested in (.jpg, .tiff, .png, .bmp, .psd...) are you interested in, and why is it not appropriate to simply consider such file as another binary file that someone needs to digitally sign? From mwood at iupui.edu Fri Sep 10 15:28:27 2021 From: mwood at iupui.edu (Mark H. Wood) Date: Fri, 10 Sep 2021 09:28:27 -0400 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> References: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> Message-ID: On Thu, Sep 09, 2021 at 10:43:05AM +0000, Oli Kon via Gnupg-users wrote: > On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users - > gnupg-users at gnupg.org wrote: > > I didn't know where else to turn, for folks who might be able to point > > me at standards for or discussion of embedding crypto signatures in > > image formats, to detect tampering with the image. > > There are no standards that I have ever heard about that would > be specific to ~image~ files; so I would ask this: > > Which particular image file type are you interested in (.jpg, > .tiff, .png, .bmp, .psd...) are you interested in, and why is it > not appropriate to simply consider such file as another binary > file that someone needs to digitally sign? Formats: first of all .jpg, but really any image format that can bear signature data. Why are image files special? They aren't. For every type of structured file, one must consider the structure of the file type in order to insert a signature without disrupting the other content, to identify the content which should be covered by the signature, and to locate the signature data. -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From ryan at digicana.com Fri Sep 10 22:00:55 2021 From: ryan at digicana.com (Ryan McGinnis) Date: Fri, 10 Sep 2021 20:00:55 +0000 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> References: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> Message-ID: <2P_uMbGbOpfXOF8VQ2ZGG7FdsayP8O5qDMvVfgxn83DVYQRpr2Xd0W4aAm58pRn5o8rpBAusJWmOYlF5cjPmJ8Fwa3gqm2gppMauhbHBjsM=@digicana.com> Years ago, I think Canon offered some kind of in-camera file format that supposedly could prove that the file had not been tampered with. Eventually exploits were found that rendered it unreliable. https://hk.canon/en/support/to-users-of-the-original-data-security-kit-osk-e3-original-data-verification-kit-dvk-e1-or-dvk-e2-accessories-for-digital-slr-cameras/notice I suppose if you were going to engineer a spec like that today you'd have each camera have it's own key that it used (maybe alongside a baked-in manufacturer key) to sign the relevant guts of RAW files of each shot it took. But this would really only be useful in a true forensics type situation, as most photographers end up editing and altering photos with programs like Lightroom before they call them "done". As it is, most of the time people look for image tampering not through signatures but rather by looking for telltale signs of the artifacts left behind by common forms of tampering. https://belkasoft.com/forgery-detection -Ryan McGinnis ryan at digicana.com http://bigstormpicture.com 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD ??????? Original Message ??????? On Thursday, September 9th, 2021 at 5:43 AM, Oli Kon via Gnupg-users wrote: > On 2021-09-08 4:53 p.m., Mark H. Wood via Gnupg-users - > > gnupg-users at gnupg.org wrote: > > > I didn't know where else to turn, for folks who might be able to point > > > > me at standards for or discussion of embedding crypto signatures in > > > > image formats, to detect tampering with the image. > > There are no standards that I have ever heard about that would > > be specific to ~image~ files; so I would ask this: > > Which particular image file type are you interested in (.jpg, > > .tiff, .png, .bmp, .psd...) are you interested in, and why is it > > not appropriate to simply consider such file as another binary > > file that someone needs to digitally sign? > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From olikon at shaw.ca Sat Sep 11 20:53:57 2021 From: olikon at shaw.ca (Oli Kon) Date: Sat, 11 Sep 2021 18:53:57 +0000 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: <2P_uMbGbOpfXOF8VQ2ZGG7FdsayP8O5qDMvVfgxn83DVYQRpr2Xd0W4aAm58pRn5o8rpBAusJWmOYlF5cjPmJ8Fwa3gqm2gppMauhbHBjsM=@digicana.com> References: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> <2P_uMbGbOpfXOF8VQ2ZGG7FdsayP8O5qDMvVfgxn83DVYQRpr2Xd0W4aAm58pRn5o8rpBAusJWmOYlF5cjPmJ8Fwa3gqm2gppMauhbHBjsM=@digicana.com> Message-ID: On 2021-09-10 8:00 p.m., Ryan McGinnis via Gnupg-users - gnupg-users at gnupg.org wrote: > Years ago, I think Canon offered some kind of in-camera file format > that supposedly could prove that the file had not been tampered with. We appear to be talking about two different things here. Both Nikon and Canon had developed a system which, purportedly, guaranteed that an image file represented "a reality, as the camera has seen it". This is no more possible than constructing a ~perpetum mobile~, for no matter what the in-camera software and hardware did, the lens could be simply pointed to a synthetic image that is a faked reality, and camera would be none the wiser. By that naive logic, we could point the lens at the Botticelli's painting and camera would produce a cryptgraphically signed file that guaranteed that the photographer was present when Venus was born. Both Nikon and Canon quickly realized the error of their ways and quietly dropped the whole idea. Is is a completely different thing for an owner of a private cryptographic key to sign a file, and clearly state what it is that he or she guarantees. That is a trivial process but it requires three things: a clear statement of what is it that the file signer guarantees, a secure conveyance of matching public key into the hands of the image user and a detached or "baked-into-file" signature. Since all three things are required, I see no significant advantage of an in-file (as opposed to a detached) signature. From stefan.vasilev at posteo.ru Sun Sep 12 01:54:08 2021 From: stefan.vasilev at posteo.ru (=?UTF-8?Q?=D0=A1=D1=82=D0=B5=D1=84=D0=B0=D0=BD_=D0=92=D0=B0=D1=81?= =?UTF-8?Q?=D0=B8=D0=BB=D1=8C=D0=B5=D0=B2?=) Date: Sat, 11 Sep 2021 23:54:08 +0000 Subject: Off-topic: standards for embedded signing of digital =?UTF-8?Q?images=3F?= In-Reply-To: References: Message-ID: <25bce458cd1ce919e0ea3ba8d8c3419a@posteo.de> Mark H. Wood wrote: > I didn't know where else to turn, for folks who might be able to point > me at standards for or discussion of embedding crypto signatures in > image formats, to detect tampering with the image. I do not know any, but like to add my POV. Let's say GnuPG could digitally sign a .png image, i.e. inserting the signature steganographically in the image and later a user could verify the steganographically embedbed signature. What happens if Eve uses Photoshop and does a slightly image correcting and re-saves the image? It would IMHO give a user then an invalid signature or none. Sending images over the Internet, say from an authorized photostudio (passport photos etc.) can only be savely transmitted (openly) IMHO if the photostudio would embedd the image in an, for example, digitally signed .pdf, containing an eIDAS[1] signature, guaranteeing globally that the image in the .pdf was signed by an authorized photosudio and not manipulated by a middleman, while in transfer. [1] eIDAS is the Digital Signature Standard in the EU for .pdf documents, which can be verified with the free Adobe Reader. Regards Stefan From ryan at digicana.com Sun Sep 12 04:31:08 2021 From: ryan at digicana.com (Ryan McGinnis) Date: Sun, 12 Sep 2021 02:31:08 +0000 Subject: Off-topic: standards for embedded signing of digital images? In-Reply-To: References: <3e78434c-75d9-0bc3-27da-fbeac7db1abe@shaw.ca> <2P_uMbGbOpfXOF8VQ2ZGG7FdsayP8O5qDMvVfgxn83DVYQRpr2Xd0W4aAm58pRn5o8rpBAusJWmOYlF5cjPmJ8Fwa3gqm2gppMauhbHBjsM=@digicana.com> Message-ID: No, I think what Canon and Nikon attempted to implement was something that, when paired with a validation software, would say with certainty "this is exactly what the camera wrote to the card". It wasn't saying anything about whether what was being photographed was real or faked, merely that after the image file was written it wasn't tampered with. It's a chain of custody thing. Sorta like signing software -- the signature doesn't mean the software isn't a Trojan, it just means that the software has been signed by whatever key it was signed by, and you decide what that signature means to you. Unfortunately they never really got the standard down, which is kinda funny since it's the kind of thing that can almost certainly be done. I guess there just wasn't much of a market for it. (Probably because altering photos undetectably is very hard to do -- you don't need digital signatures to see that the DA used the clone tool to put the gun in the killer's hand) -Ryan McGinnis ryan at digicana.com http://bigstormpicture.com 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD ??????? Original Message ??????? On Saturday, September 11th, 2021 at 2:53 PM, Oli Kon via Gnupg-users wrote: > On 2021-09-10 8:00 p.m., Ryan McGinnis via Gnupg-users - > > gnupg-users at gnupg.org wrote: > > > Years ago, I think Canon offered some kind of in-camera file format > > > > that supposedly could prove that the file had not been tampered with. > > We appear to be talking about two different things here. Both Nikon > > and Canon had developed a system which, purportedly, guaranteed that > > an image file represented "a reality, as the camera has seen it". > > This is no more possible than constructing a ~perpetum mobile~, for > > no matter what the in-camera software and hardware did, the lens > > could be simply pointed to a synthetic image that is a faked reality, > > and camera would be none the wiser. By that naive logic, we could > > point the lens at the Botticelli's painting and camera would produce > > a cryptgraphically signed file that guaranteed that the photographer > > was present when Venus was born. Both Nikon and Canon quickly > > realized the error of their ways and quietly dropped the whole idea. > > Is is a completely different thing for an owner of a private > > cryptographic key to sign a file, and clearly state what it is that > > he or she guarantees. That is a trivial process but it requires > > three things: a clear statement of what is it that the file signer > > guarantees, a secure conveyance of matching public key into the hands > > of the image user and a detached or "baked-into-file" signature. > > Since all three things are required, I see no significant advantage > > of an in-file (as opposed to a detached) signature. > > Gnupg-users mailing list > > Gnupg-users at gnupg.org > > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From lyknode at cilg.org Wed Sep 15 20:30:25 2021 From: lyknode at cilg.org (Baptiste Beauplat) Date: Wed, 15 Sep 2021 20:30:25 +0200 Subject: Size for ECC keys have changed from 256 to 255 Message-ID: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> Hi, I noticed that the key size reported by gpg --with-colons for ECC keys (ed25519) have changed from 256 to 255. For instance, on my key I previously got: $gpg --with-colons -k lyknode at cilg.org | grep pub | cut -d : -f 3 256 While now the result is: $gpg --with-colons -k lyknode at cilg.org | grep pub | cut -d : -f 3 255 I was wondering if that's a bug, since from what I understand (certainly way to little) the public key size of ed25519 is fixed at 256 and the value 255 is only used in the prime number calculation (2^255 - 19). Note: The changed comes from the following commit in libgcrypt: https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d Best, -- Baptiste Beauplat - lyknode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From wk at gnupg.org Thu Sep 16 12:27:33 2021 From: wk at gnupg.org (Werner Koch) Date: Thu, 16 Sep 2021 12:27:33 +0200 Subject: [Announce] GnuPG 2.2.31 (LTS) released Message-ID: <877dfgerxm.fsf@wheatstone.g10code.de> Hello! We are pleased to announce the availability of a new GnuPG LTS release: version 2.2.31. This release fixes a few minor bugs and a regression in the last release. The LTS (long term support) series of GnuPG is guaranteed to be maintained at least until the end of 2024. See https://gnupg.org/download/index.html#end-of-life What is GnuPG ============= The GNU Privacy Guard (GnuPG, GPG) is a complete and free implementation of the OpenPGP and S/MIME standards. GnuPG allows to encrypt and sign data and communication, features a versatile key management system as well as access modules for public key directories. GnuPG itself is a command line tool with features for easy integration with other applications. The separate library GPGME provides a uniform API to use the GnuPG engine by software written in common programming languages. A wealth of frontend applications and libraries making use of GnuPG are available. As an universal crypto engine GnuPG provides support for S/MIME and Secure Shell in addition to OpenPGP. GnuPG is Free Software (meaning that it respects your freedom). It can be freely used, modified and distributed under the terms of the GNU General Public License. Noteworthy changes in version 2.2.31 (2021-09-15) ================================================= * agent: Fix a regression in GET_PASSPHRASE. [#5577] * scd: Fix an assertion failure in close_pcsc_reader. [67e1834ad4] * scd: Add support for PC/SC in "GETINFO reader_list". Release-info: https://dev.gnupg.org/T5571 Getting the Software ==================== Please follow the instructions found at or read on: GnuPG 2.2.31 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.2.31.tar.bz2 (7043k) https://gnupg.org/ftp/gcrypt/gnupg/gnupg-2.2.31.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.2.31_20210915.exe (4395k) https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_202109.exe.sig The source used to build the Windows installer can be found in the same directory with a ".tar.xz" suffix. A new version of Gpg4win will probably not be published. Users affected by one of the fixed bugs may instead install this version on top of Gpg4win 3.1.16. 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.2.31.tar.bz2 you would use this command: gpg --verify gnupg-2.2.31.tar.bz2.sig gnupg-2.2.31.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.2.31.tar.bz2, you run the command like this: sha1sum gnupg-2.2.31.tar.bz2 and check that the output matches the next line: 18104b919caf14d1ef17635262418f382f888d53 gnupg-2.2.31.tar.bz2 e387330c49855bd5a04387b3c9a51abfdafa5e64 gnupg-w32-2.2.31_20210915.tar.xz abc56b365c4e9a93d0b55de72b631b1615b66628 gnupg-w32-2.2.31_20210915.exe Internationalization ==================== This version of GnuPG has support for 26 languages with Chinese (traditional and simplified), Czech, French, German, Italian, Japanese, Norwegian, Polish, Russian, 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 thee 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/T5571 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 still mostly 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. 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, or answering questions on the mailing lists. Many thanks to our numerous financial supporters, both corporate and individuals. Without you it would not be possible to keep GnuPG in a good and secure shape and to address all the small and larger requests made by our users. Thanks. Happy hacking, 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 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) 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. -- Please read Nils Melzer: Der Fall Julian Assange It is really important to know the background of the Assange case to understand the massive perils to free journalism. The book is right now only available in German: https://dev.gnupg.org/u/melzerassang -------------- 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 gniibe at fsij.org Fri Sep 17 08:30:58 2021 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 17 Sep 2021 15:30:58 +0900 Subject: Size for ECC keys have changed from 256 to 255 In-Reply-To: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> References: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> Message-ID: <87czp7lnml.fsf@akagi.fsij.org> Baptiste Beauplat wrote: > I noticed that the key size reported by gpg --with-colons for ECC keys > (ed25519) have changed from 256 to 255. Thank you for sharing. I didn't know that it is exposed to users. (I considered it were (only) internal thing in libgcrypt.) > I was wondering if that's a bug, since from what I understand (certainly > way to little) the public key size of ed25519 is fixed at 256 and the > value 255 is only used in the prime number calculation (2^255 - 19). > > Note: The changed comes from the following commit in libgcrypt: > > https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d Yes, I did it. Let me explain the reason why I did. It is certainly a "fix", from the viewpoint of the library. The field is NBITS, number of bits (of the curve). This information (exact number of bits, instead of rounded one to 2^n) is needed. For example, in the computation of X25519, it needs to check if there are more bit(s) in octet. Besides, for other curves, this field is used in this semantics (See NIST P-521). -- From bernhard at intevation.de Fri Sep 17 11:33:17 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 17 Sep 2021 11:33:17 +0200 Subject: Unable to load dll In-Reply-To: <20210804175849.GA10236@springbeautygroup.com> References: <20210804175849.GA10236@springbeautygroup.com> Message-ID: <202109171133.23798.bernhard@intevation.de> Hi Eric, Am Mittwoch 04 August 2021 19:58:49 schrieb Eric Y. Lin: > I've built up a win32 application to remotely import a public key to verify > a digital signature. Everything works fine in a Windows 10 machine. Yet, as > I was trying this win32 app when the gpg4win-3.1.16 was uninstalled, it > didn't work. > > The error message is "Unable to load DLL '.....'" The > specified module could not be found. I got the same error message even if I > copied the libgpgme.imp and libgpgme-11.dll to be in the same folder as the > win32 app. It seems that your application was using GPGME, which is the official API for the GnuPG crypto engine. For it to work, you'd need Gpg4win or another build of GnuPG and GPGME for windows installed. There is GnuPG only build for Windows, but as I remember it may not include GPGME. > Another small issue is that the remotely listing and importing public key > is a very slow process. It usually takes about one minute or so to > complete. Is this a normal thing ? I am not e what you mean by remotely. If you are accessing a keyserver or using WKD, it first depends on the speed of the server response and the network. Both should be fast. GnuPG then may need to compute the trust relations and this can take a bit, if there are many. Before you can make this faster, I'd try to find out where the time is spend. Best Regards, Bernhard -- www.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, Dr. Jan-Oliver Wagner -------------- 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 johanw at vulcan.xs4all.nl Fri Sep 17 13:36:48 2021 From: johanw at vulcan.xs4all.nl (Johan Wevers) Date: Fri, 17 Sep 2021 13:36:48 +0200 Subject: [Announce] GnuPG 2.2.31 (LTS) released In-Reply-To: <877dfgerxm.fsf@wheatstone.g10code.de> References: <877dfgerxm.fsf@wheatstone.g10code.de> Message-ID: <83419b18-6e66-b8a0-1ad2-2f248426faeb@vulcan.xs4all.nl> On 16-09-2021 12:27, Werner Koch wrote: > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_202109.exe.sig The signature file can't be found. -- ir. J.C.A. Wevers PGP/GPG public keys at http://www.xs4all.nl/~johanw/pgpkeys.html From kloecker at kde.org Fri Sep 17 16:07:36 2021 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Fri, 17 Sep 2021 16:07:36 +0200 Subject: [Announce] GnuPG 2.2.31 (LTS) released In-Reply-To: <83419b18-6e66-b8a0-1ad2-2f248426faeb@vulcan.xs4all.nl> References: <877dfgerxm.fsf@wheatstone.g10code.de> <83419b18-6e66-b8a0-1ad2-2f248426faeb@vulcan.xs4all.nl> Message-ID: <4921915.TiVpgQdEpu@daneel> On Freitag, 17. September 2021 13:36:48 CEST Johan Wevers via Gnupg-users wrote: > On 16-09-2021 12:27, Werner Koch wrote: > > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_202109.exe.sig > > The signature file can't be found. On 16-09-2021 12:27, Werner Koch wrote: > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_20210915.exe (4395k) > https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_202109.exe.sig Obviously, this should have been https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.2.31_20210915.exe.sig 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 a.yousar at informatik.hu-berlin.de Fri Sep 17 16:51:42 2021 From: a.yousar at informatik.hu-berlin.de (Annie Yousar) Date: Fri, 17 Sep 2021 16:51:42 +0200 Subject: Size for ECC keys have changed from 256 to 255 In-Reply-To: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> References: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> Message-ID: <4e3685b7-a987-5d93-511c-a09552142243@informatik.hu-berlin.de> Baptiste, usually the bit length of the characteristic /p /of the finite field, where all the coordinate computationa are made, is taken as the key length. And whereas this bit length of the prime for the NIST curve P-256? is 256 , it is 255 for Curve25519. Therefore the key length value is correct, despite the public key has a bitlength of 256. /Ann. Am 2021-09-15 um 20:30 schrieb Baptiste Beauplat via Gnupg-users: > Hi, > > I noticed that the key size reported by gpg --with-colons for ECC keys > (ed25519) have changed from 256 to 255. > > For instance, on my key I previously got: > > $gpg --with-colons -k lyknode at cilg.org | grep pub | cut -d : -f 3 > 256 > > While now the result is: > > $gpg --with-colons -k lyknode at cilg.org | grep pub | cut -d : -f 3 > 255 > > I was wondering if that's a bug, since from what I understand (certainly > way to little) the public key size of ed25519 is fixed at 256 and the > value 255 is only used in the prime number calculation (2^255 - 19). > > Note: The changed comes from the following commit in libgcrypt: > > https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d > > Best, > > > _______________________________________________ > Gnupg-users mailing list > Gnupg-users at gnupg.org > http://lists.gnupg.org/mailman/listinfo/gnupg-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From lyknode at cilg.org Thu Sep 23 20:17:00 2021 From: lyknode at cilg.org (Baptiste Beauplat) Date: Thu, 23 Sep 2021 20:17:00 +0200 Subject: Size for ECC keys have changed from 256 to 255 In-Reply-To: <87czp7lnml.fsf@akagi.fsij.org> References: <20210915183025.4znxqwshi46annjc@libra.beauplat.fr> <87czp7lnml.fsf@akagi.fsij.org> Message-ID: <20210923181700.ec5z75hjzaywltkg@libra.beauplat.fr> Hi Yutaka, On 2021/09/17 03:30 PM, NIIBE Yutaka wrote: > Baptiste Beauplat wrote: > > I noticed that the key size reported by gpg --with-colons for ECC keys > > (ed25519) have changed from 256 to 255. > > Thank you for sharing. I didn't know that it is exposed to users. > (I considered it were (only) internal thing in libgcrypt.) > > > I was wondering if that's a bug, since from what I understand (certainly > > way to little) the public key size of ed25519 is fixed at 256 and the > > value 255 is only used in the prime number calculation (2^255 - 19). > > > > Note: The changed comes from the following commit in libgcrypt: > > > > https://dev.gnupg.org/rCdb7b2c591004868abedbc2c19d3bb2efebf8529d > > Yes, I did it. > > Let me explain the reason why I did. > > It is certainly a "fix", from the viewpoint of the library. > > The field is NBITS, number of bits (of the curve). This information > (exact number of bits, instead of rounded one to 2^n) is needed. For > example, in the computation of X25519, it needs to check if there are > more bit(s) in octet. Besides, for other curves, this field is used in > this semantics (See NIST P-521). Thank you for clarifying this. If I understood correctly, my problem comes from the fact that the size of the public key isn't strictly equal to NBITS however that's the value used in the frontend part. In that case, I'll open a bug against gnupg itself. -- Baptiste Beauplat - lyknode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From bernhard at intevation.de Fri Sep 24 12:15:28 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Fri, 24 Sep 2021 12:15:28 +0200 Subject: Error messages reconfiguring an OpenPGP smartcard In-Reply-To: References: Message-ID: <202109241215.35020.bernhard@intevation.de> Hi Borden, Am Samstag 04 September 2021 12:11:34 schrieb Borden via Gnupg-users: > Can I get some troubleshooting guidance to understand this output and why > I cannot generate a new encryption key? in general, increasing verbosity helps to understand better what is going on. For most GnuPG command line tools, this means to add "--verbose" or the short form "-v" to the command line. A second "-v" will give you more data. Then there is the group of "--debug" options which will give you even more insights. Check the documentation to see what they actually do. (And be careful when posting those verbose information, it my contain sensible parts if higher debug levels are used.) Regards, Bernhard -- www.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, Dr. Jan-Oliver Wagner -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: This is a digitally signed message part. URL: From wk at gnupg.org Mon Sep 27 19:37:31 2021 From: wk at gnupg.org (Werner Koch) Date: Mon, 27 Sep 2021 19:37:31 +0200 Subject: Error messages reconfiguring an OpenPGP smartcard In-Reply-To: (Borden via Gnupg-users's message of "Sat, 4 Sep 2021 12:11:34 +0200 (CEST)") References: Message-ID: <87v92l7wdg.fsf@wheatstone.g10code.de> On Sat, 4 Sep 2021 12:11, Borden said: > According to gpg --card-status, I have an OpenPGP card v. 2.1 made by > LogoEmail (that's not from whom I bought it, so I'm not sure if the Note that re-configuring a card is only possible with certain cards; it is an optional feature of the specification. I don't know the card from www.scardsolutions.com - you may want to ask them what they implement. If gpg --card-status -v does not hsow any hints and you have the time, you can add some debugging options: Add these lines to ~/.gnupg/scdameon.conf: --8<---------------cut here---------------start------------->8--- log-file /some/where/scd.log verbose debug ipc,reader,cardio --8<---------------cut here---------------end--------------->8--- and gpgconf --kill scdaeemon then try again and have a look at the log file. We might be able to help anlyzing the log but we would see the PINs etc. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From borden_c at tutanota.com Tue Sep 28 02:53:57 2021 From: borden_c at tutanota.com (Borden) Date: Tue, 28 Sep 2021 02:53:57 +0200 (CEST) Subject: Error messages reconfiguring an OpenPGP smartcard In-Reply-To: <87v92l7wdg.fsf@wheatstone.g10code.de> References: <87v92l7wdg.fsf@wheatstone.g10code.de> Message-ID: Thank you for the feedback and suggestions. As happens in most open source software, a few updates and weeks later, key regeneration worked just fine. So the error may have been some library mismatch. Updating the beginner documentation with these debugging suggestions may divert some amateurs like me from bothering the list. I didn't come across these suggestions in my search. In fact, it may be worthwhile to update the code proper to suggest these debugging options when it throws general errors - since it's evident that the information I posted wasn't all that helpful in troubleshooting the problem. With thanks, From bernhard at intevation.de Tue Sep 28 17:39:29 2021 From: bernhard at intevation.de (Bernhard Reiter) Date: Tue, 28 Sep 2021 17:39:29 +0200 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page Message-ID: <202109281739.29873.bernhard@intevation.de> Hi All, the https://wiki.gnupg.org/WKD page got longer over time and thus should better be split up to help people find what they are interested in. Thus I've started with restructuring and found it cannot be done in one step. New is https://wiki.gnupg.org/WKD/forUsers which should address WKD from the users perspective. It has a principle list of what to look for with email clients and email providers now. It will later link an annotated list of clients and providers (once they get properly put in a good place). Feedback (and help) is always appreciated. :) Best Regards, Bernhard ps.: Christoph will probably help me with updating the wiki as he will write his bachelor thesis about how to improve the usage of WKD. -- www.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, Dr. Jan-Oliver Wagner -------------- 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 vesely at tana.it Wed Sep 29 20:26:02 2021 From: vesely at tana.it (Alessandro Vesely) Date: Wed, 29 Sep 2021 20:26:02 +0200 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page In-Reply-To: <202109281739.29873.bernhard@intevation.de> References: <202109281739.29873.bernhard@intevation.de> Message-ID: <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> On Tue 28/Sep/2021 17:39:29 +0200 Bernhard Reiter wrote: > Feedback (and help) is always appreciated.:) I'm not sure if WKD/forHosts would be a better location than WKDHosting. Anyway, I'd publish the test suggested by Alissa on this list on 8 July 2019: gpg --homedir "$(mktemp -d)" --locate-keys hi at alyssa.is The address https://www.ietf.org/id/draft-koch-openpgp-webkey-service.txt, near the bottom of the page yields 404. Please use: https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service Keep up the good work! Ale -- From mailinglist at chiraag.me Thu Sep 30 14:17:37 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Thu, 30 Sep 2021 12:17:37 +0000 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page In-Reply-To: <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> References: <202109281739.29873.bernhard@intevation.de> <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> Message-ID: 12021/06/31 06:01.41 ?????, Alessandro Vesely via Gnupg-users ??????: > On Tue 28/Sep/2021 17:39:29 +0200 Bernhard Reiter wrote: > > Feedback (and help) is always appreciated.:) > > > I'm not sure if WKD/forHosts would be a better location than WKDHosting. > > Anyway, I'd publish the test suggested by Alissa on this list on 8 July 2019: > > gpg --homedir "$(mktemp -d)" --locate-keys hi at alyssa.is > Hmm, this is odd. I setup WKD as detailed on the https://wiki.gnupg.org/WKDHosting (using the openpgpkey subdomain), currently only for one address on my domain (spam at chiraag.me). Opening the file directly in a web browser does work, so the file is at the correct path with the correct (I presume) permissions. However, running the test given here does _not_ work and fails with the debugging output I've attached. Any ideas? Thanks, Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [no clock] start gpg: DBG: fd_cache_invalidate (/tmp/tmp.apCYUlb83x/pubring.kbx) gpg: DBG: iobuf-1.0: open '/tmp/tmp.apCYUlb83x/pubring.kbx' desc=file_filter(fd) fd=3 gpg: DBG: iobuf-1.0: close 'file_filter(fd)' gpg: DBG: /tmp/tmp.apCYUlb83x/pubring.kbx: close fd/handle 3 gpg: DBG: fd_cache_close (/tmp/tmp.apCYUlb83x/pubring.kbx) new slot created gpg: DBG: iobuf-*.*: ioctl '/tmp/tmp.apCYUlb83x/pubring.kbx' invalidate gpg: DBG: fd_cache_invalidate (/tmp/tmp.apCYUlb83x/pubring.kbx) gpg: DBG: did (/tmp/tmp.apCYUlb83x/pubring.kbx) gpg: keybox '/tmp/tmp.apCYUlb83x/pubring.kbx' created gpg: /tmp/tmp.apCYUlb83x/trustdb.gpg: trustdb created gpg: DBG: [no clock] keydb_new gpg: DBG: [no clock] keydb_search enter gpg: DBG: keydb_search: 1 search descriptions: gpg: DBG: keydb_search 0: SUBSTR: 'spam at chiraag.me' gpg: DBG: internal_keydb_search: searching keybox (resource 0 of 1) gpg: DBG: internal_keydb_search: searched keybox (resource 0 of 1) => EOF gpg: DBG: [no clock] keydb_search leave (not found) gpg: DBG: chan_5 <- # Home: /tmp/tmp.apCYUlb83x gpg: DBG: chan_5 <- # Config: /tmp/tmp.apCYUlb83x/dirmngr.conf gpg: DBG: chan_5 <- OK Dirmngr 2.3.1 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_5 -> GETINFO version gpg: DBG: chan_5 <- D 2.3.1 gpg: DBG: chan_5 <- OK gpg: DBG: chan_5 -> WKD_GET -- spam at chiraag.me gpg: DBG: chan_5 <- S SOURCE https://openpgpkey.chiraag.me gpg: DBG: chan_5 <- ERR 167772218 No data gpg: error retrieving 'spam at chiraag.me' via WKD: No data gpg: error reading key: No data gpg: DBG: chan_5 -> BYE gpg: DBG: [no clock] keydb_release gpg: DBG: [no clock] stop gpg: keydb: handles=1 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=1 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: objcache: keys=0/0/0 chains=0,0..0 buckets=0/0 attic=0 gpg: objcache: uids=0/0/0 chains=0,0..0 buckets=0/0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/65536 bytes in 0 blocks -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 713 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 andrewg at andrewg.com Thu Sep 30 16:14:51 2021 From: andrewg at andrewg.com (Andrew Gallagher) Date: Thu, 30 Sep 2021 15:14:51 +0100 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page In-Reply-To: References: <202109281739.29873.bernhard@intevation.de> <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> Message-ID: <0db31f5a-a057-f5d0-37c3-b83e60fca85c@andrewg.com> On 30/09/2021 13:17, ?????? ?????? via Gnupg-users wrote: > Hmm, this is odd. I setup WKD as detailed on thehttps://wiki.gnupg.org/WKDHosting (using the openpgpkey subdomain), currently only for one address on my domain (spam at chiraag.me). Opening the file directly in a web browser does work, so the file is at the correct path with the correct (I presume) permissions. However, running the test given here does_not_ work and fails with the debugging output I've attached. What URL are you expecting it to be found at? Did you hash the full email address or just the bit before the @? A -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xFB73E21AF1163937.asc Type: application/pgp-keys Size: 34134 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mailinglist at chiraag.me Thu Sep 30 23:19:43 2021 From: mailinglist at chiraag.me (=?utf-8?B?4LKa4LK/4LKw4LK+4LKX4LONIOCyqOCyn+CysOCyvuCynOCzjQ==?=) Date: Thu, 30 Sep 2021 21:19:43 +0000 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page In-Reply-To: References: <202109281739.29873.bernhard@intevation.de> <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> Message-ID: 12021/06/32 07:17.95 ?????, Phil Pennock ??????: > On 2021-09-30 at 12:17 +0000, ?????? ?????? via Gnupg-users wrote: > > Hmm, this is odd. I setup WKD as detailed on the https://wiki.gnupg.org/WKDHosting (using the openpgpkey subdomain), currently only for one address on my domain (spam at chiraag.me). Opening the file directly in a web browser does work, so the file is at the correct path with the correct (I presume) permissions. However, running the test given here does _not_ work and fails with the debugging output I've attached. > > > > Any ideas? > > Do you have user-agent filtering in your web-server? > > 2021-09-30 17:11:35 dirmngr[733043.6] error accessing 'https://openpgpkey.chiraag.me/.well-known/openpgpkey/chiraag.me/hu/55caf3anhb75xpzx9m6hgw6589ozf1b9?l=spam': http status 403 > > Running: > > curl -fSs 'https://openpgpkey.chiraag.me/.well-known/openpgpkey/chiraag.me/hu/55caf3anhb75xpzx9m6hgw6589ozf1b9?l=spam' | gpg --import > > works. So you return the data just fine to curl, but when dirmngr asks > for it, it's getting a "403 Forbidden" response. > > That smells to me of a web-server which is trying to block user-agents > it dislikes. This isn't certain, but that's where I'd start looking. > > -Phil That is very helpful! I'll have to check with my hoster to figure out what's going on, thanks :) - Chiraag -- ?????? ?????? Pronouns: he/him/his -------------- next part -------------- A non-text attachment was scrubbed... Name: publickey - mailinglist at chiraag.me - b0c8d720.asc Type: application/pgp-keys Size: 713 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 gnupg-users at spodhuis.org Thu Sep 30 23:13:51 2021 From: gnupg-users at spodhuis.org (Phil Pennock) Date: Thu, 30 Sep 2021 17:13:51 -0400 Subject: WKD docs on the wiki, restructuring. Feedback on forUsers page In-Reply-To: References: <202109281739.29873.bernhard@intevation.de> <1ace12f3-1166-97d0-8745-5a827f8fa38d@tana.it> Message-ID: On 2021-09-30 at 12:17 +0000, ?????? ?????? via Gnupg-users wrote: > Hmm, this is odd. I setup WKD as detailed on the https://wiki.gnupg.org/WKDHosting (using the openpgpkey subdomain), currently only for one address on my domain (spam at chiraag.me). Opening the file directly in a web browser does work, so the file is at the correct path with the correct (I presume) permissions. However, running the test given here does _not_ work and fails with the debugging output I've attached. > > Any ideas? Do you have user-agent filtering in your web-server? 2021-09-30 17:11:35 dirmngr[733043.6] error accessing 'https://openpgpkey.chiraag.me/.well-known/openpgpkey/chiraag.me/hu/55caf3anhb75xpzx9m6hgw6589ozf1b9?l=spam': http status 403 Running: curl -fSs 'https://openpgpkey.chiraag.me/.well-known/openpgpkey/chiraag.me/hu/55caf3anhb75xpzx9m6hgw6589ozf1b9?l=spam' | gpg --import works. So you return the data just fine to curl, but when dirmngr asks for it, it's getting a "403 Forbidden" response. That smells to me of a web-server which is trying to block user-agents it dislikes. This isn't certain, but that's where I'd start looking. -Phil