If the use of GnuPG (current implementation) is a condition, I think that you could improve the generation of SKESK packets, so that no other passphrase can not let gpg misunderstand as it may decrypt encrypted packet.
Unfortunately, for my use case the corresponding SKESK packet number is not known when calling GnuPG.
I use the internal driver.
I'm aware of you releasing an RC for comments, and i apologize for not catching this particular case earlier. As you know from T4607, i was even advocating for it. i didn't understand the full implications of the "import-then-clean" approach at the time, and was thinking it would only apply to the incoming material, not the stored material.
Are you using pcscd (is that process running) or the internal driver.? Please try the latter if you are not already using it.
The code has comments why we do a first clean_key on the imported keyblock.
All my keys are RSA 4096. It worked fine with OpenPGP smart cards and with two Yubikey 5. On all devices a set of RSA 4096 keys were geneated on the device itself. Only one card failed. But even the card which failed, generated at least the signature key in RSA 4096.
Please let us know what kind of key and how large, like RSA-4096 or ECC Brainpool.
For RSA 2048 or larger, yes, it takes too long.
I mean, if all SKESK packets should be tried, we need some larger surgery of current implementation.
Is it possible for your application (DOTS), to specify the packet number for SKESKP, not trying all SKESK packets?
^-- with this change, we can decrypt the skesks.asc with --passphrase-repeat=169, and skesks2.asc with --passphrase-repeat=30
i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.
Wed, Jul 17
@gniibe, thank you for backporting this to STABLE-BRANCH-2-2!
But that's exactly my use case in DOTS: an easily to create 'decryption puzzle' (including the hardness of iterated and salted S2K) for the serving party in order to make DoS harder. I don't see how public-key crypto can help here. Moreover, I would keep the user interaction as cheap as possible, i.e., copy'n'paste an ASCII-armored message and passwort to GnuPG without importing public keys etc.
The problem here is that trial decryption may cost a lot of time because of the passphrase KDF function which, on purpose, takes long. There is one exception: A simple S2K (algo 0) takes no time and its use makes sense iff the passphrase has been created directly as a random string. However, I do not see the use cases for of a set of many passphrases compared to just use public key crypto.
I should may add, that on the card which failed, only the signature key was generated and written to the card. The authentication and encryption keys could not be generated..
@gniibe Thanks for explaining the background. Are there any ideas for fixing? (e.g. the decrypted content could be checked for a valid packet structure or at least for starting with a valid packet header)
does the removal of the gpg22 tag mean that it will not be possible to rely on colon-delimited output for the gpg 2.2 series?
Tue, Jul 16
Just a note that we're now shipping this patch in debian unstable. It would be great if it was merged upstream.
that pseudocode is strange to me -- it looks like you have (two) duplicate calls to clean_key (imported_keyblock) (though maybe i just don't know what .... means in this pseudocode).
Thanks, fixed in master.
You are partly right. I missed that we also do clean the original keyblock while updating a key. The code is
I see. I am also mostly testing with ntbtls so I was wondering about the report. Thanks for reporting and fixing.
Current situation of *.pc: static linking is not supported (yet).
It has never supported, actually, by *-config.
While I understand incorrectness, the risk in practice is not that high. So, I put this as "normal" priority.
In the current implementation of GnuPG, multiple packets of Symmetric-Key Encrypted Session Key Packet are not handled very well.
Pushed the change to master as well as 2.2 branch.
Mon, Jul 15
I think dropping import-clean from the default keyserver options is the right way to go. It is not clear what additional benefit import-clean provides given that we are already using self-sigs-only. And the idea of non-additive behavior to the local keyring when pulling from a keyserver is a deeply surprising change for multiple users i've talked to.
The fact that import-clean modifies already-held certifications makes me think it is inappropriate to have as the default for keyserver access (see T4628 for more details).
I am proposing to backport rG33c17a8008c3ba3bb740069f9f97c7467f156b54 and rGa7a043e82555a9da984c6fb01bfec4990d904690 to STABLE-BRANCH-2-2 as they represent a significant performance improvement in several specific use cases and appear to have no downsides.
If you're on a platform that has awk available (any GNU/Linux and MacOS should provide it), you can scan for the largest OpenPGP certificate in your keyring with an awk script i posted over at https://dev.gnupg.org/T3972#127356