Moving a (VS-NfD compliant) Brainpool key is not possible with Kleopatra. The option "Transfer to smartcard" is greyed out.
Moving the same key on the command line works fine. (At least if the card is empty beforehand.)
Description
Description
Details
Details
- Version
- 3.1.26, 3.2.0.0
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • werner | T6379 Kleopatra: Brainpool key can not be moved to smart card | ||
| Open | • werner | T6620 Add a way to extract ECC key parameters from a public key |
Event Timeline
Comment Actions
Which algorithms are offered when you use "Regenerate Key"? What's the output of gpg -K --with-colon <key_id>?
Comment Actions
On 3.1.26, only RSA Algorithms are offered:
I'm sorry, I got a bit confused, it works in Kleopatra on 3.2.0, but not in 3.2.26
On 3.2.0 for "Regenerate Key" and "Generate Key" 7 algorithms are offered (one to many?):
On 3.1.26, only RSA Algorithms are offered:
This is on 3.1.26 after I moved the first subkey to the card via command line keytocard:
gpg -K --with-colon 595E61FF0929ED7584BA140D13B6ADCFDDDC9206
sec:u:256:19:13B6ADCFDDDC9206:1676545638:1739703600::u:::scESC:::D2760001240103040006154932980000::brainpoolP256r1:23::0:
fpr:::::::::595E61FF0929ED7584BA140D13B6ADCFDDDC9206:
grp:::::::::3CFD6A7640BE496C00CE2BF879B79AC981DCDB44:
uid:u::::1676545638::7084D80B57C334CE1A0C2A7C3E9A54FE9A12DBFE::test_Brainpool::::::::::0:
ssb:u:256:18:2237C4F898D4BE00:1676545638:1739703600:::::e:::+::brainpoolP256r1:23:
fpr:::::::::E74545CD33CC0B0F3800E4D72237C4F898D4BE00:
grp:::::::::ECA8237AF7D895D884FC7332CEB2AEB752C66E2E:
Comment Actions
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.
Comment Actions
We got a user report that the issue did not occur before their update from 3.1.25 to 3.1.26
Comment Actions
I think Werner backported some missing functionality to GnuPG 2.2. Please retest with the next version.
Comment Actions
For Testversion 3.1.27.0-beta44 for "Regenerate key" now the same algorithms as in 3.2.0 are offered for a Yubikey and it is possible to move them to the smart card.
This is fine even for not VSD-compliant keys, as they are marked as such.
For ZeitControl card (version 3.4) it is not possible to move 25519 keys to the card, as the card does not support it.
Comment Actions
Noticed in gpg4win 4.2.0-beta373:
For Brainpool and ed/cv25519 keys it is not possible to move a subkey to a smart card with Kleopatra. The error message is "invalid value".
Moving the main key works, though. The command line works for all keys types, of course.
Comment Actions
By subkey she meant the encryption key and by "main key" she meant the signing key. I don't think that we have tested with authentication keys but I would expect them to work, too.
Comment Actions
yeah, sorry, didn't test different key types yesterday.
NIST encryption keys do not work either, so only RSA encryption keys can be moved with Kleopatra to a smart card in gpg4win 4.2.0.
I can confirm that authentication keys work.
Comment Actions
The relevant logs are
2023-07-27 12:08:01 scdaemon[28156] opgp: ecdh parameters missing 2023-07-27 12:08:01 scdaemon[28156] operation writekey result: Invalid value
Kleopatra does
KEYTOCARD --force 388BC88C5D67E531047FA013D790291AB829F2C8 D2760001240100000006154949680000 OPENPGP.2 20230727T094737
i.e. without "the hexified ECDH parameters for OpenPGP" parameter.
How is Kleopatra supposed to know the ECDH parameters? Why doesn't gpg-agent add those parameters? If gpg-agent doesn't know them, then who knows?
Comment Actions
We had to add the parameters because some keys don't use the default paramters PGP and gpg have used since the introduction of ECC 12 years ago. So yes, we could fallback to the standard parameters but it would bet better if Kleopatra could extract them from the public key (maybe via a GPGME helper).
Comment Actions
The relevant commit is rGc03ba92576e34f791430ab1c68814ff16c81407b
gpg: Fix writing ECDH keys to OpenPGP smartcards.
The problem showed up because in 2.4 we changed the standard ECDH
parameter some years ago. Now when trying to write an ECDH key
created by 2.2 with 2.4 to an openpgp card, scdaemon computes a wrong
fingerprint and thus gpg was not able to find the key again by
fingerprint.
Thus we see the problem because we did not backport the patch to 2.2. However over short or long we will run into simalar bgs in 2.2. Thus we should eventually backport it and in any case provide the ecdh params to keytocard.
Comment Actions
Thanks for the pointer! I'll see how I can do what ecdh_param_str_from_pk does in gpgme.
Comment Actions
The state of the brain is:
If a nistp384 or brainpoolP384r1 key was created with gnupg 2.2 it does not work to move the key to a card using kleopatra with gnupg.2.4 And vice versa.
However, it does work when using gpg --edit-key, keytocard
All other key types are not affected. Changes to Kleopatra are required; see T6620.