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.

Just one bit of additional information: Using gpg (GnuPG) 2.3.5-beta17 on a large terminal I just tried quick generating a new key with a fresh GNUPGHOME where I only set pinentry-program /usr/bin/pinentry-curses in ${GNUPGHOME}/gpg-agent.conf.

I don't see a point in trying to make the fancy curses pinentry work on small terminals.

There is also the very simple pinentry-tty

As an end user, the --pinentry-mode=loopback flag does exactly what I'd want to resolve this issue. Just to give it more visibility, is there any chance we could try to detect when the user's terminal is too small, and print a message suggesting they use that flag?

I don't see a point in trying to make the fancy curses pinentry work on small terminals. People using small terminals can use --pinentry-mode=loopback to get a simple passphrase prompt that works on terminals of any size.

From my point of view it should be fixed by adding line-breaks to make it work on small terminals. It is better to break the formatting, but allow it, instead of bailing out and leaving the user only with the option to use the more complicated interface. This problem could also affect other password entries where a longer information is displayed.

An alternative to password creation in small terminals could be https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html#Unattended-GPG-key-generation

@LRitzdorf it should work if you enter an acceptable passphrase. (I've just tried with 56x51 widthxheight and it worked)

you also use the CPU cache size on GNU/Linux. Is it important to have that information on MS-Windows?

I don't like it either but the browser vendors don't like SRV records.

I still think that redirecting to another catch-all domain is contrary to the original goal and weakens the security model. We need to see what we can do about this.

The attached patch implements getting the number of processors on MS-Windows.

Thank you, works now on Windows with openpgpkey.sanka-gmbh.de

Independently of that, it seems that gpg4win doesn't work with at least one widely deployed webserver in its default configuration, specifically Caddy, so this fix is well appreciated.