I have been convinced disabling DSA makes more sense.

Done.
(Actually, it's not in the tarball.)

Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).

We have tests in gniibe/new-pk-api, which can be backported.

• t-dsa
• t-ecdsa
• t-rsa-pss
• t-rsa-15

Thank you, applied.

The patch has been applied.

Thanks jukivili for the review.

I have just a note about this issue, that it would be helpful to exercise this new API in some tests. Right now, only the old API is tested.

It turns out that the asymmetric key operations are not yet properly enforced with the .disabled flag. While the other key crypto usually has some "open" api, where this can be simply captured, the pubkey API has several entry points and the "test_algo" is not enough to check for disabled key types.

Yeah, remove it.

Thank you. My local tests (in emulated fips mode and normal mode) do not show any errors with current master branch.

And please let me know the change rC751fcadd34ed: random: Release memory in DRBG. affects t-secmem failure.

IIUC, one of the causes for the failure of secmem was resource release of DRBG memory.

Thank you for testing.

Applied. Thank you.

Thanks, however I didn't see your email on mailing-list. Maybe the email got stuck on the way.

Thanks. I did some git archeology and found the first mention of this in the following commit in 2011 without much details:

Adding the case for == 0 only might be problematic, because I don't think it's an alias for a secure value; I think that == 0 means that it's up to libgcrypt to select the value (just like other generate_* functions).

Thank you, applied.

I sent a copy to gcrypt-devel@gnupg.org. Hope this is the right process. Thanks.

Please read doc/HACKING carefully on the process of sending DCO the right way.

Let me get back to this once more as one of the parts for RSA was initially missed:

diff -up libgcrypt-1.8.4/cipher/rsa.c.fips-keygen libgcrypt-1.8.4/cipher/rsa.c
--- libgcrypt-1.8.4/cipher/rsa.c.fips-keygen	2017-11-23 19:16:58.000000000 +0100
+++ libgcrypt-1.8.4/cipher/rsa.c	2019-02-12 14:29:25.630513971 +0100
@@ -696,7 +696,7 @@ generate_x931 (RSA_secret_key *sk, unsig

I went through some more testing and noticed one missing file in the release tarball, that prevents building libgcrypt now. Should be fixed with the attached patch.

I did go through a bit more testing too and the selftests still initialize and use the secure memory (and the t-secmem fails in FIPS mode if we invoke selftests from constructor). Now from run_random_selftests() -> _gcry_random_selftest() -> drbg_healthcheck() -> _gcry_rngdrbg_healthcheck_one(). So this means that we either need to de-initialize secure memory after the constructor selftests or prevent its initialization as I suggested in some of the previous comments.

For the part 1, I created: T5710: FIPS: disable DSA for FIPS

This is the patch from @Jakuje

Also, applied the part 2, improving basic.c.

Applied the part 3, the 3DES is no-FIPS patch.

Applied the part 4, the indicator patch.

The change for pubkey-util.c is not needed any more, because

• T5665 handles new functions rejects use of SHA-1 as approved signature.
• pubkey-util.c is used by gcry_pk_sign and gcry_pk_verify.

I do not like the idea of using the get_config interface for this. It should be easily usable by applications to check for single cipher/mode so int/bool return values would be preferred against the string ones (which are now used in the get_config). I am not sure if getting all the configuration in one string blob would be any use (except for some auditing) either.

Hi Werner, Here is the DCO. Thanks.

Thank you. Extending the semantics of GCRYCTL_CLOSE_RANDOM_DEVICE sounds good to me. I think the deinit functions were created initially especially not to change the semantics of existing code using GCRYCTL_CLOSE_RANDOM_DEVICE, but I agree that it will probably not be an issue.

FWIW: We need a DCO; see doc/HACKING.

Part 1 was applied. Part 3, Part 4, and Part 7 are irrelevant now, because we now have rndgetentropy which doesn't use device.

Following patch should prevent assembly files being built at all with --disable-asm:

Thanks for your report.

Fixed, with using normal memory for ->mem.

->mem is just used to measure the difference of memory access.

It found that newer jitterentropy uses larger mem (128KiB), while older uses 2KiB.

Pushed to master.

Additionally, poly1305-s390x.S is being compiled despite running/targeting a PC system:

We could use a new mode #define GCRY_GET_CONFIG_FIPS 1 with gcry_get_config:

With just implicit indicators, we would have to block all non-approved cipher modes and kdfs including the OCB mode and skcrypt, which would probably make gnupg2 unusable in FIPS mode, which is not our intention.

In the documentation, I found:

Also, and I should maybe have opened with it, the issues vcpkg has with your build system are currently tracked here, while my effort to build gpg-error natively (i.e. without relying on ShiftMediaProject fork) on all platforms is here.

In T5365#151844, @gniibe wrote:

Let me clarify the use case of gpg-error.m4.

gpg-error.m4 is for GnuPG and its friends, where we cannot assume availability of pkg-config. Its capability is limited, and we don't pursue 100% compatibility of pkg-config.

Let me clarify the use case of gpg-error.m4.

In T5365#144688, @gniibe wrote:

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

I just wanted to add one more note that i just found out that the tests --disable-hwf or gcry_control GCRYCTL_DISABLE_HWF have no effect in case the global_init() is called from constructor.

Also applied to gpgme.

Since there is no problem with libgpg-error 1.43, I applied it to other libraries: npth, libassuan, libksba, and ntbtls.

I'll fix regressions: failures of pubkey and pkcs1v2.

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.