Here's fix for mode specific setkey clearing error code:

There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:

@jukivili Yes, please go ahead for both branches. Thank you.

About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.

Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.

In T6451#169608, @gniibe wrote:

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thank you for you responses! :)

I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.

tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.

That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.

Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.

Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.

Fixed in 1.10.2.

Your quick support solve my problem, I am thanking you :)
Bye bye

I added a remark to the print function. Thanks for the suggestion.

You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".

Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.

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

Right, thanks for the review! Updated patches below.

Actually, the same issue is in the mac case, which I missed on first couple of reviews:

-  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);
+  enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_mac_algos);

Going through the code once more, there is one typo to be fixed:

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);

should say

+_gcry_fips_indicator_md (va_list arg_ptr)
+{
+  enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_md_algos);

otherwise ack.

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.