Yubikeys and GnuPG 2.2/2.3
Hi all,
I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin)
with Yubikey NEO for my SSH needs.
For some time now, gpg-agent has problems detecting my Yubikey. Windows
sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to
manually updating the driver to get it recognised as "Identity Device (NIST SP
800-73 [PIV])" and then reinserting my Yubikey a few times until gpg
--card-status command recognised Yubikey. This used to "hold" between computer
reboots, but lately has been happening almost every time I reinsert Yubikey NEO.
To avoid furiously reinserting the key and risk breaking something, I wrote a
small PowerShell function that does this (kill scdaemon, restart Windows Smart
Card service and try reading card status):
do {
& gpgconf --kill scdaemon
Restart-Service SCardSvr
& gpg --card-status -vvv
} while ($LASTEXITCODE -ne 0)
This usually works after a few loops. I have both Yubikey NEO and Yubikey 5
and both have the same problem.
My scdaemon.conf has a single line:
card-timeout 1
I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf:
log-file
debug-level basic
verbose
After killing scdaemon.exe and running gpg --card-status, I get:
2022-01-07 15:53:58 scdaemon[9960] listening on socket '\.gnupg\S.scdaemon'
2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- GETINFO socket_name
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> D \.gnupg\S.scdaemon
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- OPTION
event-signal=0x0284
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- GETINFO version
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> D 2.2.27
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- SERIALNO
2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
(0x801b)
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> ERR 100696144 No
such device
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- RESTART
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
When I run my "fixing" loop, I'll get a few of these blocks and then a success.
Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work
at all. Debugging scdaemon with Yubikey NEO, I get something like this:
2022-01-07 15:48:05 scdaemon[24108] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- GETINFO socket_name
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- OPTION
event-signal=290
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- GETINFO version
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> D 2.3.4
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- SERIALNO
2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1
2022-01-07 15:48:05 scdaemon[24108] slot 0:
ATR=3bfc138131fe15597562696b65794e454f7233e1
2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card
error
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> S PINCACHE_PUT 0//
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> ERR 100696144 No
such device
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- RESTART
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
With Yubikey 5, I get:
2022-01-07 15:48:46 scdaemon[15680] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 <- GETINFO socket_name
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 -> D
Re: Gpg4win LetsEncrypt issue
Am Mittwoch 05 Januar 2022 09:16:52 schrieb Alex Nadtoka via Gnupg-users: > Is there a way to enable more detailed debug mode so I can see the path for > the certificate that dirmngr is using? Use dirmngr.conf to add more diagnostic output, e.g. log-file c:\XYZ debug-level advanced and restart dirmngr and do a request. (reload could be done by gpgconf --reload dirmngr ) 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: one ecc key-pair for both encryption and signature?
There is anequivalence given (two functions) in the Ed25519 wikipedia page, but I don't know if this allows the same curve used in both algorithms. Yes, in the same way that if you torture a DSA key long enough you can get the Elgamal encryption algorithm out of it. But once you do that, *you're no longer using DSA*. Likewise, Edwards DSA can be tortured into becoming a Curve25519 key. But once you do that, *you're no longer using Edwards DSA*. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: one ecc key-pair for both encryption and signature?
On 07/01/2022 16:55, Bernhard Reiter wrote: > Then RSA should be limited in the same way. (Because there it is possible, so I guess that there is another reason.) I agree, although IIRC such usage is supported for backwards compatibility reasons. | The curve is birationally equivalent to a twisted Edwards curve | used in the Ed25519 signature scheme. There is anequivalence given (two functions) in the Ed25519 wikipedia page, but I don't know if this allows the same curve used in both algorithms. "Birationally equivalent" means that there is a 1:1 mapping between the points of each curve that preserves their mathematical structure. This means that you could in principle convert a key from one curve to the other, but it would be a more complex function than just copying the raw bit string. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: one ecc key-pair for both encryption and signature?
Am Freitag 07 Januar 2022 15:21:45 schrieb Andrew Gallagher via Gnupg-users: > On 07/01/2022 14:06, Bernhard Reiter wrote: > > With 2.2.33 is is not possible to create a single ecc key-pair > > that can do "sign" and "encrypt". > > it is best practice to keep the encryption-capable subkey distinct. Is this the only reason? Then RSA should be limited in the same way. (Because there it is possible, so I guess that there is another reason.) Am Freitag 07 Januar 2022 15:26:50 schrieb Robert J. Hansen via Gnupg-users: > Ed25519 is (effectively) a Schnorr signature done over an Edwards curve. > Schnorr signatures have really no capability of being used for > encryption, unless you want to do it just a few bytes at a time. Reading https://en.wikipedia.org/wiki/Curve25519 | Curve25519 is an elliptic curve [..] designed for use with the elliptic | curve Diffie–Hellman (ECDH) key agreement scheme -> encrypt | The curve is birationally equivalent to a twisted Edwards curve | used in the Ed25519 signature scheme. There is anequivalence given (two functions) in the Ed25519 wikipedia page, but I don't know if this allows the same curve used in both algorithms. 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Yubikeys and GnuPG 2.2/2.3
Hi all,
I run GnuPG 2.2.27 on Windows 10 and gpg-agent + ssh-pageant (from Cygwin)
with Yubikey NEO for my SSH needs.
For some time now, gpg-agent has problems detecting my Yubikey. Windows
sometimes detects Yubikey as "Unknown Smart Card" and I used to resort to
manually updating the driver to get it recognised as "Identity Device (NIST SP
800-73 [PIV])" and then reinserting my Yubikey a few times until gpg
--card-status command recognised Yubikey. This used to "hold" between computer
reboots, but lately has been happening almost every time I reinsert Yubikey NEO.
To avoid furiously reinserting the key and risk breaking something, I wrote a
small PowerShell function that does this (kill scdaemon, restart Windows Smart
Card service and try reading card status):
do {
& gpgconf --kill scdaemon
Restart-Service SCardSvr
& gpg --card-status -vvv
} while ($LASTEXITCODE -ne 0)
This usually works after a few loops. I have both Yubikey NEO and Yubikey 5
and both have the same problem.
My scdaemon.conf has a single line:
card-timeout 1
I tried debugging scdaemon a bit, so I added these lines to scdaemon.conf:
log-file
debug-level basic
verbose
After killing scdaemon.exe and running gpg --card-status, I get:
2022-01-07 15:53:58 scdaemon[9960] listening on socket '\.gnupg\S.scdaemon'
2022-01-07 15:53:58 scdaemon[9960] handler for fd -1 started
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- GETINFO socket_name
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> D \.gnupg\S.scdaemon
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- OPTION
event-signal=0x0284
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- GETINFO version
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> D 2.2.27
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- SERIALNO
2022-01-07 15:53:58 scdaemon[9960] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] pcsc_connect failed: sharing violation
(0x801b)
2022-01-07 15:53:58 scdaemon[9960] reader slot 0: not connected
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> ERR 100696144 No
such device
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 <- RESTART
2022-01-07 15:53:58 scdaemon[9960] DBG: chan_0x0288 -> OK
When I run my "fixing" loop, I'll get a few of these blocks and then a success.
Recently, I tried upgrading to GnuPG 2.3.4 and my "fixing" loop does not work
at all. Debugging scdaemon with Yubikey NEO, I get something like this:
2022-01-07 15:48:05 scdaemon[24108] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:05 scdaemon[24108] handler for fd -1 started
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- GETINFO socket_name
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> D \AppData\Local\gnupg\d.3b7nddgeibkoou7f\S.scdaemon
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- OPTION
event-signal=290
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- GETINFO version
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> D 2.3.4
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- SERIALNO
2022-01-07 15:48:05 scdaemon[24108] detected reader 'Yubico Yubikey NEO
OTP+U2F+CCID 0'
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: not connected
2022-01-07 15:48:05 scdaemon[24108] reader slot 0: active protocol: T1
2022-01-07 15:48:05 scdaemon[24108] slot 0:
ATR=3bfc138131fe15597562696b65794e454f7233e1
2022-01-07 15:48:05 scdaemon[24108] no supported card application found: Card
error
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> S PINCACHE_PUT 0//
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> ERR 100696144 No
such device
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 <- RESTART
2022-01-07 15:48:05 scdaemon[24108] DBG: chan_0x02d4 -> OK
With Yubikey 5, I get:
2022-01-07 15:48:46 scdaemon[15680] listening on socket '\\AppData\\Local\\gnupg\\d.3b7nddgeibkoou7f\\S.scdaemon'
2022-01-07 15:48:46 scdaemon[15680] handler for fd -1 started
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 -> OK GNU Privacy
Guard's Smartcard server ready
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 <- GETINFO socket_name
2022-01-07 15:48:46 scdaemon[15680] DBG: chan_0x0308 -> D
Re: one ecc key-pair for both encryption and signature?
I know that "ed25519" and "cv25519" are different algorithms, but from my limited understanding the same key-pair should be usable for both encrypting and signing in theory? Ed25519 is (effectively) a Schnorr signature done over an Edwards curve. Schnorr signatures have really no capability of being used for encryption, unless you want to do it just a few bytes at a time. Schnorr signatures were also used as the basis for DSA during the cryptowars of the 1990s. The US government was very worried that any federal crypto standard not be able to be used for encryption (seriously): they wanted to give American citizens and businesses a strong signature algorithm, but not give us a strong encryption algorithm. Hence, Schnorr was adapted into becoming the Digital Signature Algorithm... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: one ecc key-pair for both encryption and signature?
On 07/01/2022 14:06, Bernhard Reiter wrote: With 2.2.33 is is not possible to create a single ecc key-pair that can do "sign" and "encrypt". There are circumstances (legal, contractual, operational) where you may need to disclose or share an encryption key, so it is best practice to keep the encryption-capable subkey distinct. And if you present people with the option to do a suboptimal thing, a significant fraction of them will choose that option by accident - so usually best not to offer it in the first place. -- Andrew Gallagher OpenPGP_signature Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
one ecc key-pair for both encryption and signature?
With 2.2.33 is is not possible to create a single ecc key-pair that can do "sign" and "encrypt". I know that "ed25519" and "cv25519" are different algorithms, but from my limited understanding the same key-pair should be usable for both encrypting and signing in theory? Can someone point me to an explanation why it isn't done so here? Thanks Bernhard == Details GNUPGHOME=~/dot-gnupg-test3/ gpg --expert --full-generate-keygpg: WARNING: gpg (GnuPG) 2.2.33; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key (14) Existing key from card Your selection? 11 Possible actions for a ECDSA/EdDSA key: Sign Certify Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (A) Toggle the authenticate capability (Q) Finished Your selection? e Invalid selection. -- 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 signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Having two versions of GPG on Linux causes problem
* 2022-01-07 13:45:09+0800, foods.bolds wrote: > I installed two versions of GnuPG on Ubuntu using two package > managers. > It seems that GPG 2.3 invoked the old version of gpg-agent residing in > /usr/bin. I cannot delete the old gpg because it is a dependency of > other software. Probably there is a systemd unit gpg-agent.socket which listens to connections on a socket and starts unit gpg-agent.service which starts /usr/bin/gpg-agent. If that is the case you can override the .service unit. Write a .conf file which overrides just the ExecStart= and ExecReload= settings, like this: # /etc/systemd/user/gpg-agent.service.d/my.conf # or maybe: # ~/.config/systemd/user/gpg-agent.service.d/my.conf [Service] ExecStart=/usr/local/bin/gpg-agent --supervised ExecReload=/usr/local/bin/gpgconf --reload gpg-agent Then: systemctl --user stop gpg-agent.service systemctl --user daemon-reload -- /// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/ // OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Having two versions of GPG on Linux causes problem
Hi, I installed two versions of GnuPG on Ubuntu using two package managers. GPG 2.2 is installed with built-in apt and GPG 2.3 is installed with LinuxBrew. The path of LinuxBrew has priority in the $PATH so it is invoked in the terminal (which is what I want). However whenever I uses it, it shows the message “server gpg-agent is older than us (2.2.20 < 2.3.4)”. It seems that GPG 2.3 invoked the old version of gpg-agent residing in /usr/bin. I cannot delete the old gpg because it is a dependency of other software. Running “gpgconf kill —all” won’t solve the problem, so does restarting the machine. What is strange is that running “gpgconf list” shows the correct path of all the components, including gpg-agent. I installed two versions of GPG because I want to use the newest v2.3, which is not provided in any apt source as I know. Is there anyway to resolve the issue, or installing two versions is an undefined behaviour? Thanks in advance Meng___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
