From maxime.deroucy at gmail.com Tue Dec 5 00:00:39 2023 From: maxime.deroucy at gmail.com (maxime.deroucy at gmail.com) Date: Tue, 05 Dec 2023 00:00:39 +0100 Subject: prefered key/subkey for decryption Message-ID: <5c34216da5448bbb6e4462952e85c6e87113f268.camel@gmail.com> Hello, Here is my setup: * I have a primary key, which I keep in a secure location. * from this primary key I created many subkeys, one for each of my tool (laptop, cellphone, server, etc.) * I also have a yubikey, which hold one of my secret subkey. On my laptop I have only 2 secret subkeys available: * a "local" one (on my keyring, on my disk), using rsa4096 * the one on my yubikey (only when my yubikey is plugged), using rsa2048 I use password-store as a password manager. All my password/files are encrypted with all my private subkey (reminder: all subkeys are derived from the same primary key). So when I try to decrypt one of my password-store password (when I try to `--decrypt` on of the `~/.password-store/?` files), gnupg can use either my "local" subkey or the "yubikey" one. When I was using gnupg 2.2.41 the first subkey that was tried is the yubikey one. I think it was because it's was the first subkey of the list used when I --encrypt the password/files. Which is what I prefer (because the "local" one is protected by a much longer password). On gnupg 2.4.3 the fist subkey tried is the "local" one. I think that it's because the "local" subkey is rsa4096, which is more secure than rsa2048 (the yubikey subkey). I would like gnupg to try the yubikey subkey first. (I would like the "local" subkey to be tried only when the yubikey isn't plugged). I found --personal-cipher-preferences, --personal-digest-preferences and --personal-compress-preferences but as both subkeys are RSA? it doesn't help. Is it possible ? Is there an option I missed ? What do you suggest ? Do you need more informations ? -- Thank you in advance Regards From wk at gnupg.org Tue Dec 5 10:11:52 2023 From: wk at gnupg.org (Werner Koch) Date: Tue, 05 Dec 2023 10:11:52 +0100 Subject: prefered key/subkey for decryption In-Reply-To: <5c34216da5448bbb6e4462952e85c6e87113f268.camel@gmail.com> (Maxime de Roucy via Gnupg-users's message of "Tue, 05 Dec 2023 00:00:39 +0100") References: <5c34216da5448bbb6e4462952e85c6e87113f268.camel@gmail.com> Message-ID: <8734whvwrr.fsf@jacob.g10code.de> Hi! On Tue, 5 Dec 2023 00:00, Maxime de Roucy said: > On gnupg 2.4.3 the fist subkey tried is the "local" one. > I think that it's because the "local" subkey is rsa4096, which is more secure > than rsa2048 (the yubikey subkey). No, there is such logic. > I found --personal-cipher-preferences, --personal-digest-preferences and > --personal-compress-preferences but as both subkeys are RSA? it doesn't help. That does not help with decryption. In general this problem shows up if you receive a lot of mails using an anonymous recipients (--throw-keyids) and gpg ask you to insert all your cards one after the ther. We have this TODO item in the code: /* FIXME: The list needs to be sorted so that we try the keys in * an appropriate order. For example: * - On-disk keys w/o protection * - On-disk keys with a cached passphrase * - On-card keys of an active card * - On-disk keys with protection * - On-card keys from cards which are not plugged it. Here a * cancel-all button should stop asking for other cards. * Without any anonymous keys the sorting can be skipped. */ Your use case is very similar and such a sorting would also be helpful. Another way to implement this might be by using a similar thing to what we allow for ssh-keys (see gnupg/agent/keyformat.txt) in the private key files: *** Use-for-ssh If given and the value is "yes" or "1" the key is allowed for use by gpg-agent's ssh-agent implementation. This is thus the same as putting the keygrip into the 'sshcontrol' file. Only one such item should exist. If another non-zero value between 1 and 99999 is used, this is taken to establish the order in which the keys are returned to ssh; lower numbers are returned first. If a negative value is used this overrides currently active (inserted) cards and thus allows to prefer on-disk keys over inserted cards. A value of -1 has the highest priority; values are capped at -999 and have a lower priority but still above the positive values, inserted cards or the order in sshcontrol. Sorry, for not having a better answer. > (reminder: all subkeys are derived from the same primary key). Sure that you derived them? What we do is to bind subkeys to a primary key and then the sender selects the latest valid subkey for encryption. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From ch at bitfehler.net Wed Dec 6 12:29:36 2023 From: ch at bitfehler.net (Conrad Hoffmann) Date: Wed, 6 Dec 2023 12:29:36 +0100 Subject: Disable keyboxd system-wide? Message-ID: <03edd3b2-fb17-4858-bf6c-b6c88e34ae15@bitfehler.net> Hi all, I am encountering a weird issue with keyboxd. It only happens in combination with fakeroot and systemd, so I am not sure what to blame it on. But as temporary workaround, I would be interested if there is a way to disable keyboxd system-wide (as opposed to ~/.gnupg/common.conf), so unsuspecting new users do not run into this? Thanks a lot, Conrad From wk at gnupg.org Thu Dec 7 09:29:43 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2023 09:29:43 +0100 Subject: Disable keyboxd system-wide? In-Reply-To: <03edd3b2-fb17-4858-bf6c-b6c88e34ae15@bitfehler.net> (Conrad Hoffmann via Gnupg-users's message of "Wed, 6 Dec 2023 12:29:36 +0100") References: <03edd3b2-fb17-4858-bf6c-b6c88e34ae15@bitfehler.net> Message-ID: <87wmtqtnyg.fsf@jacob.g10code.de> Hi! On Wed, 6 Dec 2023 12:29, Conrad Hoffmann said: > it on. But as temporary workaround, I would be interested if there is > a way to disable keyboxd system-wide (as opposed to > ~/.gnupg/common.conf), so unsuspecting new users do not run into this? If you put this --8<---------------cut here---------------start------------->8--- [ignore] use-keyboxd [-ignore] --8<---------------cut here---------------end--------------->8--- int /etc/gnupg/common.conf the use-keyboxd option in the ~/.gnupg/common.conf file should be ignored. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From ch at bitfehler.net Thu Dec 7 12:07:24 2023 From: ch at bitfehler.net (Conrad Hoffmann) Date: Thu, 7 Dec 2023 12:07:24 +0100 Subject: Disable keyboxd system-wide? In-Reply-To: <87wmtqtnyg.fsf@jacob.g10code.de> References: <03edd3b2-fb17-4858-bf6c-b6c88e34ae15@bitfehler.net> <87wmtqtnyg.fsf@jacob.g10code.de> Message-ID: <7e7d911e-d9eb-44d1-b8c4-0c83322006ee@bitfehler.net> On 12/7/23 09:29, Werner Koch wrote: > Hi! > > On Wed, 6 Dec 2023 12:29, Conrad Hoffmann said: >> it on. But as temporary workaround, I would be interested if there is >> a way to disable keyboxd system-wide (as opposed to >> ~/.gnupg/common.conf), so unsuspecting new users do not run into this? > > If you put this > > --8<---------------cut here---------------start------------->8--- > [ignore] > use-keyboxd > [-ignore] > --8<---------------cut here---------------end--------------->8--- > > int /etc/gnupg/common.conf the use-keyboxd option in the > ~/.gnupg/common.conf file should be ignored. Thanks a lot, that did the trick. I only got to an empty /etc/gnupg/common.conf, but was not yet aware of the [ignore] syntax, very useful. Cheers, Conrad From wk at gnupg.org Thu Dec 7 13:52:21 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 07 Dec 2023 13:52:21 +0100 Subject: Disable keyboxd system-wide? In-Reply-To: <7e7d911e-d9eb-44d1-b8c4-0c83322006ee@bitfehler.net> (Conrad Hoffmann's message of "Thu, 7 Dec 2023 12:07:24 +0100") References: <03edd3b2-fb17-4858-bf6c-b6c88e34ae15@bitfehler.net> <87wmtqtnyg.fsf@jacob.g10code.de> <7e7d911e-d9eb-44d1-b8c4-0c83322006ee@bitfehler.net> Message-ID: <87fs0etbsq.fsf@jacob.g10code.de> On Thu, 7 Dec 2023 12:07, Conrad Hoffmann said: > Thanks a lot, that did the trick. I only got to an empty > /etc/gnupg/common.conf, but was not yet aware of the [ignore] syntax, > very useful. There is also a --8<---------------cut here---------------start------------->8--- [force] some-option [-force] --8<---------------cut here---------------end--------------->8--- Which uses the option but ignore them in the ~/.gnupg conf files. FWIW, you can also do things like --8<---------------cut here---------------start------------->8--- # Options to handle embedded keys [getreg flag \Software\GNU\GnuPG:AutoKeyImport] [if $flag != 0] auto-key-import [fi] [getreg flag \Software\GNU\GnuPG:IncludeKeyBlock] [if $flag != 0] include-key-block [fi] --8<---------------cut here---------------end--------------->8--- To read values from the Windows Registry or with getenv from the environment. Another hack is this: --8<---------------cut here---------------start------------->8--- # From 2024-01-01 on we require at least rsa3000 [if $_epoch >= 1704067200 ] min-rsa-length 3000 [fi] --8<---------------cut here---------------end--------------->8--- Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From dan.list at brilhante.top Fri Dec 8 21:12:29 2023 From: dan.list at brilhante.top (Daniel Cerqueira) Date: Fri, 08 Dec 2023 20:12:29 +0000 Subject: Contributing: how to modify the man page Message-ID: <87sf4ca1xu.fsf@brilhante.top> I am about to contribute some simple code into GnuPG. I want my commit to be complete, so I am looking to also modify the gpg info and the gpg man page. I would like to know which files do I need to edit in order to edit the gpg man page and the gpg info page. Thanks From sergio.borghese at gmail.com Sat Dec 9 14:12:38 2023 From: sergio.borghese at gmail.com (sergio borghese) Date: Sat, 9 Dec 2023 14:12:38 +0100 Subject: gnupg + TPM 2.0 support request Message-ID: Hello Everyone, I would like to protect my pgp keys using the TPM2 installed on my laptop I was hence reading this article: https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html but I'm not able to get the `card-no: TPM-Protected` attribute for my key so I guess something is going wrong and the key is not being protected using the TPM I opened a support request also here: https://crypto.stackexchange.com/questions/108897/cannot-protect-gpg-key-using-tpm2-on-ubuntu-22-04 Please find below the info on what I did I'm trying to protect a GPG key using the TPM2 available on my laptop, but I'm not having any success. Probably I'm doing something wrong, but I cannot figure out what this is. My system is running `Ubuntu 22.04` Here what I did: ## Verify TPM2 is available and enabled in my Linux system: - check tpm hw is detected at boot time: ``` $ dmesg | grep -i tpm [ 0.327325] kernel: tpm_tis STM0125:00: 2.0 TPM (device-id 0x0, rev-id 78) ``` - check tpm devices are available and have the correct owners: ``` $ ls -l /dev/tpm* crw-rw---- 1 tss tss 10, 224 nov 27 07:42 /dev/tpm0 crw-rw---- 1 tss tss 253, 65536 nov 27 07:42 /dev/tpmrm0 ``` - my user is member of the `tss` group - installed the following packages: ``` clevis-tpm2 libnatpmp1 libtss2-tcti-swtpm0 tpm-udev tpm2-abrmd tpm2-openssl tpm2-tools libtpm2-pkcs11-tools libtpm2-pkcs11-1 ``` - loaded the tpm module: ``` $ modprobe tpm_tis_spi $ lsmod | grep tpm tpm_tis_spi 20480 0 ``` - check the tpm broker is up and running ``` root at NR054-UB:/lib/modules/6.2.0-37-generic# systemctl status tpm2-abrmd ? tpm2-abrmd.service - TPM2 Access Broker and Resource Management Daemon Loaded: loaded (/lib/systemd/system/tpm2-abrmd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2023-11-27 07:42:29 CET; 4 days ago Main PID: 1086 (tpm2-abrmd) Tasks: 6 (limit: 18082) Memory: 1.4M CPU: 9.563s CGroup: /system.slice/tpm2-abrmd.service ??1086 /usr/sbin/tpm2-abrmd ``` I built gpg version `2.4` (as the default gpg version on `ubuntu 22.04` is `2.2`) and set the env variable `GNUPGHOME=~/gpg2.tmp/` to use a "clean" keyring ``` $ gpg2 --version gpg (GnuPG) 2.4.3 libgcrypt 1.10.2 Copyright (C) 2023 g10 Code GmbH License GNU GPL-3.0-or-later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Home: /home//gpg2.tmp 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 ``` ## Try to protect a test gpg key using TPM So far so good. As I got no relevant error or warning in setting up all the previous steps, I continued following the example from: [1] https://gnupg.org/blog/20210315-using-tpm-with-gnupg-2.3.html [2] https://www.monperrus.net/martin/7-things-to-do-with-your-TPM-on-Linux - started the tpm2daemon: ``` tpm2daemon --log-file ~/gpg2.tmp/tpm2daemon.log --daemon --debug-level 1000 ``` BUT, when I try move the key to the TPM I do not get the ` card-no: TPM-Protected ` attribute to the key ``` $ /opt/gpg24/bin/gpg2 --edit-key tpm.test at test.com gpg (GnuPG) 2.4.3; Copyright (C) 2023 g10 Code GmbH This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Secret key is available. sec rsa2048/2E0718AD3A17F52E created: 2023-12-02 expires: 2026-12-01 usage: SC trust: ultimate validity: ultimate [ultimate] (1). tpm.test at test.com gpg> keytotpm Really move the primary key? (y/N) y sec rsa2048/2E0718AD3A17F52E created: 2023-12-02 expires: 2026-12-01 usage: SC trust: ultimate validity: ultimate [ultimate] (1). tpm.test at test.com ``` What I'm I doing wrong? Any hint on how to debug this? Ciao e grazie Sergio -- preferisco ammazzare il tempo, preferisco sparare cazzate, preferisco fare esplodere una moda, preferisco morire d'amore. (Caparezza) -------------- next part -------------- An HTML attachment was scrubbed... URL: From verbuecheln at posteo.de Sat Dec 9 15:15:33 2023 From: verbuecheln at posteo.de (Stephan =?ISO-8859-1?Q?Verb=FCcheln?=) Date: Sat, 09 Dec 2023 14:15:33 +0000 Subject: gnupg + TPM 2.0 support request In-Reply-To: References: Message-ID: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> As far as I am aware, Debian and Ubuntu still have GnuPG 2.2 which does not have that feature yet. Regards -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: This is a digitally signed message part URL: From sergio.borghese at gmail.com Sun Dec 10 01:04:03 2023 From: sergio.borghese at gmail.com (sergio borghese) Date: Sun, 10 Dec 2023 01:04:03 +0100 Subject: gnupg + TPM 2.0 support request In-Reply-To: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> References: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> Message-ID: Hi Stephan, You are right actually, but I built gnupg 2.4 from the source code. I'm using the correct binary and also assured the gpg-agent used is the one built from version 2.4 The strange thing is that I get no error when editing the key and use the command keytotpm, but the key is not sealed Ciao e grazie Sergio On Sat 9 Dec 2023, 15:16 Stephan Verb?cheln via Gnupg-users, < gnupg-users at gnupg.org> wrote: > As far as I am aware, Debian and Ubuntu still have GnuPG 2.2 which does > not have that feature yet. > > Regards > _______________________________________________ > 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 wk at gnupg.org Sun Dec 10 10:29:39 2023 From: wk at gnupg.org (Werner Koch) Date: Sun, 10 Dec 2023 10:29:39 +0100 Subject: Contributing: how to modify the man page In-Reply-To: <87sf4ca1xu.fsf@brilhante.top> (Daniel Cerqueira via Gnupg-users's message of "Fri, 08 Dec 2023 20:12:29 +0000") References: <87sf4ca1xu.fsf@brilhante.top> Message-ID: <878r629zi4.fsf@jacob.g10code.de> Hi! > info and the gpg man page. I would like to know which files do I need to > edit in order to edit the gpg man page and the gpg info page. Both are build from the same texinfo source. That is gnupg/doc/gpg.texi or one of the other *texi files - some are include files. Shalom-Salam, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From sergio.borghese at gmail.com Sun Dec 10 16:55:48 2023 From: sergio.borghese at gmail.com (sergio borghese) Date: Sun, 10 Dec 2023 16:55:48 +0100 Subject: gnupg + TPM 2.0 support request In-Reply-To: References: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> Message-ID: Hello everyone, still trying to debug the interaction between my custom built gpg 2.4 and the tpm I manage to enable the gpg-agent log file and set the debug level to 5 (advanced) according to: https://www.gnupg.org/documentation/manuals/gnupg/Agent-Options.html#option-_002d_002dhomedir Actually what I see when I run the `keytotpm` is: ``` 2023-12-10 16:42:44 gpg-agent[357268] DBG: chan_10 <- KEYTOTPM FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B 2023-12-10 16:42:44 gpg-agent[357268] starting a new PIN Entry 2023-12-10 16:42:44 gpg-agent[357268] DBG: connection to PIN entry established 2023-12-10 16:42:44 gpg-agent[357268] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 357865 curses 1.2.1 /dev/pts/3 xterm-256color :0 20620/590201106/5 590201106/590200513 0 2023-12-10 16:42:44 gpg-agent[357268] DBG: chan_10 <- END 2023-12-10 16:42:49 gpg-agent[357268] no running /opt/gpg24/libexec/tpm2daemon daemon - starting it 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 <- OK GNU Privacy Guard's TPM2 server ready 2023-12-10 16:42:49 gpg-agent[357268] first connection to daemon /opt/gpg24/libexec/tpm2daemon established 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> GETINFO socket_name 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 <- ERR 268435731 Unknown IPC command 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> OPTION event-signal=12 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 <- OK 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> IMPORT 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 <- INQUIRE KEYDATA 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> [ 44 20 28 31 31 3a 70 72 69 76 61 74 65 2d 6b 65 ...(982 byte(s) skipped) ] 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> [ 44 20 c8 dc 76 ef 16 58 03 a0 29 29 29 00 ] 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 -> END 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_11 <- INQUIRE NEEDPIN Please enter the TPM Authorization passphrase for the key. 2023-12-10 16:42:49 gpg-agent[357268] starting a new PIN Entry 2023-12-10 16:42:49 gpg-agent[357268] DBG: connection to PIN entry established 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 357872 curses 1.2.1 /dev/pts/3 xterm-256color :0 20620/590201106/5 590201106/590200513 0 2023-12-10 16:42:49 gpg-agent[357268] DBG: chan_10 <- END 2023-12-10 16:42:51 gpg-agent[357268] starting a new PIN Entry 2023-12-10 16:42:51 gpg-agent[357268] DBG: connection to PIN entry established 2023-12-10 16:42:51 gpg-agent[357268] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 357874 curses 1.2.1 /dev/pts/3 xterm-256color :0 20620/590201106/5 590201106/590200513 0 2023-12-10 16:42:51 gpg-agent[357268] DBG: chan_10 <- END 2023-12-10 16:42:52 gpg-agent[357268] starting a new PIN Entry 2023-12-10 16:42:52 gpg-agent[357268] DBG: connection to PIN entry established 2023-12-10 16:42:52 gpg-agent[357268] DBG: chan_10 -> INQUIRE PINENTRY_LAUNCHED 357876 curses 1.2.1 /dev/pts/3 xterm-256color :0 20620/590201106/5 590201106/590200513 0 2023-12-10 16:42:52 gpg-agent[357268] DBG: chan_10 <- END 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_11 -> D pippero 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_11 -> END 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_11 <- [ 44 20 28 31 30 3a 31 30 37 33 37 34 31 38 32 35 ...(524 byte(s) skipped) ] 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_11 <- OK 2023-12-10 16:42:55 gpg-agent[357268] updating regular key file '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key' by a shadow key inhibited 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_10 -> OK 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_10 <- KEYINFO FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_12 -> KEYINFO --list 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_12 <- OK 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_10 -> S KEYINFO FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B D - - - P - - - 2023-12-10 16:42:55 gpg-agent[357268] DBG: chan_10 -> OK ``` What seems interesting to me are the following log entries: ``` 2023-12-10 16:46:24 gpg-agent[358316] DBG: chan_11 <- ERR 268435731 Unknown IPC command ``` and ``` 2023-12-10 16:46:30 gpg-agent[358316] updating regular key file '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key' by a shadow key inhibited ``` Does anyone know what the above error means exactly and how to solve it? Ciao e grazie Sergio On Sun, Dec 10, 2023 at 1:04?AM sergio borghese wrote: > Hi Stephan, > > You are right actually, but I built gnupg 2.4 from the source code. I'm > using the correct binary and also assured the gpg-agent used is the one > built from version 2.4 > > The strange thing is that I get no error when editing the key and use the > command keytotpm, but the key is not sealed > > Ciao e grazie > Sergio > > > On Sat 9 Dec 2023, 15:16 Stephan Verb?cheln via Gnupg-users, < > gnupg-users at gnupg.org> wrote: > >> As far as I am aware, Debian and Ubuntu still have GnuPG 2.2 which does >> not have that feature yet. >> >> Regards >> _______________________________________________ >> Gnupg-users mailing list >> Gnupg-users at gnupg.org >> https://lists.gnupg.org/mailman/listinfo/gnupg-users >> > -- preferisco ammazzare il tempo, preferisco sparare cazzate, preferisco fare esplodere una moda, preferisco morire d'amore. (Caparezza) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Mon Dec 11 01:33:02 2023 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 11 Dec 2023 09:33:02 +0900 Subject: gnupg + TPM 2.0 support request In-Reply-To: References: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> Message-ID: <87bkaxk281.fsf@akagi.fsij.org> Hello, sergio borghese wrote: > 2023-12-10 16:46:24 gpg-agent[358316] DBG: chan_11 <- ERR 268435731 Unknown > IPC command This is no harm. TPM2d doesn't support GETINFO command. > 2023-12-10 16:46:30 gpg-agent[358316] updating regular key file > '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key' > by a shadow key inhibited I fixed this problem in the repo of GnuPG 2.4/master, I suppose. It's the commit 9909f622f for 2.4. The check was introduced (by the commit a1015bf2f) (in GnuPG 2.4.2), which caused the problem for KEYTOTPM handling of gpg-agent. Then fixed in repo (will be in GnuPG 2.4.4). -- From sergio.borghese at gmail.com Mon Dec 11 10:15:17 2023 From: sergio.borghese at gmail.com (sergio borghese) Date: Mon, 11 Dec 2023 10:15:17 +0100 Subject: gnupg + TPM 2.0 support request In-Reply-To: <87bkaxk281.fsf@akagi.fsij.org> References: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> <87bkaxk281.fsf@akagi.fsij.org> Message-ID: Hi Niibe, Thanks a lot for the info and help So, if I get this right, I just need to get the latest master and rebuild the gnupg sw. Is this correct? Will try and send an update to the ML to share the results with everyone Ciao e grazie Sergio On Mon, Dec 11, 2023 at 1:33?AM NIIBE Yutaka wrote: > Hello, > > sergio borghese wrote: > > 2023-12-10 16:46:24 gpg-agent[358316] DBG: chan_11 <- ERR 268435731 > Unknown > > IPC command > > This is no harm. TPM2d doesn't support GETINFO command. > > > 2023-12-10 16:46:30 gpg-agent[358316] updating regular key file > > > '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key' > > by a shadow key inhibited > > I fixed this problem in the repo of GnuPG 2.4/master, I suppose. It's > the commit 9909f622f for 2.4. > > The check was introduced (by the commit a1015bf2f) (in GnuPG 2.4.2), > which caused the problem for KEYTOTPM handling of gpg-agent. Then fixed > in repo (will be in GnuPG 2.4.4). > -- > -- preferisco ammazzare il tempo, preferisco sparare cazzate, preferisco fare esplodere una moda, preferisco morire d'amore. (Caparezza) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-gnumlists at wisemo.com Thu Dec 14 16:19:10 2023 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Thu, 14 Dec 2023 16:19:10 +0100 Subject: gpgsm: ksba_cms_parse failed: Broken pipe Message-ID: <9df606cc-96b0-a67a-496c-29cf7cf58b2c@wisemo.com> Dear list, I am using gpgsm in a script for its ability to efficiently process CMS format messages larger than available memory.? However after a recent script change, it now fails every time on previously accepted data with error messages that are essentialy gpg implementation internals gobbledygook. Versions involved (distribution supplied builds, so not latest upstram source): $ uname -a Linux 5.10.0-0.deb10.21-amd64 #1 SMP Debian 5.10.162-1~deb10u1 (2023-02-14) x86_64 GNU/Linux $ gpgsm --version gpgsm (GnuPG) 2.2.27 libgcrypt 1.8.4 libksba 1.3.5-unknown 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/me/.gnupg Supported algorithms: Cipher: 3DES, AES128, AES192, AES256, SERPENT128, SERPENT192, SERPENT256, SEED, CAMELLIA128, CAMELLIA192, CAMELLIA256 Pubkey: RSA, ECC Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224, WHIRLPOOL Command lines (from a bash script, sorry for long lines): $ # Note: $infl is archived gzipped DER-encoded CMS SignedData of privacy-sensitive data ? #?????? $DSTAMP is the date/time when the signature is supposed to be valid ? #?????? $fprint is the fingerprint of the only allowed signer certificate ? #?????? $wrkdir is a unique temporary directory. ? #?????? faketime, gpgsm, grep, zcat, cat and false are the usual GNU or distribution tools ? #?????? shell is GNU bash ? #?????? non-debug environment is a cron job ? zcat ${infl} | ??? faketime "${DSTAMP}" gpgsm --verify --validation-model shell --assume-binary --status-fd 3 --output - - 3>${wrkdir}/sigdec.status || : ? ( ( grep "^\[GNUPG:\] \(GOOD\|EXPKEY\)SIG ${fprint}" ${wrkdir}/sigdec.status && ????? grep "^\[GNUPG:\] VALIDSIG ${fprint}" ${wrkdir}/sigdec.status ) >/dev/null || ??? ( cat ${wrkdir}/sigdec.status >&2 ; false ) ) Message on stderr: ??? gpgsm: ksba_cms_parse failed: Broken pipe Message on status-fd (copied to stderr by cat command) ??? [GNUPG:] ERROR verify.leave 32877 So what do these error messages mean, and why aren't they in they described in the documentation (info and man)? Which of the inputs was being truncated on the way to the that parsing function? P.S. It would be much easier if the gpgsm code could be used standalone like the old gpg1 could, with no entanglement to pinentry, dirmgr status-fd protocol etc. etc.? scripted signing and verification of computer generated data is not suited to a human-centric user interface. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From wk at gnupg.org Thu Dec 14 19:43:45 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 14 Dec 2023 19:43:45 +0100 Subject: gpgsm: ksba_cms_parse failed: Broken pipe In-Reply-To: <9df606cc-96b0-a67a-496c-29cf7cf58b2c@wisemo.com> (Jakob Bohm via Gnupg-users's message of "Thu, 14 Dec 2023 16:19:10 +0100") References: <9df606cc-96b0-a67a-496c-29cf7cf58b2c@wisemo.com> Message-ID: <871qbo8w0u.fsf@jacob.g10code.de> Hi! On Thu, 14 Dec 2023 16:19, Jakob Bohm said: > ? zcat ${infl} | > ??? faketime "${DSTAMP}" gpgsm --verify --validation-model shell > --assume-binary --status-fd 3 --output - - 3>${wrkdir}/sigdec.status > || : > gpgsm: ksba_cms_parse failed: Broken pipe gpgsm expects more data but zcat already sent its EOF. This might be due to a broken ASN.1 structure which announced N bytes but gpgsm was not able to read thes N bytes. CMS chunks up the data so that you can have a very long stream of data. (I have sometimes seen chunks of just one byte). That is the error message you meant, or did you see more? Adding --verbose is often very helpful. > Message on status-fd (copied to stderr by cat command) > > ??? [GNUPG:] ERROR verify.leave 32877 This is the machine interface; which you rightfully parse. $ gpg-error 32877 32877 = (0, 32877) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_EPIPE) = (Unspecified source, Broken pipe) verify.leave helps us to locate the place where the error as emitted: Here is is at the end of gpgsm_verify function but unfortunately we can't get the offset of the input data where it stopped parsing. You may use "--debug hashing" to write a file with the data hashed (i.e. what is verified). That gives an indication where inthe stream the error occured. Anothyer useful tool is the venerable dumpasn1 tool which you could use instead of gpgsm to find error in the input data structure. > Which of the inputs was being truncated on the way to the that > parsing function? The decompressed $infl . > It would be much easier if the gpgsm code could be used standalone > like the old gpg1 could, with no entanglement to pinentry, dirmgr Yeah But for security reasons we have separated tasks in a way similar to what postfix does. > status-fd protocol etc. etc.? scripted signing and verification of > computer generated data is not suited to a human-centric user Right, it is a machine interface. For gpg we have the extra tool gpgv to make verification against a known set of keys easy. And recently we added --assert-signer which basically does the same. There has never been a demand to have a dedicated verification tool for CMS but I can imagine to add a --assert-signer also to gpgsm. Your use of faketime is interesting ;-) Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From jb-gnumlists at wisemo.com Sat Dec 16 00:35:39 2023 From: jb-gnumlists at wisemo.com (Jakob Bohm) Date: Sat, 16 Dec 2023 00:35:39 +0100 Subject: gpgsm: ksba_cms_parse failed: Broken pipe In-Reply-To: <871qbo8w0u.fsf@jacob.g10code.de> References: <9df606cc-96b0-a67a-496c-29cf7cf58b2c@wisemo.com> <871qbo8w0u.fsf@jacob.g10code.de> Message-ID: Hi, On 2023-12-14 19:43, Werner Koch wrote: > On Thu, 14 Dec 2023 16:19, Jakob Bohm said: > >> ? zcat ${infl} | >> ??? faketime "${DSTAMP}" gpgsm --verify --validation-model shell >> --assume-binary --status-fd 3 --output - - 3>${wrkdir}/sigdec.status >> || : > > >> gpgsm: ksba_cms_parse failed: Broken pipe > > gpgsm expects more data but zcat already sent its EOF. This might be > due to a broken ASN.1 structure which announced N bytes but gpgsm was > not able to read thes N bytes. CMS chunks up the data so that you can > have a very long stream of data. (I have sometimes seen chunks of just > one byte). > > That is the error message you meant, or did you see more? Adding > --verbose is often very helpful. > >> Message on status-fd (copied to stderr by cat command) >> >> ??? [GNUPG:] ERROR verify.leave 32877 > > This is the machine interface; which you rightfully parse. > > $ gpg-error 32877 > 32877 = (0, 32877) = (GPG_ERR_SOURCE_UNKNOWN, GPG_ERR_EPIPE) = (Unspecified source, Broken pipe) > > verify.leave helps us to locate the place where the error as emitted: > Here is is at the end of gpgsm_verify function but unfortunately we > can't get the offset of the input data where it stopped parsing. You > may use "--debug hashing" to write a file with the data hashed > (i.e. what is verified). That gives an indication where inthe stream > the error occured. > > Anothyer useful tool is the venerable dumpasn1 tool which you could use > instead of gpgsm to find error in the input data structure. > >> Which of the inputs was being truncated on the way to the that >> parsing function? > > The decompressed $infl . > Thanks for this decoding, based on this I did further testing and found the following: 1. The input file was DER encoded, not BER, so no BER chunking, just a single 1.3 GiB OCTET STRING as inner data. (Checked with dumpasn1 and a lot of patience), and was actually OK. 2. The same error messages are produced when the /output/ hits a broken pipe such as piping into head(1) or having a script typo (my case). So based on 2, it would have been much more helpful if the error message had stated if the "parser" hit an I/O error on output or input, such as "output: -: Broken pipe" while the status-fd stream could have said [GNUPG:] ERROR verify.leave 32877 output - E_PIPE Preferably also change GPG_ERR_SOURCE_UNKNOWN to some other constant indicating output failure. >> It would be much easier if the gpgsm code could be used standalone >> like the old gpg1 could, with no entanglement to pinentry, dirmgr > > Yeah But for security reasons we have separated tasks in a way similar > to what postfix does. > >> status-fd protocol etc. etc.? scripted signing and verification of >> computer generated data is not suited to a human-centric user > > Right, it is a machine interface. For gpg we have the extra tool gpgv > to make verification against a known set of keys easy. And recently we > added --assert-signer which basically does the same. There has never > been a demand to have a dedicated verification tool for CMS but I can > imagine to add a --assert-signer also to gpgsm. My point was that status-fd isn't an easy interface to script against, but your bug tracker already contains a rejected task to simplify things. > > Your use of faketime is interesting ;-) > I use faketime to reflect the age of the data being processed, as the certificates are rotated as necessary and the overall scripts contain a table mapping origin dates to certificates and cert validity ranges. Similar tricks may be needed to verify/decrypt stored e-mail based on the delivery times found in the newest (topmost) "Received:" header. P.S. Your mail server ellsberg.gnupg.com appears to be a bit aggressive in its greylisting (mails rejected first 3 to 4 times), causing NDR reports to be mailed back to me after 30 minutes. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From pasha at bell01.com Sun Dec 17 22:36:16 2023 From: pasha at bell01.com (Pasha) Date: Sun, 17 Dec 2023 22:36:16 +0100 Subject: GnuPG over web Message-ID: <7ef4faaef4bab4e5fd98e444df618c3538a6841b.camel@bell01.com> Hi all, I created an example of GnuPG over web. No browser plugin needed, but WebSocket support required. ?? user??? ---------- public key ----------------> ???????????????????????????????????????????????? |? webserver ???????????????????????????????????????????????? v ?? user??? <-----HTTP data with GNUPG tag(s)------ ?? browser -------- encrypted data --------------> ???????????????????????????????????????????????? | local websocket ???????????????????????????????????????????????? v (gpg_websocket.py) ?? browser <------- plain text data -------------- User will submit public key to a website using HTTP POST or other medium. Webserver will encrypt some information (Banking, other data) using public key and put inside html tag(s). When the page is loaded in browser, javascript will send encrypted HTML tags' contents to a local WebSocket to get plain text data. Local WebSocket is a server with current user's private key to decrypt using GPGME. source: https://dynamicmalloc.com/cgit/gnupg_over_web.git Without local WebSocket server: ===============================
xxxx
WebSocket server with private key: ==================================
plain text content.
Please let me know if you have any comments or suggestions. Thank you. note: resending without pgp example tag. regards Pasha From pasha at bell01.com Sun Dec 17 22:29:14 2023 From: pasha at bell01.com (Pasha) Date: Sun, 17 Dec 2023 22:29:14 +0100 Subject: GnuPG over web Message-ID: <6762a0fb8acd4ca449c2850cec76ba16bef593a3.camel@bell01.com> Hi all, I created an example of GnuPG over web. No browser plugin needed, but WebSocket support required. user ---------- public key ----------------> | webserver v user <-----HTTP data with GNUPG tag(s)------ browser -------- encrypted data --------------> | local websocket v (gpg_websocket.py) browser <------- plain text data -------------- User will submit public key to a website using HTTP POST or other medium. Webserver will encrypt some information (Banking, other data) using public key and put inside html tag(s). When the page is loaded in browser, javascript will send encrypted HTML tags' contents to a local WebSocket to get plain text data. Local WebSocket is a server with current user's private key to decrypt using GPGME. source: https://dynamicmalloc.com/cgit/gnupg_over_web.git Without local WebSocket server: ===============================
-----BEGIN PGP MESSAGE----- hQGMAyJ3PpkRYGT1AQv7BTx9T8PpK8kFB5UYfcuhkuvWN1AixXE+12UniO7aRAXz ... -----END PGP MESSAGE-----
WebSocket server with private key: ==================================
plain text content.
Please let me know if you have any comments or suggestions. Thank you. regards Pasha From jbailey at raspberryginger.com Thu Dec 21 04:31:11 2023 From: jbailey at raspberryginger.com (Jeff Bailey) Date: Wed, 20 Dec 2023 19:31:11 -0800 Subject: --list-keys fails with missing .gnupg directory and --no-options Message-ID: Hi! I'm trying to make a script resilient against a bad gnupg.conf file, so I tried passing --no-options to it. However, it then caused the command to fail on machines where gnupg had never been run, so ~/.gnupg didn't exist yet with the following error: gpg: Fatal: /home/jbailey/.gnupg: directory does not exist! I'm wondering if the documentation for --no-options should perhaps be updated to indicate that commands like --list-keys may fail if there's no homedir, or perhaps should --no-options skip doing anything with trustdb.gpg. Or perhaps I'm wrong on how I'm thinking about this. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Thu Dec 21 16:04:06 2023 From: wk at gnupg.org (Werner Koch) Date: Thu, 21 Dec 2023 16:04:06 +0100 Subject: --list-keys fails with missing .gnupg directory and --no-options In-Reply-To: (Jeff Bailey's message of "Wed, 20 Dec 2023 19:31:11 -0800") References: Message-ID: <8734vvzjfd.fsf@jacob.g10code.de> Hi! Right, no-options also inhibits the homedir creation: --no-options Shortcut for --options /dev/null. This option is detected before an attempt to open an option file. Using this op? tion will also prevent the creation of a ?~/.gnupg? homedir. > I'm wondering if the documentation for --no-options should perhaps be > updated to indicate that commands like --list-keys may fail if there's no I think that most commands will fail without a homedir. > homedir, or perhaps should --no-options skip doing anything with > trustdb.gpg. Well, if the homedir exists - which is the common case - this would change behaviour. --no-options is used so that you don't accidently use configured options like --encrypt-to or similar. For example, dirmngr and gpg-wks-client have such needs. I would suggest to create a temporary home directory or disable the trust thing (--always-trust should work). But without a home directory many things can't work. BTW, if case you are writing a verification script, have a look at the new option --assert-signer. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From sergio.borghese at gmail.com Tue Dec 26 01:47:12 2023 From: sergio.borghese at gmail.com (sergio borghese) Date: Tue, 26 Dec 2023 01:47:12 +0100 Subject: gnupg + TPM 2.0 support request In-Reply-To: References: <1d8c262d6eabd29953db404c885e89df69488b9b.camel@posteo.de> <87bkaxk281.fsf@akagi.fsij.org> Message-ID: Hi Niibe, All, Sorry for the late reply, but I was working on this in my spare time. This is just to say that your suggestion solved my issue. I got the latest source code from github and built gngpg 2.4 from master branch * master 37fa36a32 [origin/master] doc: Fix description of scdaemon for --disable-ccid. I also needed to build pinentry form master, as I need a version supporting with latest libassuan protocol * master 6fdb5e5 doc: Fix documentation ``` gpg> keytotpm Really move the primary key? (y/N) y sec rsa2048/37B7F7A2498FDF57 created: 2023-12-10 expires: 2026-12-09 usage: SC card-no: TPM-Protected trust: ultimate validity: ultimate [ultimate] (1). tpm-test ``` Thanks again for the support Ciao e grazie Sergio On Mon, Dec 11, 2023 at 10:15?AM sergio borghese wrote: > Hi Niibe, > > Thanks a lot for the info and help > So, if I get this right, I just need to get the latest master and rebuild > the gnupg sw. Is this correct? > Will try and send an update to the ML to share the results with everyone > > Ciao e grazie > Sergio > > On Mon, Dec 11, 2023 at 1:33?AM NIIBE Yutaka wrote: > >> Hello, >> >> sergio borghese wrote: >> > 2023-12-10 16:46:24 gpg-agent[358316] DBG: chan_11 <- ERR 268435731 >> Unknown >> > IPC command >> >> This is no harm. TPM2d doesn't support GETINFO command. >> >> > 2023-12-10 16:46:30 gpg-agent[358316] updating regular key file >> > >> '/home/netresults.wintranet/borghese/gpg2.tmp/private-keys-v1.d/FDEE0860BCFCE24C29738F1ADBF42D4C7D95516B.key' >> > by a shadow key inhibited >> >> I fixed this problem in the repo of GnuPG 2.4/master, I suppose. It's >> the commit 9909f622f for 2.4. >> >> The check was introduced (by the commit a1015bf2f) (in GnuPG 2.4.2), >> which caused the problem for KEYTOTPM handling of gpg-agent. Then fixed >> in repo (will be in GnuPG 2.4.4). >> -- >> > > > -- > preferisco ammazzare il tempo, > preferisco sparare cazzate, > preferisco fare esplodere una moda, > preferisco morire d'amore. > (Caparezza) > > -- preferisco ammazzare il tempo, preferisco sparare cazzate, preferisco fare esplodere una moda, preferisco morire d'amore. (Caparezza) -------------- next part -------------- An HTML attachment was scrubbed... URL: From felix.klee at inka.de Wed Dec 27 13:40:40 2023 From: felix.klee at inka.de (Felix E. Klee) Date: Wed, 27 Dec 2023 13:40:40 +0100 Subject: Cannot export SSH public key In-Reply-To: <4532235.LvFx2qVVIh@daneel> References: <4532235.LvFx2qVVIh@daneel> Message-ID: Thanks for pointing out that the signature key and the authentication keys are identical: $ gpg --card-status [?] Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3 1736 created ....: 2023-06-29 03:50:43 Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 [?] sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never At the same time, here the key IDs are different: $ gpg --list-keys --keyid-format LONG yubikey at f76.eu pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC] 7A0FE73DDB744F0F97341DA71BE349D11B6ED589 uid [ultimate] Felix E. Klee (YubiKey) sub rsa4096/7CC02D68D2E31736 2023-06-29 [E] sub rsa4096/32B106F6877CC64B 2023-11-22 [A] How does that go together? I thought the long key ID is the last 16 characters of the fingerprint. And the fingerprint is a 40 character hash of the public (or private?) key. From felix at f76.eu Wed Dec 27 10:23:01 2023 From: felix at f76.eu (Felix E. Klee) Date: Wed, 27 Dec 2023 10:23:01 +0100 Subject: Cannot export SSH public key In-Reply-To: <4532235.LvFx2qVVIh@daneel> References: <4532235.LvFx2qVVIh@daneel> Message-ID: Thanks for pointing out that the signature key and the authentication keys are identical: $ gpg --card-status [?] Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3 1736 created ....: 2023-06-29 03:50:43 Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 [?] sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never At the same time, the key IDs are different: $ gpg --list-keys --keyid-format LONG yubikey at f76.eu pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC] 7A0FE73DDB744F0F97341DA71BE349D11B6ED589 uid [ultimate] Felix E. Klee (YubiKey) sub rsa4096/7CC02D68D2E31736 2023-06-29 [E] sub rsa4096/32B106F6877CC64B 2023-11-22 [A] How does that go together? I thought the long key ID is the last 16 characters of the fingerprint. And the fingerprint is a 40 character hash of the public (or private?) key. From kloecker at kde.org Thu Dec 28 20:40:48 2023 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Thu, 28 Dec 2023 20:40:48 +0100 Subject: Cannot export SSH public key In-Reply-To: References: <4532235.LvFx2qVVIh@daneel> Message-ID: <3271059.aeNJFYEL58@daneel> On Mittwoch, 27. Dezember 2023 13:40:40 CET Felix E. Klee wrote: > Thanks for pointing out that the signature key and the authentication > keys are identical: > > $ gpg --card-status [...] > Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E > D589 > created ....: 2023-06-29 03:50:43 -> Apparently created on the same day as the other keys on the card. [...] > ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never -> Apparently created about 5 months later. Also note that "ssb#" indicates that this is a stub key, i.e. the secret key doesn't exist on disk (or on card). > At the same time, here the key IDs are different: > > $ gpg --list-keys --keyid-format LONG yubikey at f76.eu > pub rsa4096/1BE349D11B6ED589 2023-06-29 [SC] > 7A0FE73DDB744F0F97341DA71BE349D11B6ED589 > uid [ultimate] Felix E. Klee (YubiKey) > sub rsa4096/7CC02D68D2E31736 2023-06-29 [E] > sub rsa4096/32B106F6877CC64B 2023-11-22 [A] > > How does that go together? It doesn't. The authentication key on the card is different from the key on disk (or rather "not on disk" because you lack the secret key of the authentication key registered in your keyring). 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 felix.klee at inka.de Sat Dec 30 23:30:39 2023 From: felix.klee at inka.de (Felix E. Klee) Date: Sat, 30 Dec 2023 23:30:39 +0100 Subject: gpg --card-status Message-ID: Example output with line numbers: 01 Reader ...........: Yubico YubiKey CCID 00 00 02 Application ID ...: D2760001240103040006186980150000 03 Application type .: OpenPGP 04 Version ..........: 3.4 05 Manufacturer .....: Yubico 06 Serial number ....: 18698015 07 Name of cardholder: [not set] 08 Language prefs ...: [not set] 09 Salutation .......: 10 URL of public key : [not set] 11 Login data .......: [not set] 12 Signature PIN ....: not forced 13 Key attributes ...: rsa4096 rsa4096 rsa4096 14 Max. PIN lengths .: 127 127 127 15 PIN retry counter : 3 0 3 16 Signature counter : 0 17 KDF setting ......: off 18 Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 19 created ....: 2023-06-29 03:50:43 20 Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3 1736 21 created ....: 2023-06-29 03:50:43 22 Authentication key: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 23 created ....: 2023-06-29 03:50:43 24 General key info..: pub rsa4096/1BE349D11B6ED589 2023-06-29 Felix E. Klee (YubiKey) 25 sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never 26 card-no: 0006 18698015 27 ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never 28 card-no: 0006 18698015 29 ssb# rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never Lines 18, 20, 22: Fingerprint. I read somewhere that this a hash of the key. But of which one? The public key? The private key? What hash function? Line 25: ?sec>? means secret primary key. Where does the key ID come from? Is it read from the card? Or it read from the public key ring on disk? Line 27: ?ssb>? means secret sub key. Line 29: ?ssb#? means secret sub key, but without the matching secret key on the card. This I just learned from Ingo Kl?cker in another thread. If there is any authoritative documentation, please let me know! So far, I?ve puzzled the info together, piece by piece from various resources on the web. From felix.klee at inka.de Sun Dec 31 08:50:56 2023 From: felix.klee at inka.de (Felix E. Klee) Date: Sun, 31 Dec 2023 08:50:56 +0100 Subject: Cannot export SSH public key In-Reply-To: <3271059.aeNJFYEL58@daneel> References: <4532235.LvFx2qVVIh@daneel> <3271059.aeNJFYEL58@daneel> Message-ID: Thanks, Ingo! Looking at my log, I realize that I indeed uploaded the primary key when I did `keytocard`. I did not do `key 2` to select the authentication sub key. Instead I was assuming that GnuPG does automatically select the right sub key. There was a warning about moving the primary key, which I ignored. Today I fixed that, and now all works consistently: $ gpg --card-status [?] Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3 1736 created ....: 2023-06-29 03:50:43 Authentication key: 9DFF AD98 566A 604F 7290 7C24 32B1 06F6 877C C64B created ....: 2023-11-22 15:14:14 General key info..: pub rsa4096/1BE349D11B6ED589 2023-06-29 Felix E. Klee (YubiKey) sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never card-no: 0006 18698015 $ gpg --export-ssh-key yubikey ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B $ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== cardno:18 698 015 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== (none) Weird only is that `ssh-add -L` outputs the key twice. Logging in via SSH with the authentication sub key now works as expected, all smooth. From kloecker at kde.org Sun Dec 31 17:34:42 2023 From: kloecker at kde.org (Ingo =?ISO-8859-1?Q?Kl=F6cker?=) Date: Sun, 31 Dec 2023 17:34:42 +0100 Subject: gpg --card-status In-Reply-To: References: Message-ID: <12356199.O9o76ZdvQC@daneel> On Samstag, 30. Dezember 2023 23:30:39 CET Felix E. Klee wrote: > Line 25: ?sec>? means secret primary key. Where does the key ID come > from? Is it read from the card? Or it read from the public key ring on > disk? > > Line 27: ?ssb>? means secret sub key. > > Line 29: ?ssb#? means secret sub key, but without the matching secret > key on the card. This I just learned from Ingo Kl?cker in another > thread. The meaning of ">" and "#" is documented in the description of the command `--list-secret-keys` in the manual page of gpg. 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 felix at f76.eu Sat Dec 30 23:15:24 2023 From: felix at f76.eu (Felix E. Klee) Date: Sat, 30 Dec 2023 23:15:24 +0100 Subject: Cannot export SSH public key In-Reply-To: <3271059.aeNJFYEL58@daneel> References: <4532235.LvFx2qVVIh@daneel> <3271059.aeNJFYEL58@daneel> Message-ID: Thanks, Ingo! Looking at my log, I realize that I indeed uploaded the primary key when I did `keytocard`. I did not do `key 2` to select the authentication sub key. Instead I was assuming that GnuPG does automatically select the right sub key. There was a warning about moving the primary key, which I ignored. Today I fixed that, and now all works consistently: $ gpg --card-status [?] Signature key ....: 7A0F E73D DB74 4F0F 9734 1DA7 1BE3 49D1 1B6E D589 created ....: 2023-06-29 03:50:43 Encryption key....: DBBD 3239 D0F1 4326 808D FC8F 7CC0 2D68 D2E3 1736 created ....: 2023-06-29 03:50:43 Authentication key: 9DFF AD98 566A 604F 7290 7C24 32B1 06F6 877C C64B created ....: 2023-11-22 15:14:14 General key info..: pub rsa4096/1BE349D11B6ED589 2023-06-29 Felix E. Klee (YubiKey) sec> rsa4096/1BE349D11B6ED589 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/7CC02D68D2E31736 created: 2023-06-29 expires: never card-no: 0006 18698015 ssb> rsa4096/32B106F6877CC64B created: 2023-11-22 expires: never card-no: 0006 18698015 $ gpg --export-ssh-key yubikey ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== openpgp:0x877CC64B $ ssh-add -L ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== cardno:18 698 015 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC1jJSXxnM4iR3F16Yd5FEjrOo6sbGF rkvVVoqUt9iyL5Z+Lz1ElpyUoKcGRRtU8NNueI8RpJT7ipIxubMiefDHVU7FRhk809jQ vlTu8YDezdIZ0BWJ3W9+CCCQkD9JNmr5LsUnqD5KKUP4v0rwN6zLsXARGjpv1Jj61vJe o3+B9CGpe8cIFvbdVw7QEi5t1hW9ghRrHDREXhIYkc51rzK4htBBdlX7E4yFuiuPZC/2 Q2lUelBrHP+bwgC+GzliHUIseuGAGEpSjJadtuSC2gUZbgv7PN6jM7WzaSdJ22spoFlP XoIimu4hSOpEgK/txOuB+ge3MrpXEQPYW1tN0nD1RZF39uGbGdQrk9s6MARbZ+1APTJh H6oi9fPfOp7EEkmZsm1ojwGoIN+RoYQ23KMVqI915SNn5CaRySQNenVyAJ7Skl2Q3bdK ENW7lkGFXZ/DxpA8dQITZGBJEGhVppj2Pfp4uANDcdqUUGCN3i0srmkb7XaNn3U9qyIB KEgnFupkNfMVB48AQu1PYxoEoO/zIyTVlPn0iSAl64zA27u5RXlikEbx0ePvPSYuMTL4 ZaDk2vNvKNmPvXBi6dZvXIPx2ROrqBrLMNx19EHDVSSVT+R3Qf1f/4TwRdHPb6ZliSFv FF6eygY40y5whHNy7Q8zxrj5Py56Cp+Alus3jr6UNw== (none) Weird only is that `ssh-add -L` outputs the key twice. Logging in via SSH with the authentication sub key now works as expected, all smooth.