catch the newest version
full git formatted patch here: https://fars.ee/LN-i.patch

My Yubikey (Yubico.com Yubikey 4/5 OTP+U2F+CCID) (key Ed25519) works fine with OpenSSH using kex of sntrup761x25519-sha512@openssh.com.

Thank you. I can replicate the issue.

After re-running myself a few times, I managed to hit it again. In tests/openpgp/report.xml, I see:

[...]
<testsuite name="&lt;keyboxd&gt;tests/openpgp/use-exact-key.scm" time="0" package="&lt;keyboxd&gt;tests/openpgp" id="0" timestamp="2022-04-25T16:18:27" hostname="unknown" tests="1" failures="0" errors="0" >
<properties/>
<testcase name="use-exact-key.scm" classname="&lt;keyboxd&gt;tests.openpgp" time="0" >
<failure message="Unknown error." />
</testcase>
<system-out>
Importing public key.
Checking that the most recent, valid signing subkey is used by default
    &gt; 8BC90111 3E880CFF F5F77B83 45117079 1EA97479 &lt;
Checking that we can select a specific signing key
    &gt; 8BC90111 F5F77B83 1EA97479 &lt;
</system-out>
<system-err>
</system-err>
[...]

Was fixed in 2.3.5

In D435#3175, @dkg wrote:

aiui, the point here is to have the user "service" get triggered somehow (through pam's pam_systemd.so's session module?) before ssh goes ahead and forms the socket. is that right? If the pre-launch mechanism is pam, is there a reason to do it as a systemd user service? That won't work for systems that have pam but don't have systemd, whereas a pam module that creates these will work.

is there any update ? I having the same Issue here on Windows 11 Pro, Outlook Version 2203 (Microsoft 365) 64bit

Any idea? Any update?

Works together with the changes for T5939: Kleopatra: Better error for wrong password in symmetric decryption. Tested with symmetric encrypted file and with symmetric+pk encrypted file.

Thanks. Will go into 2.3.6

Please contact the Debian developers for any systemd/gnupg issues. We don't suggest the use of the --supervised option because it causes more problems than it claims to solve.

I pushed the change above. I also pushed another change with IOBUF_INPUT_TEMP.

In this case it works, because the error messages are not translatable.

Sorry, I was confused. For RSA-4096, data is hashed by gpg-agent and hashed data is signed by a card.

In T5939#157259, @werner wrote:

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

We are using rsa-4096 on smartcard for quite some time; so I wonder what's the problem here. Is that that we don't use our Assuan hack for large key material with OpenPGP.3?

There is another case: RSA-4096 key. scdaemon rejects data by Invalid value. Unfortunately, there is no fix for this, as it's really too large. Even if scdaemon allows larger data, the card implementation rejects, when it conforms to PKCS #1 standard (data should not be larger than 40% of the modulus).

Thank you for the bug report.

You should not use log messages because they are subject to change and they are translated. Let us return an ERROR status instead.

Should also go into 2.2

The rest of the code looks fine.

I have added the check for a possibly wrong symmetric password to QGpgMEDecryptVerifyJob because it relies on logging messages emitted by gpg which are not part of gpg's status API.

The error

gpg: decryption failed: Bad session key

is only logged if the sanity check "algo given in decrypted session key is a valid OpenPGP algo" passes even though a wrong password was given (which happens with a chance of 11:256). If the sanity check detects a bad algo then gpg logs

gpg: decryption of the symmetrically encrypted session key failed: Checksum error

If AEAD is used, then other logging will happen.