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?

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.

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.

@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)

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).

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.

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.

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).

Maybe GnuPG could display a prompt if it detects a pubring.gpg and no pubring.kbx. Something like:

@gniibe: We move this issue over to mail. I'll forward it to you.

If I were testing more, I would generate many (say, 1000, or more, for example) encrypted message by the tool (IBM Encryption Facility), to examine by GnuPG and figure out some patterns of failure.

While I only observed the output of --list-packet, what I see are:

With NTBTLS, it seems it works correctly.

Err... my repo for 2.2 was a week old. Now, I updated, and confirmed it's there.
Thanks having the support!

Release done.

I did this already on July 3 with commit 458973f502b9a43ecf29e804a2c0c86e78f5927a

Please consider to backport rG914fa3be22bf: dirmngr: Support the new WKD draft with the openpgpkey subdomain. from master. Cherry-pick mostly works, only dirmngr/server.c needs manual edit (because of resolve_dns_name change).
Allowing WKD service by subdomain (openpgpkey) is good, because it is easier to deploy by separate admin, in some situations.

Quiet tricky to get right; needs some rework.

Done for master and 2.2.

Once a revocation is added (to any part of the certificate), perhaps all the certification packets that are clearly made obsolete by the revocation could be dropped from the certificate? That would certainly free up space to be able to import additional revocations if needed.

And of course, thanks for your fix.

Applied to both branches. I have run no tests myself, though.

Fix will be in 2.2.17

Fix will be in 2.2.17.
See T4612 for the revocation case.

@dkg I believe @aheinecke gave the GpgOL description just as an example of why WKD-first retrieval would be beneficial (for details of that see https://wiki.gnupg.org/AutomatedEncryption#Trust_Levels) and I believe this ticket is a follow-up to my question on gnupg-devel ML: https://lists.gnupg.org/pipermail/gnupg-devel/2019-June/034372.html

auto-key-retrieve happens in the context of signature verification when the certificate is missing. If no signer User ID subpacket is present in the signature, then WKD simply won't work.

I asked you to carry this to a mailing list and not re-open this task.

if you want to add a separate subcommand for that, i would be happy to abandon migrate-pubring-from-classic-gpg.

My plan is to let --search-key be the same as locate-key but without local lookups, thus it will be the same as

Okay, if an attacker exactly hist that limit your case is valid. I see no easy fix here, though. What we can do is what is done on Unix file systems to give average users a disk full erroreven if there a few percent of the disk is free; root can use that extra space then. Revocation certificates would be what root is on Unix file systems.

That was pretty easy to reproduce thanks to your still not working server.

I somehow expected such a feature request ;-). However, I do not think that an automatic migration is is appropriate for the stable branch.

Will be in 2.2.17

Oh dear, that happens if one is always on master. I simply forgot to cherry pick the change from master back in November.
Two commits, though.

my initial scenario is where an adversarial keystore floods a certificate right up to (but within) the 5MiB boundary, so that the user has stored it in the keyring already. Then, the user encounters the certificate again, with revocation attached.

I don't think so. The fallback mechnanism will still work and remove everything but valid self-signatures. This gives enough space to write the keyblock with the new revocation certificates. I am not sure about designated revokers in this case.

as a separate variant: if the attacker floods the certificate with bogus self-signatures -- that is, certifications that have an issuer fingerprint or issuer key id subpacket, whether hashed or unhashed -- will that make it impossible to import any of them?

Thanks for working on this fallback, Werner.

Also pushed to 2.2. Right now I can't see what else can be done, so I change the status to testing.

I implemented that in master. The first output is from an update of your key and the second from an insert of a new key.

That won't be easy to debug unless we have intermediate debug values from the generating implementation. That IBM Encryption Facility looks partly similar in the command line options to gpg so I wonder whether it will be possible to get some debug output. @mrdave19: we can continue by private mail in case that is helpful for you (wk at g10code com)

I should add that i don't really care whose fault it is if the software is broken by some downstream. if it harms any users, and we can fix it, we should fix it, especially if the fix is easy.

We're writing free software, which we know that people use and modify downstream. if we know that the software has a particular sharp edge that people who are modifying it are likely to cut themselves on, we have two options:

Come on, if someone changes the software and breaks it, it is their's fault ant not ours. The whole thing on which keyserver and certificate to use as been discussed ad nausea in the past. Given all the problems with the keyservers I do not see a reason to change it right away to a state we had before. Keyserver code is pretty hard to test and has thus always been prone to regressions.

(See T4175 why this changed in 2.2.12.)

Even if you can't use it the option is still useful to avoid other kinds of DoS. As written in the comments it is not a full solution but it helps to side-step issues with key-signature. In particular for sites which do not have a need for them.
BTW, revocation certificates are still merged with the new option.

If the default keyserver is not hkps.pool.sks-keyservers.net, then @kristianf's CA certificate has no business certifying it.

Welcome back from vacation!
@aheinecke Yes I am 1000% sure the passphrase is "dave" without the quotes.
These are the commands I use for the encrypt using the IBM Encryption Facility:

-o '/home/suimgwy/_july1.pbe' \
-s2k-cipher-name AES_256 -s2k-digest-name SHA256 -s2k-mode 3 \
-s2k-passphrase dave \
-t ISO-8859-1 \
-use-mdc \
-c '/home/suimgwy/_input.txt'
<<<

thanks for working on this @werner. rG2e349bb61737 is definitely not useful for me. If i am going to tell anyone "hey, do this weird thing differently in order to fetch my key", i will tell them "pull it from https://dkg.fifthhorseman.net/dkg-openpgp.key". I will never tell anyone to use import-self-sigs-only.

That is probably not what you want but at least it allows to import your key

back from vacation so apologies for the delay. @werner This is reproducible on the command line without Kleopatra. So maybe something for you our Gniibe to look into?

I have mentioned it several times in the past that I would like to see the search by user id feature be removed from keyservers so that there is less incentive to use them as a perpetual and searchable database for maybe illegitimate data.