The application probably doesn't support this curve, the changelog only mentions Curve25519 and NIST P-256. Also Kleopatra lists only these two curves when generating a key from the card. Upon further inspection, the 0xFA DO listing the supported algorithms only has RSA 2048, RSA 4096, nistp256, ed255519 and cv25519

This is a Nitrokey 3A with the firmware 1.2.2-alpha.20221130. I'll check with the vendor.

Sure that you specific card/implementation of Nitrokey supports this curve? The card application uses a vendor from the test card range - this it is likely that it is some Javacard implementaion or it is an old gnuk firmware on the nitrokey basic.

Changing the key attributes didn't help unfortunately:

There must be some regression in the code which changes the key attributes. Please try
"gpg --card-edit" admin, key-attr
and switch to nistp384.

I also tried to import the key with the gpg-card writekey command and I got the same error.

Same error message but probably a different cause, in this case the card was factory reset before importing.

Looks similar to T6378. Can you provide the output of

Thanks for the reply :)

Sorry, I think you have to fix the other tools. The ! suffix has virtually been supported forever and any new option to do the same complicates the code and the documentation.

well, this user made a backup and it went wrong anyway ;-) See T6377

Oh this issue was in the wrong project. Related to T5836

If 3.1.26 only offers RSA algos, then Kleopatra obviously assumes that the smart card only supports RSA and therefore doesn't offer the transfer of Brainpool keys.

I'm sorry, I got a bit confused, it works in Kleopatra on 3.2.0, but not in 3.2.26

Which algorithms are offered when you use "Regenerate Key"? What's the output of gpg -K --with-colon <key_id>?

Thanks. please give a few days.

created ~/.gnupg/gpg-agent.conf containing:

debug ipc,cache
debug-pinentry
log-file socket://

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

Kleopatra simply copies the content of the corresponding *.key file in the private-keys-v1.d folder. If the *.key file contains a shadowed key after issuing a KEYTOCARD --force [...] command followed by a SCD LEARN --force command (note the SCD!), then gpg-agent is to blame.

I may be reading your comment wrong, but the problem here is not multiple pinentry prompts, or multiple gpg-agents present.

Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.

Hier is a log file from GpgOL (+Code verfolgung)

Works now for gpgme. Thanks!

Works for me with gpgtar (GnuPG) 2.4.1-beta21. I haven't verified this with 2.2.x.

Understood. I appreciate the time you took to analyse the issue. Thanks.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.

Oh, yes this makes sense in the copy/delete path of utils/path-helper.cpp Kleo::moveDir on Windows src and dest are usually on the same device so this might not have been noticed as much by our users as then it is just a rename.

The first signature is a direct key signature (class 0x1f) and this determines the expiration time. The usual case is to have the expiration time in the user id signatures. Our code does not allow to chnage the expiration time of direct key signature. This is because direct key signature are used by PGP and GnuPG only to add designated revokers. Gpg has no means to create a direct key signature like you have in your key.