I encountered this bug last year, but I realized that it's hard to make a reproducible case.

For the Data Object of serial number, what I read is this code: https://github.com/Yubico/yubikey-manager

FWIW: Actually the old code assumed that the s/n is at least 4 bytes. IIRC, I once checked the source of the Yubico tools to get this info.

Applied and pushed.

The device with serial number 10000003, it is represented as three bytes: 00989683

These are the versions:

Which version of Kleopatra are you using? And which operating system, e.g. Windows 10?

@dkg
If we support native X25519 format, multiple representations will be possible (there are 32 ways, at least) for a single secret key, because it's the feature of X25519.

In 2.3, the logic to identify Yubikey has been changed (to support PIV application).

In your log, it says:

usb_claim_interface failed: -3

Sorry, I was wrong.

@werner
My patch is for the case if it's better to accept such a key of OpenPGP.
I don't know if it's better or not (yet). The purpose of this patch is to show the point where OpenPGP secret part translates into libgcrypt secret key, concretely.

Do we want to encourage multiple cleartext wire-format representations of the same secret key?

I need to see how we can pass the check permission notice up to gpg. This is a too common problem and thus serves some special treatment.

GPG Version :

JFYI: Original curve25519-donna (as well as Botan library, and OpenSSL) tweaks bits inside of the exponentiation function, so secret keys with or without tweaked bits would be equivalent and produce the same public key.

Works. My initial tests also failed because on Windows 64 the registry value has to be placed in the WOW6432NODE

Apologies,.. I used ctags on read_w32_registry_string and that jumped me to build-aux/speedo/w32/g4wihelp.c which has a read_w32_registry_string that does not expand....
Now I found the w32-reg.c in common which looks completely fine.

Alright, we can keep just the colon delimited format for --ldapservers et al. Because we support ldap URLs in CrlDistributionPoints in X.509 certificates we need to handle them internally. But there is indeed no need to support them in the config files.

gniibe: Can you explain why an import shall modify the secret key? Form my understanding it is an invalid secret key and thus it can't be used. An import operation is different than the key generation.

For an implementation of Curve25519 routine, it is needed to tweak those bits.

Better to have in-line:

diff --git a/agent/cvt-openpgp.c b/agent/cvt-openpgp.c
index 53c88154b..b1d43227a 100644
--- a/agent/cvt-openpgp.c
+++ b/agent/cvt-openpgp.c
@@ -159,7 +159,21 @@ convert_secret_key (gcry_sexp_t *r_key, int pubkey_algo, gcry_mpi_t *skey,
                EdDSA flag.  */
             format = "(private-key(ecc(curve %s)(flags eddsa)(q%m)(d%m)))";
           else if (!strcmp (curve, "Curve25519"))
-            format = "(private-key(ecc(curve %s)(flags djb-tweak)(q%m)(d%m)))";
+            {
+              unsigned int nbits;
+              unsigned char *buffer = gcry_mpi_get_opaque (skey[1], &nbits);
+              unsigned char d[32];
+
+              if (nbits != 256)
+                return gpg_error (GPG_ERR_BAD_SECKEY);
+
+              memcpy (d, buffer, 32);
+              d[0] = (d[0] & 0x7f) | 0x40;
+              d[31] &= 0xf8;
+              gcry_mpi_release (skey[1]);
+              skey[1] = gcry_mpi_set_opaque_copy (NULL, d, 256);
+              format = "(private-key(ecc(curve %s)(flags djb-tweak)(q%m)(d%m)))";
+            }
           else
             format = "(private-key(ecc(curve %s)(q%m)(d%m)))";

"Curve25519" in libgcrypt was implemented before the standardization of X25519. There are two problems here: endianess and tweaking-bits.

In T5442#146871, @gniibe wrote:

I see your situation

Could you please help me to analyze what's going on?
Please add following lines to your scdaemon.conf to see CCID driver's debug output:

debug-ccid-driver
verbose
verbose
verbose

And share the debug output.

Ah, I think that your problem was fixed in rG53bdc6288f9b: scd: Recover the partial match for PORTSTR for PC/SC. (to be 2.3.2).

I see your situation

In T5442#146869, @gniibe wrote:

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

If possible, please let us know how you configure the permission to access CCID device with 2.2 (and with 2.3)?

In T5415#146808, @KasparEtter wrote:

Please excuse my late reply. I was busy with other things over the last few weeks.

Yes, putting disable-ccid into ~/.gnupg/scdaemon.conf works for me with GnuPG 2.3.1 under macOS Catalina (10.15).

I still don't understand what the problem is/was, so I cannot judge whether it's better to recommend this manual configuration for Mac users or to disable CCID by default on macOS.

I tried again after cloning the master branch, and I finally figured it out. Sorry for the trouble caused by this irrelevant question just submitted. thanks again.

Please read T5454 again. To get the listing I showed you need to use the latest gpgme from Git master.