From gniibe at fsij.org Tue Mar 4 03:48:15 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 04 Mar 2025 11:48:15 +0900 Subject: T7338: Make SHA1 non-FIPS and differentiate in the SLI In-Reply-To: References: <8734gjfu2k.fsf@jacob.g10code.de> <875xldeqz4.fsf@jacob.g10code.de> <87ikpdqt7h.fsf@haruna.fsij.org> <87cyfeznz5.fsf@haruna.fsij.org> <87msehks8y.fsf@haruna.fsij.org> <877c5jyi0c.fsf@haruna.fsij.org> <87jz9eh3fm.fsf@haruna.fsij.org> <871pvl2s94.fsf@haruna.fsij.org> <87wmdd1d36.fsf@haruna.fsij.org> Message-ID: <87o6yheck0.fsf@haruna.fsij.org> "Lucas Mulling" wrote: > Sorry for the delay, I've tested the patches everything seems to be in order. Thank you for your testing. I'm going to push the changes so far. > The only thing I had to change was: > > diff --git a/tests/basic.c b/tests/basic.c > index f32e41db..5e1f94b5 100644 > --- a/tests/basic.c > +++ b/tests/basic.c > @@ -17268,8 +17268,9 @@ check_pubkey_sign (int n, gcry_sexp_t skey, gcry_sexp_t pkey, int algo, > rc = gcry_pk_sign (&sig, hash, skey); > if (in_fips_mode && (flags & FLAG_NOFIPS || datas[dataidx].flags & FLAG_NOFIPS)) > { > - if (!rc) > - fail ("gcry_pk_sign did not fail as expected in FIPS mode\n"); > + if ((datas[dataidx].expected_rc && !rc)) > + fail ("gcry_pk_sign (%d) did not fail as expected in FIPS mode\n", > + dataidx); > goto next; > } > if (gcry_err_code (rc) != datas[dataidx].expected_rc) I see the point. But, let me defer changing test program(s) in 1.11. Newer FIPS conscious applications with the indicator, it won't use rejection, but will check the indicator. For this new use case, current test programs in tests/ are somewhat irrelevant and need to be updated. Yes, you are right that tests/basic.c is one of those test programs. Others are: keygen, t-kem, dsa-rfc6979, curves, t-cv25519, and t-x448. Those programs assumes that it rejects computation under FIPS mode. For 1.10 compatibility, GCRY_FIPS_FLAG_REJECT_PK is enabled by default and GCRY_FIPS_FLAG_REJECT_PK_MD is not enabled by default. GCRY_FIPS_FLAG_REJECT_PK is the flag rejecting non-compliant use cases in public key operations. GCRY_FIPS_FLAG_REJECT_PK_MD is the flag rejecting non-compliant use cases with regards to public key operation using message digest SHA1, specifically, for gcry_pk_sign/gcry_pk_verify functions. Please note that in 1.10, gcry_pk_sign/gcry_pk_verify functions were not covered as intended functions to be used in FIPS conscious applications, so, not rejecting public key operation using SHA1 were OK. For gcry_pk_hash_sign/gcry_pk_hash_verify functions, which are covered as intended functions to be used in FIPS conscious applications, public key operation using message digest SHA1 are rejected when either GCRY_FIPS_FLAG_REJECT_PK is enabled or GCRY_FIPS_FLAG_REJECT_PK_MD is enabled. -- From gniibe at fsij.org Tue Mar 4 03:49:46 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 04 Mar 2025 11:49:46 +0900 Subject: T7338: Make SHA1 non-FIPS and differentiate in the SLI In-Reply-To: References: <8734gjfu2k.fsf@jacob.g10code.de> <875xldeqz4.fsf@jacob.g10code.de> <87ikpdqt7h.fsf@haruna.fsij.org> <87cyfeznz5.fsf@haruna.fsij.org> <87msehks8y.fsf@haruna.fsij.org> <877c5jyi0c.fsf@haruna.fsij.org> <87jz9eh3fm.fsf@haruna.fsij.org> <871pvl2s94.fsf@haruna.fsij.org> <87wmdd1d36.fsf@haruna.fsij.org> Message-ID: <87ldtlechh.fsf@haruna.fsij.org> Hello, I have one more fix. I'm going to push this. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-fips-cipher-Do-the-computation-when-marking-non-comp.patch Type: text/x-diff Size: 4973 bytes Desc: not available URL: From gniibe at fsij.org Tue Mar 4 05:56:10 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 04 Mar 2025 13:56:10 +0900 Subject: [PATCH 0/2] KAT for non-deterministic ECDSA and differentiate K In-Reply-To: <20250226153056.156673-1-lucas.mulling@suse.com> References: <20250226153056.156673-1-lucas.mulling@suse.com> Message-ID: <87ikope6mt.fsf@haruna.fsij.org> Lucas Mulling wrote: > Currently, the KAT for ECDSA only tests for deterministic ECDSA with > rfc6979 flag. For FIPS, a test for non-deterministic ECDSA is also > required, this is achieved by setting the k with label. > > Also, in FIPS mode, label is not allowed and needs to be differentiate. Thank you. Applied and pushed. -- From gniibe at fsij.org Wed Mar 5 06:41:12 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 05 Mar 2025 14:41:12 +0900 Subject: [PATCH 0/4] Differentiate use of non-compliant flags in the SLI In-Reply-To: <20250226202131.381279-1-lucas.mulling@suse.com> References: <20250226202131.381279-1-lucas.mulling@suse.com> Message-ID: <87y0xk11c7.fsf@haruna.fsij.org> Lucas Mulling wrote: > FIPS requires that the following flags be differentiated in the SLI: > * igninvflag; > * no-blinding; > * random-override. > > Lucas Mulling (4): > cipher: Differentiate igninvflag in the SLI > cipher: Differentiate no-blinding flag in the SLI > cipher,visibility: Differentiate use of random-override in the SLI > tests: Fix tests to account for differentiated flags Let me apply and push the first two patches firstly. I'll push these two. For the third, it changes the behavior of gcry_pk_random_override_new (adding rejection) to require major changes in tests (of the fourth). I wonder if this is appropriate in 1.11. Let me consider for this. -- From gniibe at fsij.org Thu Mar 6 02:20:58 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 06 Mar 2025 10:20:58 +0900 Subject: [PATCH 0/4] Differentiate use of non-compliant flags in the SLI In-Reply-To: <87y0xk11c7.fsf@haruna.fsij.org> References: <20250226202131.381279-1-lucas.mulling@suse.com> <87y0xk11c7.fsf@haruna.fsij.org> Message-ID: <874j07hs3p.fsf@haruna.fsij.org> NIIBE Yutaka wrote: > Let me apply and push the first two patches firstly. I'll push these > two. Done. > For the third, it changes the behavior of gcry_pk_random_override_new > (adding rejection) to require major changes in tests (of the fourth). I > wonder if this is appropriate in 1.11. Let me consider for this. I would like to apply the patch attached to introduce GCRY_FIPS_FLAG_REJECT_PK_FLAGS. The intention is keeping the behavior of 1.10, so that forthcoming 1.11.1 release won't break things with existing applications. Then, let me apply yours of: [PATCH 3/4] cipher, visibility: Differentiate use of random-override in the SLI After that, let me fix it with GCRY_FIPS_FLAG_REJECT_PK_FLAGS, so that your fourth patch is not needed for 1.11. The idea here is that: * For existing FIPS conscious applications with libgcrypt, it assumes old API of static indicator; That is, use of GCRYCTL_FIPS_SERVICE_INDICATOR_CIPHER, GCRYCTL_FIPS_SERVICE_INDICATOR_MAC, GCRYCTL_FIPS_SERVICE_INDICATOR_MD, GCRYCTL_FIPS_SERVICE_INDICATOR_KDF, GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION, and GCRYCTL_FIPS_SERVICE_INDICATOR_PK_FLAGS. It has the behaviors of rejecting non-compliant use in some places in supported functions, but not for other places. It is OK with old API, non-supported functions don't reject (like MD5 can be used). * For new FIPS conscious applications, there are new API to check the indicator. We are now introducing new API for 1.12, and forward-compatible implementation in 1.11. * Existing tests in tests/ are basically with old API (except t-fips-service-ind). Update will be done in master for 1.12 after 1.11 branch will be created. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fips-cipher-Add-GCRY_FIPS_FLAG_REJECT_PK_FLAGS.patch Type: text/x-diff Size: 2672 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 6 02:27:17 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 06 Mar 2025 10:27:17 +0900 Subject: [PATCH 0/4] Differentiate use of non-compliant flags in the SLI In-Reply-To: <874j07hs3p.fsf@haruna.fsij.org> References: <20250226202131.381279-1-lucas.mulling@suse.com> <87y0xk11c7.fsf@haruna.fsij.org> <874j07hs3p.fsf@haruna.fsij.org> Message-ID: <871pvbhrt6.fsf@haruna.fsij.org> NIIBE Yutaka wrote: > I would like to apply the patch attached to introduce > GCRY_FIPS_FLAG_REJECT_PK_FLAGS. The intention is keeping the behavior > of 1.10, so that forthcoming 1.11.1 release won't break things with > existing applications. Also, I'm going apply this minor fix. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-cipher-ecc-Fix-for-supplied-K.patch Type: text/x-diff Size: 2554 bytes Desc: not available URL: From lucas.mulling at suse.com Thu Mar 6 19:37:14 2025 From: lucas.mulling at suse.com (Lucas Mulling) Date: Thu, 06 Mar 2025 15:37:14 -0300 Subject: [PATCH 0/4] Differentiate use of non-compliant flags in the SLI In-Reply-To: <874j07hs3p.fsf@haruna.fsij.org> References: <20250226202131.381279-1-lucas.mulling@suse.com> <87y0xk11c7.fsf@haruna.fsij.org> <874j07hs3p.fsf@haruna.fsij.org> Message-ID: On Wed Mar 5, 2025 at 10:20 PM -03, NIIBE Yutaka wrote: > The idea here is that: > > * For existing FIPS conscious applications with libgcrypt, it assumes > old API of static indicator; That is, use of > GCRYCTL_FIPS_SERVICE_INDICATOR_CIPHER, > GCRYCTL_FIPS_SERVICE_INDICATOR_MAC, > GCRYCTL_FIPS_SERVICE_INDICATOR_MD, > GCRYCTL_FIPS_SERVICE_INDICATOR_KDF, > GCRYCTL_FIPS_SERVICE_INDICATOR_FUNCTION, and > GCRYCTL_FIPS_SERVICE_INDICATOR_PK_FLAGS. It has the behaviors of > rejecting non-compliant use in some places in supported functions, > but not for other places. It is OK with old API, non-supported > functions don't reject (like MD5 can be used). > > * For new FIPS conscious applications, there are new API to check the > indicator. We are now introducing new API for 1.12, and > forward-compatible implementation in 1.11. > > * Existing tests in tests/ are basically with old API (except > t-fips-service-ind). Update will be done in master for 1.12 after > 1.11 branch will be created. Agreed, this makes sense, thanks for the fixes! From gniibe at fsij.org Tue Mar 11 06:30:05 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 11 Mar 2025 14:30:05 +0900 Subject: T7338: Make SHA1 non-FIPS and differentiate in the SLI In-Reply-To: <87ldtlechh.fsf@haruna.fsij.org> References: <8734gjfu2k.fsf@jacob.g10code.de> <875xldeqz4.fsf@jacob.g10code.de> <87ikpdqt7h.fsf@haruna.fsij.org> <87cyfeznz5.fsf@haruna.fsij.org> <87msehks8y.fsf@haruna.fsij.org> <877c5jyi0c.fsf@haruna.fsij.org> <87jz9eh3fm.fsf@haruna.fsij.org> <871pvl2s94.fsf@haruna.fsij.org> <87wmdd1d36.fsf@haruna.fsij.org> <87ldtlechh.fsf@haruna.fsij.org> Message-ID: <87r034jfs2.fsf@haruna.fsij.org> Hello, I was wrong about SHA1. I had thought that I were able to defer the change. Actually, we need to apply this patch (attached), to support 1.12 (the new service indicator) forward compatibility in 1.11.1. Well, the implementation in 1.11 is a bit confusing, it allows use of SHA1 (it is an approved hash function in the static indicator, and no rejection for its use), no behavior changes for existing applications, but it is _internally_ marked non-FIPS. This is (hopefully) the last change for T7338. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-md-Make-SHA-1-non-FIPS-internally-for-1.12-API.patch Type: text/x-diff Size: 6585 bytes Desc: not available URL: From gniibe at fsij.org Fri Mar 14 07:08:21 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 14 Mar 2025 15:08:21 +0900 Subject: LIBGCRYPT-1.11-BRANCH Message-ID: <87ecz04016.fsf@haruna.fsij.org> Hello, For releasing 1.11.1, I asked Werner to create the LIBGCRYPT-1.11-BRANCH. And, in this branch, I merged commits from master. Please test LIBGCRYPT-1.11-BRANCH and let us know if you see any problems. --