Yes, keep the internal SHA-3.

We will have rnd-getentropy.c

Applied and pushed symmetric algo for basic.

Let me clean up rndlinux.c for current use case, at first.

I decided to use 3.3.0 disabling pthread feature.

Thank you for merging the important parts of the patches and implementing similar stuff for DSA. You are right that DSA is supported in the 140-3 specs so it is fine to keep it enabled with the keylength constraints.

Applied parts except part 2.
The part 3 are modified version, so that memory can be released correctly.

Implicit indicators mean that we need to go through the all algorithms and verify that they work if they have approved key sizes/parameters and do not work when they do not.

Firstly, applied uncontroversial part in rC976673425784: doc: Reference the new FIPS 140-3

If I read it right, the version 3.1.0 adds the pthread requirement. Using 3.0.2 should be fine for us.

The most of the stuff about boot blocking was discussed in the bug https://bugzilla.redhat.com/show_bug.cgi?id=1569393 (private). There were some bugs in our patches, but also some issue in the kernel that locked the boot process (in FIPS mode).

Check for FIPS has been added. (1) and (2) were solved.

Its copyright notice in upstream now refers LICENSE file, which requires some arrangement.

I work on gniibe/jitterent branch.
I realized that full featured jitterentropy now requires pthread. Timer-less mode uses threads for entropy. This is not good for libgcrypt use.

OK. Sorry for the noise. I got a clarification that the test is no longer needed so closing this issue.

From the FIPS Certs draft for RHEL 8.5, I have the following sentence:

We are currently using "implict" service indicators but eventually we may change Libgcrypt to support explicit indicators.

I understand the point in the 1706920, but I'm afraid that the patch itself would not be directly related for the bug. My point: It surely may catch a most serious failure, but not many failures (if we need to check here).

Fair enough. Unfortunately, the separation is not completely clear from the dist git history, so please, excuse any inaccuracies I will provide here. I will try to reference particular bugs so we can get back to them if needed:

At this moment, we agreed on keeping the current behavior and not allowing the SHA1 for verification either. But we might need to revisit that in the future if this will cause issues. Or we might go the way of switching the service to non-fips if needed, rather than creating some more middle ground.

Perhaps, as a library (considering the benefit of users), it would be better to allow signature verification with SHA-1, to defer the decision to application.

Thank you for having a look into that. The change looks fine, but I need to get some clarification about what "Legacy use" means for "Digital signature verification" in the Table 8 of https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

(3-1) is implemented: rCa23cf78102f3: cipher: Reject SHA-1 for hash+sign/verify when FIPS enabled.

For a programmer like me, it is easier if the behavior will be:

The problem is that the SHA-1 as a digest algorithm itself is allowed in FIPS mode (for non-cryptographic digests), but using it as part of approved signature scheme is not allowed

The current code is inconsistent about its behavior: how non-approved digest algos are supported or not when FIPS enabled.

If .fips will mean FIPS 140-3, why not the following patch?

diff --git a/cipher/sha1.c b/cipher/sha1.c
index 3bb24c7e..cb50ef66 100644
--- a/cipher/sha1.c
+++ b/cipher/sha1.c
@@ -759,7 +759,7 @@ static gcry_md_oid_spec_t oid_spec_sha1[] =

I created T5665: libgcrypt : Restrict message digest use for FIPS 140-3.

Let me move this ticket as DONE (now Testing status), as the subject was solved (MD5 and soft/forced/inactive things).

In T5433#151041, @gniibe wrote:

Sorry, I was wrong. We don't need any changes.

When using gcry_pk_hash_sign and gcry_pk_hash_verify, approved digest algos are guaranteed when FIPS enabled.

Yes, it's a user of the function who supplies HD (handle for hash). (I had wrong assumption HD could be with non-approved digest algo.) But it is needed for the user to enable the HD and to feed message beforehand. At that stage, non-approved digest algo must fail.

I investigated if the possible change above (if applied) constitutes an ABI change: Indeed, it will be an ABI change, and an API change; code should be modified and build.

Sorry, I was wrong. We don't need any changes.

I am going to implement rejecting SHA-1 through new API (hash+sign, hash+verify).

( No need to certify the DSA things)

It seems for me that the patches to random/ was written in old days.

• Now, we have getentropy in libc
  • This is most reliable one
  • better than urandom, because it may block when kernel is not yet seeded
  • better than random, because it never blocks once kernel is seeded
• So, the real path in rndlinux.c is actually, call to getentropy
• No access to /dev/random or /dev/urandom any more, in fact
• Although old code remains, non-touched
  • like use of syscall when getentropy function is not available

Add doc in gcrypt.texi.

Thank you. Applied.

In T5617#150908, @gniibe wrote:

OK, let us start discussion by applying the patch first.

I have wondered if introducing another state in FSM would be needed, because:

OK, let us start discussion by applying the patch first.

Applied the RSA part.

Now configure with
--enable-hmac-binary-check="I know engineers. They love to change things." works.

I push a change: rC070935965763: build: Use KEY_FOR_BINARY_CHECK for --enable-hmac-binary-check..

sorry for a confusion. We do not plan to certify DSA so disregard the second part of the patch.

Do we really need to support DSA in FIPS mode? I mean standard DSA and not ECDSA.

Pushed the change: rC082ea0efa9b1: cipher: Add sign+hash, verify+hash, and random-override API.

How about:

• Only when hash-handle is used for multiple purposes, a user needs to compose SEXP
• when hash-handle is used for a single purpose, a user doesn't need to compose SEXP, but static one.

In the original SuSE's patch, _gcry_pk_sign_md function gets data template as SEXP as an argument, and the implementation does decomposing SEXP to get hash-algo. (A user of the function needs to compose SEXP with hash-algo.)

These are great news. Thank you!

Pushed the change to libgpg-error and libgcrypt (1.9 and master).
Let us see if there are any problem(s) for that, I will apply it to other libraries when it will be found no problem.

Thank you for the information.
For the record, I put the link to the email submitted:
https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html

Thanks. This looks good to me.

Thank you for pointing out. Since hmac256.{c,h} can be used by others, I think that it is better to keep those two files, instead of merging it into one.

Oh, you are right, it's not upstream. It's actually applied to Homebrew (https://brew.sh/) libtool formula which is where I originally got libtool.m4, see:

I tried to generate a tarball from master and I failed to build the hmac256 binary because the hmac256.h was not packaged into the dist tarball in master. If hmac256 should be standalone binary, I propose it should not need have a separate header file:

I see your point. I'd like to locate/identify where the change comes from.
I think that what you refer by "new libtool.m4" is actually macOS local change (I mean, not from libtool upstream, AFAIK).
Could you please point out the source of the change?

That would work, however we might hit this issue with a new macOS release. Would it make more sense to update to what the new libtool.m4 is doing? Linker flags are the same, it only changes the way they detect macOS versions:

Tsss, requires to allow JS for Google.

Just FYI, see also how GnuTLS has proposed to implement the service indicator:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1465

That does indeed not look like something which could introduce a regression.

I misunderstood as if we need to update libtool from upstream.

macOS has low priority for us and I do not want to risk any regression.

About merging our local changes.

We have our own changes for ltmain.sh and libtool.m4.

And update from automake 1.16:

It's better to update the set of files from libtool:

build-aux/ltmain.sh
m4/libtool.m4
m4/ltoptions.m4
m4/ltsugar.m4
m4/ltversion.m4
m4/lt~obsolete.m4