We came to the same conclusion -- the SHAKE digests are not usable for sign/verify operations the way how it is implemented now. But it would be more clear if we would have explicit allow-list.

After consulting with our certs lab and studying the code I think SHAKE should not be a problem for now. All of the _gcry_digest_spec_shakeXXX seem to neither have an mdlen nor a read() function. pk_sign and pk_verify seem to both call md_read() which should fail because of the missing read function, kdf checks _gcry_md_get_algo_dlen() which should also disallow SHAKE.

Good catch. A similar problem might arise with SHA384 according to section D.R which states

One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:

These look good to me.

Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:

This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.

Thanks

Well, I do not yet see a use case for this. The current rush towards PQC makes it unlikely that newer curves will get in widespread use. Iff we have a large application which requires this curves, we can reconsider,

Sorry, but we can't check all parameters. Why only check that one and not the others or invalid values for ctx. You may do such checks in an interactive environment but not for a general library.

See T6340 in case of build problems.

Thank you for your reply! I'll modify my testcase

I figured out the situation.

Ah, I found that we have very bad example use case in tests/t-mpi-point.c. This should be fixed at first.

Thank you for your report. IIUC, it is called unexpected way, like invalid/wrong KEYPARMS. Possibly, KEYPARMS == NULL, or something like that.

When I look at the stack information, I find that because E->p is not assigned in the function mpi_ec_get_elliptic_curve(), this produces a null pointer，but it didn't get to the branch : if (errc) goto leave;

If you pass NULL to that function, the calling code is wrong. No need for an explicit check in nomralize - check should be done in the public API (if at all).

I tried to fix the segmentation fault, so I added a null pointer check at the end to protect it.

Sure, but this will need adaption in FIPS mode as it fails with:

Patch using SHA1 instead of MD5.

There are other uses of MD5 and thus we can't disable it. For example gpgsm also lists the MD5 fingerprint of certificates because they are still in use at some places.

Well, the modern way, recommended by the FSFE, for license notices in source files is SPDX instead of verbose license notices. https://reuse.software/

Modern way for license notice seems use of URL: https://www.gnu.org/prep/maintain/maintain.html#License-Notices-for-Code
https://www.gnu.org/licenses/gpl-howto.html

I put rCc34c9e70055e: fips: Mark AES key wrapping as approved. under this task, so that it can be referred in the release note.

Let me describe the changes recorded in this task.

Thanks. There should also be SPDX indentifiers everywhere.

Yep. Closed now.

@jukivili: This has been released with 1.10.0 - shall we close this bug?

Go ahead if you want to do that.

Thank you. I am glad that it is already resolved.

Will this be in the next release of libgcrypt?

Okay. So, I removed gpg-error-config, updated libgcrypt/m4/gpg-error.m4, and then rebuilt configure. And, gcrypt configures and builds.

Thank you for the information.

Actually, it looks as if libgpg-error-1.46 already has that fix.

Thank you for your quick reply.

Yes, it is on macOS.

From the information in gpg-error.pc, I think it's on macOS.

In regards to this issue, we were also notified that the MD API using gcry_md_setkey() can be used to calculate HMACs and it does not have the needed input key length limitation. From the discussion here I read that we would like to keep the internal usage still available so my proposal would be to to add similar check as in gcry_mac_setkey() into the above function. Together with the revert, it is available in the following merge request:

In T6039#164435, @gniibe wrote:

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

I read the document (SP 800-131Ar2) again. I think that it would be irrelevant for PKDF2, because it's password KDF, not deriving additional keys from a Cryptographic Key.

Please note that: libgcrypt offers ECDH functionality by gcry_pk_encrypt/gcry_pk_decrypt to construct OpenPGP public-key encryption/decryption.

So, this is only for OAEP but not for ECDH? FWIW, GnUPG uses OAEP only for S/MIME.

It's not that needed, in my opinion, as nobody actually uses ECB itself (in real use case). But I understand the point of (possibly, students') benchmarking.

Pushed the change, although it is not enabled yet (since the feature will be only available by newer libgcrypt, 1.11).

One more nit regarding to the test is the format string for size_t which was using %d instead of %zu. This is fixed by the attached patch:

Also applied to 1.10 branch.

Patch applied to master, thanks.

One nit that I overlooked initially is the memory leak, which is fixed with the following patch:

The specs https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf page 10 says specifically:

I've tested the different hw implementations (amd64, arm64, s390x) and they are all ok.

Thank you for your report.

My poor old laptop - its RAM will now have a hard time to run the huge tests ;-)

The test looks good. I hope I changed the API in all the hw optimized implementations.

Fix looks good to me. This could be tested with new long running test (tests/hashtest) that would allocate 4GiB+ pattern block for inputting to gcry_md_write.