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

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

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.

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.

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

Some ideas:

• the someflags thing will probably just be a reserved parameter
• If DATA is not NULL but an MD is set the sign function should fail
• Should ownership of MD be moved to the CTX?

In an email from @werner couple days back, I got a suggestion that we could use hashing tied to the context, rather than this one-shot call tied only to digests. I circled back this suggestion to Stephan and he confirmed that it should be fine from the FIPS point of view so I am posting the suggested API here too:

ctx = gcry_pk_new (someflags)
md = gcry_md_open (...)
gcry_ctx_set_md (md);
gcry_pk_sign_ext (ctx, result, data, skey)
[...]
gcry_ctx_release (ctx);

OK. I think that the patch at SUSE is updated one which works.
As I understand correctly, this is a kind of very old patch, which intended to work around old libgcrypt limitation of RSA PSS.

I think that {D1476} is still a sketch (not real code which works). I would guess an intended use, but it's good to have concrete example program which uses the feature being added.

FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
and SUSE seems to already use a modified API:
https://sources.suse.com/SUSE:Maintenance:15118/libgcrypt.SUSE_SLE-15_Update/26a8df5f96d27d6abca7bd7ba9b0def0/libgcrypt-FIPS-RSA-DSA-ECDSA-hashing-operation.patch

Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.

Does the patch really work, or is it a sketch to describe the intended use?

I recall that I talked with Stephan about it but things got lost.