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.

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.

Oof. That hinges on the certificate, guess we'll need to renew the bunch of them. I reconfigured, might take a while for all pages but ciphers should now be:

The ECDHE_ECDSA suites are not yet implemented in ntbtls and thus we can't agree on a common cipher suite. Will be solved in the next Windows version.

In the above test, I was using
Windows: 2.3.4
Debian: 2.2.12

I captured some logs server-side, and I do see this error:

Are you using 2.3.4 also on Windows?

I have the same error when using wkd.keys.openpgp.org with a CNAME DNS entry. The error occurs with Windows 10, 11 and Server 2019 (only the most recent versions tested). With Debian it works fine.

see rC67b36154f88e for master.

Will add it. The reason I added Brainpool was due to a question on the performacne between Brainpool and other NIST.

Not applying the change to GnuPG 2.2, users can use GnuPG 2.3 for that.

Done in 1.10.1.

Good idea. Thanks. Goes onto 2.3 and 2.2

we have a similar problem in our organization. We're using Outlook from Office 365. For two weeks now we have set a GPO for Outlook to prefer plain text messages like in @kimmoal's organization environment.
This causes the same problem: We are getting blank emails when they are encrypted or signed.

When we will find reproducible test case, please reopen.

See also T5537 and commit rG7d1215cb9cba2 for 2.2.

There is actually a much easier fix here. Thanks for pointing out the problem. For histroical reasons we have several places where we create the homedir.

Confirmed to work, thanks!

Thank you. Applied.

Thank you for the error output.

it still shows the no certificate or invalid encoded error message:

Indeed, different versions of MinGW use different symbols to guard the declaration, and using those symbols in not future-proof enough, IME.
Removing the declaration is definitely the best solution.

I gave it a try. It works now, but it still shows the no certificate or invalid encoded error message:

And I move functions from pinentry.c to pinentry-curses.c, so that pinentry-w32.exe can be build with no libiconv (which is actually not used).

Thank you for your report.

Merged into T5804.

Thank you. Confirmed.

Thank you for the reproducible test case. Confirmed.

Pushed the change removing the definition.

GetNativeSystemInfo. Would you like me to submit a patch that used that in jent_ncpu?

Sorry, HOME and ~/ are not standard on Windows and applying your patch may break existing installations.

Yes, I see the problem:

In T5889#156302, @gniibe wrote:

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.

Thank you. Confirmed.

Thank you.

Considering again, I think that just removing the definition of the struct timespec in npth.h is the best approach, given the situation, it's been there for MINGW64 and it's now in original MinGW.