Few comments on new patch:

Hi jukivili,

The first is a warning and the other error codes are exactly what we want.

Thank you, applied.

It turned out that the new *.inp files are not part of the release tarball, which makes the tests from generated tarball fail. The attached patch should fix this issue.

Thank you, applied.

Sorry for the noise. There were couple of other places which I missed initially and which are covered in the v2 patch which follows:

It turns out together with rCe96980022e5e some tests are failing in FIPS mode. The attached patch should handle the failures.

Reading compressed point format has been done.
If writing support is needed, please open another task.

This new API is not for FIPS directly (any more), as we introduced pk_hash_sign/verify for FIPS.

Pushed the backport.

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.