Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.

It seems that the internal API is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.

A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.

New external API is by GCRYCTL_FIPS_SERVICE_INDICATOR and/or the new macro gcry_get_fips_service_indicator.
This change is pushed by rCf51f4e98930e: fips: Introduce GCRYCTL_FIPS_SERVICE_INDICATOR and the macro.

New internal API is introduced with T7340 by the commit rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

Change is pushed by rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

Can we close this?

Applied the change. I write the ChangeLog entry by commit message.

The fix is in 1.10.3.

Fix is in 1.10.3.

Add the check of digest algorithm for EdDSA in: rCd15fe6aac10b: cipher:ecc:fips: Only allow defined digest algo for EdDSA.

No, there are use cases in GnuPG, where we specify the hash algo for signing, and our own tests/benchmark.c.

For the first issue, I added a check in: rCf65c30d470f5: cipher:ecc:fips: Reject use of SHAKE when it's ECDSA with RFC6979.

From the FIPS 186-5 there are some limitations to use the SHAKE in FIPS Mode that we will have to reflect:

Pushed a change in master.

I found the case of X.509, which also uses fixed length output for RSA-PSS and ECDSA: https://www.rfc-editor.org/rfc/rfc8692.html

Thank you for having a look into that! The proposed patch looks good. Should we have this change also in master?

Here is a possible change (... to master, assuming it's good to support use case of RFC 8702):

diff --git a/cipher/keccak.c b/cipher/keccak.c
index 22c40302..76e08cb5 100644
--- a/cipher/keccak.c
+++ b/cipher/keccak.c
@@ -1630,8 +1630,8 @@ const gcry_md_spec_t _gcry_digest_spec_sha3_512 =
 const gcry_md_spec_t _gcry_digest_spec_shake128 =
   {
     GCRY_MD_SHAKE128, {0, 1},
-    "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 0,
-    shake128_init, keccak_write, keccak_final, NULL, keccak_extract,
+    "SHAKE128", shake128_asn, DIM (shake128_asn), oid_spec_shake128, 32,
+    shake128_init, keccak_write, keccak_final, keccak_read, keccak_extract,
     _gcry_shake128_hash_buffers,
     sizeof (KECCAK_CONTEXT),
     run_selftests
@@ -1639,8 +1639,8 @@ const gcry_md_spec_t _gcry_digest_spec_shake128 =
 const gcry_md_spec_t _gcry_digest_spec_shake256 =
   {
     GCRY_MD_SHAKE256, {0, 1},
-    "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 0,
-    shake256_init, keccak_write, keccak_final, NULL, keccak_extract,
+    "SHAKE256", shake256_asn, DIM (shake256_asn), oid_spec_shake256, 64,
+    shake256_init, keccak_write, keccak_final, keccak_read, keccak_extract,
     _gcry_shake256_hash_buffers,
     sizeof (KECCAK_CONTEXT),
     run_selftests

Reading RFC 8702, I realized that it defines the hash size in the use of CMS as: SHAKE128 : 32-byte SHAKE256 : 64-byte.

Applied rC8cdd0d353e19: cipher:pubkey: Check digest size which should not be zero. for 1.10.

I found this use case: RFC 8702
"Use of the SHAKE One-Way Hash Functions in the Cryptographic Message Syntax (CMS)": https://www.rfc-editor.org/rfc/rfc8702.html

Another possibility for digest&sign API: it is possible to determine the length of required hash function by the underlining field Fp of the curve in use. Then, use this length instead. It's better than to (try to) get the length by _gcry_md_get_algo_dlen (for SHAKE, it's undefined).

Fixed in both of master and 1.10 branch.

For libgcrypt, initially when the code was put, it made some sense.
Now, it's useless, so, let's simply remove the message.

Added: rC547dfb5aecc1: cipher:ecc: Add selftests for EdDSA.
Added: rC3ac2bba4a4b1: cipher:ecc: Implement PCT for EdDSA.

I found that for EdDSA other than pure Ed25519, it can supply context.
I changed the semantics and API for adding context and input data, as we need to support both simultaneously.

I changed the lg-input-data.diff patch not to break the ABI, reusing the published symbol of gcry_pk_random_override_new.
With this approach, if/when needed, backporting may be easier.
Drawback is debugging internal of libgcrypt will be a bit confusing.

Let's fix this in Libgcrypt (ignore setting of the handler)

Another approach would be having "non-hash" algo for gcry_md_open.

Before adding FIPS support flag and tests, we need to modify implementation:

• Adding PCT check for EdDSA
• Adding support of gcry_pk_hash_sign/verify API for EdDSA

I'm going to add selftest of EdDSA with test vectors from RFC 8032.

They re-used the same file name for the update from March and no history section. Anyway that looks promising and may solve the problem of having different algorithms allowed for restricted communication in the EU and the US.

Correct, but the last revision of FIPS 140-3 lists the EdDSA already. The same for the IG for FIPS 140-3:

My understanding is that FIPS 186-x lists more algorithms than approved for FIPS 140-y; the approved algorithms for 140-y are in the latest revisions of SP800-140. I have not checked the latter document, though.

Let's schedule that for 2.6

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

If you experience build problems on macOS see T6442

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Fixed in 1.10.2.

Pushed the change.

Thank you.
Applied to both (master and 1.10).