It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 6 2024
May 30 2024
In more than 25 years of OpenPGP we only had a few new implementations which got it wrong. I see no need to fix it here - maybe import could indeed reject such a key, though.
May 29 2024
Maybe there's a 4th possible option that's better than the three i identified?
So i see a range of ways that any OpenPGP software could deal with this:
I can replicate that and it works if you disable the use of the CRT. Looking at the key:
pkey[0]: BC9E1CD66676208956B35357210C220508F9F883FE32F4D682CD36BFB4E8055938D4BA21C341D9F48527E420F951B80335B24DF6710F01C4364D554AF659FC35D322061B67CC2F303DC878076059E4F266CFAEF6AB7A29124E969B9C15B1FC2FBA0F0F90E6B059E36B5E3C9BEC4174162689108A1E0EF6D5DDEE61B6B48327A259746288A517B1D78A0E24F5EFF6E880FF39C0BEDDC464B66F787B559EC5487F248196C2CFB15730BD9695C48355DFB2839FA23D8A37FBD48C741F6BE19F9D48BF844C5147591E1E06803DA40BEA1186B3B39CDCBC0E7DAC9DACDBB60A20E56B7E6631E47A45989A256743FDD83C591CFD4110DEA1B04ADE91CCB575FB858C13 pkey[1]: 010001 skey[2]: 512FB977EB9872FECA8BDB96884A01A6AB2B7575D307B9ED4F55E777F2F55FBFFCBF4BF2D669D4D7F42CAC7C28F4ACC0ECEEF7B1D90E3D936850372352107F87E77E20A4D133C927F99FFD52277DEA17107BDA72A072AF950AB0B70023327E3B48D9CCB871237D3D6F6C9BA7FDB45AB46217E33FA01A8ED295795323E26505BC9471CAE4DDA94DBF4F35ED915B0CD025805DCA796EB6B208D8D3F63DBE52BC0045CF4CF9B128356359C7E55B661D7B9DCA57F8984095C5AD3FE4DBD19228B281D66609A154DD7E3EE940CFC66CC180DDC4DD00C45A52D5789286D89D49CA34E5F3C4E798D90955074DAE3D99F7F004CDFFBC9B8428E8EB603E240AE07BEE8D71 skey[3]: F57D9F597750967DF272D9AC661DDC212D7C5CA4C6E91573A80756281351CDC3A2532B155D9251029F89A0A0807DF2BD177DC30FC6A847E07738B55606DF032ADAD8361E0AFEE9C0CF7D566793834977FAAE9C4B87132B94F665EFF463777CDE7EB89113FA3AAC194B6F2D30C40BE7C0DDE36A5855277C1E4D0204FC4C737BCB skey[4]: C4B135296B8F4390B953DDA84249FC8467CFF81FC715D1B5F3E01FCC8DC770813630AEA93982F2004705C4D272E07A10B1882AC5C09A45E88B14A1446B4C639B549420CE3BF90947E6E86503E426A8FDAC4C5CFC2809F5F0A1647ED5EE2457C054A40AA1F0666B28B2C970BE2093AE7B095A688B2D713CA8885826F23AFB37D9 skey[5]: 0790A8E260C6CADC353FB3961D798EFD4F15F96752DA20B86841334C38861743DD7A1FEB2B750D0864F5901BE541B6C8FB63649B18FDC4A32A1233EF90872DCD35704A4B4063DB62752CF6A7FD00F086C6B1042A2B0CB6FB36B7D5269671DACF55242A838E60D514BA868354910CEB1C41FB9A43BF932B5036A6EFE35236FFC7
Apr 24 2024
Most things are done. Missing stuff
Apr 23 2024
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.
Apr 16 2024
What is the current status of this issue?
Apr 15 2024
Here comes a new test key along with its 3 secret parts (one for the primary and two for the composite Kyber subkey).
Apr 11 2024
Mar 4 2024
Feb 26 2024
Jan 25 2024
Also fixed in the fortgcoming 2.2.43
Jan 24 2024
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.
Jan 22 2024
Jan 19 2024
Jan 18 2024
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:
Jan 17 2024
Jan 11 2024
Way to late for a change and also adding another algorithm (SIV) complicates things for no good purposes.
Jan 2 2024
I applied your patch and also fixed another possible problem.
Nov 27 2023
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.
Nov 23 2023
Nov 21 2023
Nov 13 2023
Nov 10 2023
Further investigation showed that this was due to a bogus key creating during I wrote the code.
Oct 26 2023
Will be in 2.4.4. GPGME 1.23.0 with support has been released.
Oct 25 2023
Oct 24 2023
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.
Oct 5 2023
@ebo: Du have the Ted Tester key (i.e. the ADSK key) also in you keyring?
Sep 22 2023
Encryption to the ADSK seems to work but I'm not sure if everything is displayed as expected.
Sep 12 2023
works
Sep 6 2023
Bugs goes back to 2002 where we stopped checking trust for keys without any signature. This was really useful but has this strange behaviour.
Sep 4 2023
Aug 28 2023
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.
Aug 25 2023
Aug 8 2023
Aug 1 2023
Okay, will go into the next revision. Thanks.
Jul 31 2023
Thanks for the reply!
Jul 24 2023
May 30 2023
May 26 2023
May 25 2023
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:
May 23 2023
May 9 2023
Apr 21 2023
Apr 14 2023
Apr 13 2023
isn't T3456 the same issue?
Apr 12 2023
Apr 3 2023
Mar 24 2023
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.
Mar 21 2023
Things for 2.4 are all done.
For 2.2 we will for now only implement the encryption.
Mar 3 2023
Thanks for the description; this is good for documentation.
Mar 2 2023
Mar 1 2023
Feb 8 2023
Sorry, I mistakenly closed this task. I reopen it.
Feb 7 2023
Could it be the case that your implementation actually used those bits to calculate a public key?
Feb 3 2023
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?
Jan 26 2023
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