Most things are done. Missing stuff

Alright: We have support for all our combined algos ky{768,1024}_bp{256,384,512}and ky{768,1024}_cv{25519,448} as well as test keys and encrypted test messages.

What is the current status of this issue?

Here comes a new test key along with its 3 secret parts (one for the primary and two for the composite Kyber subkey).

Wit the test keys posted in T7014 it is now possible to decrypt the sample data. The test data has been slightly adjusted for the new format; see

See also: https://gnupg.org/blog/20240125-smartcard-backup-key.html

Also fixed in the fortgcoming 2.2.43

Fixed in 2.4.4. Feel free to re-open if you still see problems.

Fixed in 2.4.4 and 2.2.43 - see above for affected versions.

We need to fix 2.2.42 too. This because we backported the responsible patch.

We tested with Kleopatra:

• Only gpg4win 4.2 is affected (the current version) but 4.1 is not affected.
• No vsd version is affected.

FWIW, I am already working on this.

Currently, there is no support for gpg-agent to keep private key not on disk, but only on memory of gpg-agent. Given the situation,
I think that it is good to:

Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.

I applied your patch and also fixed another possible problem.

It's true that for KEYTOCARD command, there is optional argument for ECDH.
My point is that for PKDECRYPT command, it will be needed to add mechanism for getting such a parameter (when we use KEM API in gpg-agent).

We already have the ECDH parameters for OpenPGP in the gpg-agent API. The question is how large the data for PQC will be - likely we need to use an inquire already for this reason.

Considering the design of gpg-agent which focuses on private key operations and data, it would be better to enhance the gpg-agent protocol to inquire public key data of any format defined by the client (including ECDH KDF parameters of OpenPGP). I mean, instead of storing data in the key file (originally designed for private key + some additional data), we will enhance the protocol.

Further investigation showed that this was due to a bogus key creating during I wrote the code.

Will be in 2.4.4. GPGME 1.23.0 with support has been released.

While trying to replicate your findings I might have found a but in the import code which rejected one of the keys (using gnupg 2.2). I'll take care of this.

@ebo: Du have the Ted Tester key (i.e. the ADSK key) also in you keyring?

Encryption to the ADSK seems to work but I'm not sure if everything is displayed as expected.

works

Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.

I am not sure about the initial state of the key. What you are doing is to sign the key with itself (self-signature). Why?
In any case, I can't replicate this. Let's talk about this next week.

Okay, will go into the next revision. Thanks.

Thanks for the reply!

The fix actually does the same as my suggested workaround.

There is an easy workaround: Append an exclamation mark to the adsk key. This way gpg will only search for this subkey.
An example with my test keys:

isn't T3456 the same issue?

OCB mode (i.e. packet 20) is only used if the keys announce it. Thus only after moving a (private) key from GnuPG to a non-GnuPG compatible implementation you will run into this problem. The compatibility options won't override the preference system.

Things for 2.4 are all done.

For 2.2 we will for now only implement the encryption.

Thanks for the description; this is good for documentation.

Sorry, I mistakenly closed this task. I reopen it.

Could it be the case that your implementation actually used those bits to calculate a public key?

Sorry for a bit late follow up. How do you calculate a public key? RNP's crypto backend, Botan, is calculating public key without taking in account bits which should be tweaked. I.e. both tweaked and non-tweaked secret keys would produce the same public key. The same is with decryption. Could it be the case that your implementation actually used those bits to calculate a public key?

To fix this we also need to fix our key selection test (key-selection.scm) which is can't cope with all combinations. The tests are run with a faked time of 2004-01-01 on all subsets of this ordered list of keys

See also T4713

So here is a redacted CLI-dump of the exact sequence I'm describing in my post. This is with untweaked keys and gpg 2.2.40 and a factory-reset yubikey.

So in case this was not clear... What I'm describing is very similar to the original description, but it is "inverted" - the untweaked key works flawlessly (import and decryption) except for keytocard. And the tweaked key can't be imported - either "Bad Secret Key" or asking for passphrase.

@onickolay Yes, I have. I have used --check-cv25519-bits and it said that it needs patching. I then did --fix-cv25519-bits and exported the key. Looking at the CV25519 private-key bytes produced by my code and by RNP, I confirmed that they did the exact same transformation.
When trying to re-import the exported key into gpg, I got the "Bad Secret Key" error again

@bigmomma Just for a quick check - did you try to use RNP's CLI command --edit-key --fix-cv25519-bits, as it's not clear from the message?

Hi! I would like to chime in on this issue as I am having some weird problems with a CV25519 sub-key and after stumbling upon this thread, I think it is related to this.
Unfortunately, I can't post the key material here, because it is my actual encryption private-key.