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.

For the reference, for now i just did the dummy install in the Fedora spec file:

Nope, The gpgconf --kill keyboxd hangs too, if I see right, while waiting for agent:

$ strace gpgconf --kill keyboxd
[...]
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2d74fe2a10) = 3244
wait4(3244, 0x7ffc9836e364, 0, NULL)    = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

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

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

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

FYI, while going through the licenses again I noticed one of the pinentry files have even older address that so if you would do sed, this would not be matched:

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

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);

We discussed this further with the lab and there are more problematic flags that we need to "cut" and we can not do that always in the code as for example the RFC6979 (deterministic ECDSA signatures) are not allowed in the current version of the FIPS documents, but it is used in the selftests (which is weirdly enough allowed) so we just need to mark it unapproved. Lets discuss this further tomorrow.

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.

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.

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:

I tried to clarify the comment in the following merge request. Feel free to pull it from there or adjust if it is too verbose or missing some points:

In rCa6a6e94027abf18a51f5f93bf9fb2cfe5496bdf8#74835, @werner wrote:

Why is that not stated in my man page which knows about kernel 3.19? Is that a regression or a RedHat specific patch?

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:

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

This still did not seem to help me in making the tests working on Fedora with git master. I am still getting wrong paths to the gpgconf

gpgscm: error running '/root/gnupg/tests/tools/gpgconf': probably not installed

There is a full reproducer and more complete log in https://bugzilla.redhat.com/show_bug.cgi?id=2089075#c11

Thank you for your work on the proposal. I have two comments:

• Do we have some test vector, which can be used in the testsute to test the new API?
• We need to mention the new API in the documentation.

For the record, the changeset in the attached merge request is final and waiting for reviews.

The provided change does not look like fixing the problem for me. The path to gpgconf is still wrong and I am getting the same error both with master and with the patched tarballs:

make[2]: Entering directory '/home/jjelen/devel/gnupg/tests/tpm2dtests'
LC_ALL=C EXEEXT= PATH="../gpgscm:/home/jjelen/.local/bin:/home/jjelen/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin" abs_top_srcdir="/home/jjelen/devel/gnupg" objdir="/home/jjelen/devel/gnupg" TPMSERVER="" SWTPM="/bin/swtpm" SWTPM_IOCTL="/bin/swtpm_ioctl" GNUPG_BUILD_ROOT="/home/jjelen/devel/gnupg/tests" GPGSCM_PATH="/home/jjelen/devel/gnupg/tests/gpgscm" /home/jjelen/devel/gnupg/tests/gpgscm/gpgscm \
  /home/jjelen/devel/gnupg/tests/tpm2dtests/run-tests.scm  
gpgscm: error running '/home/jjelen/devel/gnupg/tests/tools/gpgconf': probably not installed
(wait-process "/home/jjelen/devel/gnupg/tests/tools/gpgconf" 2693795 #t): Configuration error