You are combining two concepts here -- the KDF and the AEAD cipher itself (at least from the FIPS terminology). I would like to avoid mixing these two together in the new API. If you would like to implement the SSH/TLS KDF, I would suggest to use the kdf API you already have. Then we are here left only with a new geniv API to implement. In the T4873 I mentioned example how it is now used in libssh using libgcrypt, which implements the iv increment outside of the libgcrypt:

Thank you for the report.

I located the cause; Current implementation cannot parse the data like:

2611:d=5  hl=4 l=1632 cons:      cont [ 0 ]        
2615:d=6  hl=4 l= 500 prim:       OCTET STRING
3119:d=6  hl=4 l=1124 prim:       OCTET STRING

Is large change to cipher API really needed (new open/encrypt with less flexibility)? How that would affect performance? Would following new interfaces to gcry_cipher API work instead?

• gcry_cipher_setup_geniv(hd, int ivlen, int method): for setting up IV generator with parameters such as IV length, method id (RFC5116, TLS 1.3, SSH, etc), (other parameters?)
• gcry_cipher_geniv(hd, byte *outiv): for generating new iv: generate IV using select method, set IV internally and output generated IV to 'ivout'.
• gcry_cipher_genkey(hd, byte *outkey, int keylen, int method): for generating keys, generate key internally with parameters (method id, other?), setup key internally and output generated key to 'outkey'. (how keys from key exchange protocol be handled? using existing setkey?)

I went through my test files and found that --enarmor on zero length input file did no longer work. I made separate patch to fix that issue, which then also needs another approach for handling compress issue noticed earlier:

The mails from these days still contain the following header:

List-Post: <mailto:gnupg-devel@lists.gnupg.org>

which is probably causing the mail client directing the mails to this address. Is there a way to change or or make it an alias so it is easier for people to use the mailing list without finding this issue?

Should be fixed.

Ack from me for new 0005 and 0006.

More things to be considered:

• How to connect scdaemon
• How to invoke scdaemon

The patch for T5834 (https://dev.gnupg.org/rMad3aabdd8a64156c7e3a75d695ae1ab2c4bec841) was already applied to the build of GPGME 1.17.0 for Focal, as I did browse the list of latest GPGME bugs first before reporting this bug. Attempting to build with the latest GPGME 1.17.1 (with the included ABI patch) results in exactly the same FTBFS for i386 only, so this does appear to be a distinct issue not related to that of ABI backwards compatibility.

Does this look ok to push to master? @werner @gniibe

Please see T5834 which is fixed in 1.17.1

Fixed in 1.17.1

Note the ABI bug the Qt version of 1.17.0 which is fixed with 1.17.1 (T5872)

BTW, there are various use cases for authentication(s), it is better to focus on the part of device and crypto (USB Token and scdaemon).

Here is an experimental shell script for testing:

New versions of patches 0005 and 0006 - fixes EOF handling issues noticed with compression/decompression:

From the parent task "I think having the [...] keyselection when encrypting improved is the best way to help current users of the software who might already have received help from a collegue to import and have a list of certified certificates available."

Ready for testing

Ready for testing

I think this is not urgent as we are able to FIPS certify libgcrypt without that, but the modern protocols and algorithm use this and if we want to use libgcrypt to implement these in FIPS compliant way, we certainly need something like that.

Fixed.

Please describe your problem in more detail. Also: Which version of GpgOl and Outlook are you using, SMTP/IMAP or Exchange?

I don't think it is justified to tag this as "unbreak now" - which we use for severe bugs inhibiting the use of a deployed version.

I'm not sure. In KeyResolverCore::Private::resolve() line 668 reads

const bool pgpOnly = (!mEncrypt || !hasUnresolvedRecipients(mEncKeys, OpenPGP)) && (!mSign || mSigKeys.contains(OpenPGP));

I'd say this is supposed to check if there is an OpenPGP signing key, but I guess mSigKeys[OpenPGP] is an empty list. This may be a regression introduced by the resultion of key groups because in KeyResolverCore::Private::resolveSigningGroups() the entry mSigKeys[OpenPGP] is always set (unless we are in CMS-only mode).

Yes, unit tests still pass. So its ok with you to commit this?

What about at least accepting env variables OR tilde expansions? That will make it easier to integrate with dotfiles that intentionally use a home-dir based executable without having to pass the full path, so it could work cross platforms.

Sounds familiar, that the signing keys are not considered. I think when I worked on this, I thought that is was a bad idea to mix resolving signing and encryption keys. Do the unit tests still pass with your change?

@ikloecker
If I test the resolver code from libkleo with gpg4win-tools keyresolver binary:

pinentry-qt with new icon: