libgcrypt: Do not use SHA1 by default
Closed, WontfixPublic
Actions

Assigned To

Authored By

	Jakuje
	May 11 2021, 1:58 PM

Description

There is one place, where libgcrypt is using SHA-1 by default. It is already gated by fips_mode() check, but I think it would make sense to move away from SHA-1 by default generally.

cipher/pubkey-util.c: _gcry_pk_util_init_encoding_ctx -- sets default ctx->hash_algo to GCRY_MD_SHA1 unless in FIPS mode

It might be that the default is overridden in all the uses of this function (did not check that), but the following patch seems to work fine for me and tests keep passing for me locally:

diff --git a/cipher/pubkey-util.c b/cipher/pubkey-util.c
index b41135e6..7229b76a 100644
--- a/cipher/pubkey-util.c
+++ b/cipher/pubkey-util.c
@@ -629,14 +629,7 @@ _gcry_pk_util_init_encoding_ctx (struct pk_encoding_ctx *ctx,
   ctx->nbits = nbits;
   ctx->encoding = PUBKEY_ENC_UNKNOWN;
   ctx->flags = 0;
-  if (fips_mode ())
-    {
-      ctx->hash_algo = GCRY_MD_SHA256;
-    }
-  else
-    {
-      ctx->hash_algo = GCRY_MD_SHA1;
-    }
+  ctx->hash_algo = GCRY_MD_SHA256;
   ctx->label = NULL;
   ctx->labellen = 0;
   ctx->saltlen = 20;

Related Objects

Mentioned Here: T5665: libgcrypt : Restrict message digest use for FIPS 140-3
rCa242e3d9185e: ecc: ECDSA adjustments for FIPS 186-4

Event Timeline

Jakuje created this task.May 11 2021, 1:58 PM

Jakuje renamed this task from Do not use SHA1 by default to libgcrypt: Do not use SHA1 by default.May 24 2021, 4:38 PM

That patch consists an ABI change. We might consider this for 1.10 but we can't do such a change in 1.9.

• gniibe moved this task from Backlog to For 1.10 on the libgcrypt board.Jul 6 2021, 6:33 AM

With the planned new context aware pubkey functions we technically could do this change w/o an ABI break.

• werner triaged this task as Normal priority.Aug 1 2021, 10:57 AM

• werner added a project: FIPS.

• werner moved this task from Backlog to Next on the FIPS board.Oct 4 2021, 11:28 AM

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

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.

The line and feature ("hash-algo") was introduced for RSA PSS and RSA OAEP.

rCa242e3d9185e: ecc: ECDSA adjustments for FIPS 186-4 modified the default for FIPS enabled case. But I'm not sure if it was deliberate change, because the change was for ECDSA, which doesn't use this code at all.

RSA PSS and RSA OAEP defaults to SHA1, so, existing code may depend on the default.

Please note that when using gcry_pk_hash_sign and gcry_pk_hash_verify, this default value is overridden always, so, there is no case non-approved digest algo will be used.

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.

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 and it needs to be handled in this new function.

Additionally, we might need to be able to verify some old signatures using the new API under the "Legacy use".

For more information, see the section 9 of NIST SP 800-131Ar2

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf

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

Right. I claimed that this were satisfied, because (when FIPS enabled) there is no way for users to use the new functions with non-approved digest algo. New functions require open+enable hash handle beforehand, at that time, only approved digest algo can be used (when FIPS enabled).

But... again I was wrong.

I overlooked .fips = 1 for SHA-1 (in current code).

My claim above is only true when .fips = 0 for SHA-1.

I opened T5665 for this particular issue of SHA-1 is non-approved digest algo (for signature computation).

For this ticket, please focus on about the default use of SHA-1 in pubkey-util.c.

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.

So, I mark this ticket as wontfix.

libgcrypt: Do not use SHA1 by defaultClosed, WontfixPublicActions

Description

Related Objects

Event Timeline

libgcrypt: Do not use SHA1 by default
Closed, WontfixPublic
Actions