Thanks for working on this, @gniibe! Maybe it would be useful to add a test to the test suite that tries to import and use a secret key of this particular structure.

Please try a decent version of Gpg4win - we have fixed dozens of bugs in the mean time If the problems persists, please re-open this bug.

Use our build system and things work. In particular you need to use the software versions as listed at versions.gnupg.org and available via the build-auch/getswdb.sh. Even better use the speedo build system for Windows. Everything else is not a supported build configuration.

Thank you for the report.

The fix was not right, because gpg-agent side are not changed. See T5953.

In T5950#157442, @ikloecker wrote:

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

Moreover, please make sure that there is no text in the field above the table (in the second figure) because this text is used to filter the displayed certificates.

I located the problem. The test program use-exact-key invokes two gpg-es connecting by pipe (one gpg to generate a signature, another gpg to verify the signature). Those multiple gpg-es race accessing keyboxd.

Another test, it took 30 minutes to replicate.

I'm afraid we need a bit more information. Please tell us the exact steps how you can reproduce the problem.

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>
[...]

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

Any idea? Any update?

Thanks. Will go into 2.3.6

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

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

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.

I confirmed that the patch above works with newer Gnuk (>= 1.2.16).

With newer Gnuk Token, following patch should work:

diff --git a/scd/app-openpgp.c b/scd/app-openpgp.c
index 05e1f3977..439052f8c 100644
--- a/scd/app-openpgp.c
+++ b/scd/app-openpgp.c
@@ -5490,6 +5490,11 @@ do_auth (app_t app, ctrl_t ctrl, const char *keyidstr,
           exmode = 1;    /* Use extended length.  */
           le_value = app->app_local->keyattr[2].rsa.n_bits / 8;
         }
+      else if (app->app_local->cardcap.cmd_chaining && indatalen > 254)
+        {
+          exmode = -254; /* Command chaining with max. 254 bytes.  */
+          le_value = 0;
+        }
       else if (indatalen > 255)
         {
           if (!app->app_local->cardcap.ext_lc_le)

Feedback from the lab is that they'd recommend returning a specific error code that indicates that the prime search failed and then relying on the caller to decide whether to loop or bubble up the error. I'm not sure who we would consider to be the "caller" of the relevant generation function in this case, though.

For the record, I am for the deletion as long as it is guarded by a safety check.

Here is my proposal patch:

diff --git a/random/random-drbg.c b/random/random-drbg.c
index 5a46fd92..f1cfe286 100644
--- a/random/random-drbg.c
+++ b/random/random-drbg.c
@@ -341,6 +341,9 @@ enum drbg_prefixes
  * Global variables
  ***************************************************************/

That sounds reasonable. The FIPS 186-5 draft (https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5-draft.pdf) covers this in section A.1.3, although I'm not quite sure why a lower bound for p was chosen compared to q. The comment that seems to have triggered this change is published on page 68 of https://csrc.nist.gov/CSRC/media/Publications/fips/186/4/final/documents/comments-received-fips186-4-december-2015.pdf by Allen Roginsky. It only contains a suggestion of 20, presumably for both numbers.

In Kleopatra's KeyToCardCommand there is this comment

/* TODO DELETE_KEY is too strong, because it also deletes the stub
 * of the secret key. I could not find out how GnuPG does this. Question
 * to GnuPG Developers is pending an answer

before a commented out code snippet that asks the user whether the key should be deleted locally and, if the user confirms, asks the agent to do DELETE_KEY --force <keygrip of subkey>.

I checked FIPS 186-4 (and FIPS 186-5-draft). It is Appendix A 1.3.

• Fixed in 2.3
• assert replaced by a fatal error message

Printing a note as we do in --edit-key is a good idea.

Patches applied and pushed. For the common/t-ssh-utils, I applied my fix for the use case with key on command line when FIPS mode is enabled (MD5 error is OK, in this case).

For anyone stumbling across this issue I created a docker image containing gpg with the patch above applied: https://github.com/smlx/gnupg-piv-agent

I was pointed by Daiki to the following patch in Fedora binutils, which allows listing the fdo packaging metadata, but it does not list any other unknown objects and unfortunately fails hard:

The reason for this is probably that we expect that several UIDs are added and running a check-trustdb for eachleads to some extra waiting time.

I just copied the value of 0xcafe2a8e and the name .note.fdo.integrity from Daiki's implementation. No other reason.

I have one follow-up is that the readelf chokes on the integrity note for some reason:

$ readelf -n /usr/lib64/libgcrypt.so.20.4.1
Displaying notes found in: .note.fdo.integrity
  Owner                Data size 	Description
  FDO                  0x00000020	Unknown note type: (0x8e2afeca)

I assume this is just because the readelf does not know this type. I see this type was initially proposed by Daiki, but I did not find any other sources for this magic number so before filling bugs for readelf, do we have some doc why the 0xcafe2a8e is used?

Have you selected an Output file in a location where you can write files with your permissions?

I had already tried both, to deselct all other add-ins and to select all possible add-ins.
No change of the behaviour.

Could you please create a log file using the debug settings with Outlook Object Model debugging enabled?

libgpg-error 1.45 is out with the fix.

The set_bit is obvious but we should cross check with the specs. In the non-fips mode we also try w/o a limit.

I think that it is OK to loop forever until we find a prime.

I don't know the exact procedure by FIPS, but just setting the least significant bit in the generation (after _gcry_mpi_randomize) can reduce the probability by half.

On at least some small terminals (like the smartphone size I mentioned in my original comment), I can confirm that this is a true loop. When originally reporting the issue, one of the things I tested was repeatedly pressing the Enter key with an empty password field. In that test, the password prompt looped for the 20 or so times I continued to press Enter.

I experimented a bit. The problem is the size of button texts of the confirmation dialog, i.e. of "Yes, protection is not needed" and "Enter new passphrase". pinentry-curses checks if 3 times the size of the longest text plus a few pixels for the frame fit into the terminal's width. There can be up to 3 buttons, but in case there are only two buttons this check is too strict.

Hmm, okay. Trying the same on an 80x72 terminal I can indeed reproduce a loop. Sorry, for the noise.