Just FYI, NSS offers following API:

I have couple of references from libssh:

gniibe: Can you please check what openssl does exactly. The problem is that we currently have no permanent state for Libgcrypt (i.e. something stored on disk per user or even better global)

FWIW: Unfortunately everyone is moving to GCM, even Outlook. While GnuPG was evaluated by the German BSI we had discussions about this and their evaluators were wary about GCM due to its brittleness thus our use of OCB was very welcomed. OTOH, another approved product meanwhile comes with GCM for S/MIME and thus it seems thatGCM is accepted.

rM6a79e90dedc19877ae1c520fed875b57089a5425 looks good

There is no point in questioning whether a couple of words change racism or any other human problems of these days. It will not.

I was so far testing with changes on top of our patches.

Right. The AES-GCM was not allowed in FIPS mode until recently and I think now it is acceptable only for certain protocols (TLS, SSH), which guarantee that the IV is handled "correctly". As mentioned by gniibe, the requirements is that one should not be able to set IV to any specific value. The IV should be incremented automatically inside of the library (with some mask length + some generator configuration), somehow similarly as it is done with openssl, which would probably requite a new API in libgcrypt.

With `/etc/gcrypt/fips_enabled/', make check fails by:

If I understand correctly, to conform FIPS, we need to ensure Key/IV pair uniqueness (See "Implementation Guidance for FIPS 140-3", Annex C. "C.H Key/IV Pair Uniqueness Requirements from SP 800-38D").
Use of the API to set IV by any value may be considered bad.

Update: still ./basic --fips fails (for me), because of GCM (18 errors).
Need to fix T4873: Enable AES GCM in FIPS mode.

Thanks for the reply, this source code file and suggestions are very useful. Let gpg execute commands is a solution, but it is not optimal compared to providing a functional interface.
In addition, it is reversible to revoke the subkey by expiring it. But I will use the solutions you provide at this stage, knowing that you have time to provide better solutions. thank you!

Sorry, this is not acceptable to me. <rant>You don't change racism by avoid words which are may be connected to racism. Master is a term used for example to indicate that a person is proficient in her profession. Slave is (in theory) a historic term to describe, well slaves. That is humans who are non-free and are not allowed to control their lives - like the majority of humans these days - they are just called different and the methods of suppression are different than in the past. In fact a Roman slave (but not a medieval bondsman) had well defined and esteemed rights not something the majority of US citizen with a dark skin has in practice. Term abolished, racism abolished, works as good as freeing the US slaves in the 1856, the 1960, or still today. It did not work. Mr. Kings hope has not yet realized itself and is now maybe farther away than we all had hoped in the second half of the last century. Don't cover facts by changing words used in a very different context.</rant>

That crcalgo can be any digest algorithm and SHA256 seems best option to me.

Thank you for checking and for revised patch. I tested your patch and it works fine for the basic test up until this failure with the crcalgo:

basic: algo 316, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm
basic: algo 317, crcalgo: 3, gcry_md_open failed: Invalid digest algorithm

These are GCRY_MD_SHAKE128 and GCRY_MD_SHAKE256, but the md used here is actually GCRY_MD_RMD160 which is hardcoded and not allowed in FIPS.

What do you mean by "exporting revocation certificates"? Once such a certificate is imported you simply export the public key including the revocation signature. Otherwise, simply takes the revocation certificates from ${GNUPGHOME}/openpgp-revocs.d where they are written to, if you generate a key. Kleopatra uses gpg directly to generate a revocation certificate mimicking what gpgme would do: See https://dev.gnupg.org/source/kleo/browse/master/src/commands/genrevokecommand.cpp.

That reminds me that we we should replace libgcrypt's internal debug functions by those from gpgrt. We have a dependency for gpgrt anyway and thus we should avoid code duplication. Sure we will keep the existsing public functions but that is easy given that gpgrt comes with gpgrt_logv since 1.28 which we can make mandatory (currently libgcrypt requires 1.27 (from 2017, with 1.28 is from 2018)

I applied rC297d31294333: tests: Fix messages to STDERR when FIPS mode is enabled.. Please note that your intention to change check_digests is right, but your patch actually didn't; When a MD algo is not supported, gcry_md_test_algo returns != 0 (an error code), and it "continues" to next entry (before the change).

Thank you for your report.

Check that the file exists and that you have permissions to read the file. You may use an editor to try this out.

In agent_write_private_key of agent/findkey.c, when file is available, it returns GPG_ERR_EEXIST error. Thus, private (stub) key will be kept.

With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.

This patch for libkleo fixes the build. Alternatively, updating extra-cmake-modules to 5.80 (where the target-variant of ecm_qt_declare_logging_category was added) fixes the build.

Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program:
https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf

It is a matter of the used font. 2.2.29 will fix this problem.

In T5510#147840, @catenacyber wrote:

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

curve=23 secp256r1
point=04555555ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff73a865e2e128733884fb82ce625ade822f7d8a59a4dcc09266966cf1bf082856
bignum=2020ff2020202020202020202020202020202020202020202020202020202020
nettle: 0 045549408909dd3e772d7d669f8fba2248d334b54be3d18833223d944a328948c76198ac3b29712256dcd9ce1a09471f04267684e1edd45910d61d0b7847db2d58
gcrypt: 0 047a6ec0df23082c8ce54c2b536d76b30464f4e1e690bb77665d298f05f0bee6806e7db3377141cc71ee30dcb8ffb7240bc3ecf29132ab5eb4ae03c067cea0d561

Got a new bug with regression range ccfa9f2c1427b40483984198c3df41f8057f69f8:6dfab8cfb94ccb485a15b13df3c499cbb06fddf2

Same error message in Windows 8.1 x64 with the commands:
gpg --local-user 0x12345678 --sign-key 0xABCDEF12 or: gpg --default-key 0x12345678 --sign-key 0xABCDEF12.

Very cool, I like it especially that you avoided a popup and used that action mechanism.