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. -- From wahern at akamai.com Sun Mar 16 10:29:39 2025 From: wahern at akamai.com (Ahern, William) Date: Sun, 16 Mar 2025 09:29:39 +0000 Subject: FIPS-mode keygen fails to include preferences subpackets Message-ID: <2B1B87BF-B78F-4205-8ACF-8B54B8AE7317@akamai.com> When libgcrypt is in FIPS mode GnuPG g10/keygen.c:keygen_set_std_prefs fails entirely in the absence of an explicit preference list, resulting in the symmetric cipher preference list and similar subpackets being omitted from the generated public key. It also effects the features subpacket. Additionally, for senders using releases before GPG 2.3.x this has the effect of causing GnuPG (in FIPS mode) to fail encryption as it defaults to 3DES in the absence of a public key preference list, regardless of runtime support. The root cause is that 1) "S2" (i.e. 3DES) is unconditionally added to the default generated preference string causing 2) keygen_set_std_prefs to fail. keygen_set_stdprefs bails out entirely when any preference algorithm cannot be decoded using string_to_cipher_algo, even when all but one were successfully decoded. A simple fix is to use "3DES" instead of "S2" when generating the default preference list string (see top of keygen_set_std_prefs). That works because string_to_cipher_algo succeeds for "3DES" but not "S2", even in FIPS mode. The former takes a path through libgcrypt that simply maps the name to an identifier using the built-in algorithm table, whereas for "S2" a separate pathway is taken that actually queries runtime support, which will fail in FIPS mode. Locally we're using the simple fix, but a better solution might be to 1) add "S2" conditionally, similar to how AES is treated, and 2) refactor the second half of keygen_set_std_prefs to continue processing algorithms, only failing later if none were matched in a set. I'd be happy to craft that patch if that seems like the better solution. Regards, - Bill From lucas.mulling at suse.com Mon Mar 17 17:19:41 2025 From: lucas.mulling at suse.com (Lucas Mulling) Date: Mon, 17 Mar 2025 13:19:41 -0300 Subject: LIBGCRYPT-1.11-BRANCH In-Reply-To: <87ecz04016.fsf@haruna.fsij.org> References: <87ecz04016.fsf@haruna.fsij.org> Message-ID: Hi, This there any expected date for the release? From gniibe at fsij.org Tue Mar 18 06:26:06 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 18 Mar 2025 14:26:06 +0900 Subject: FIPS-mode keygen fails to include preferences subpackets In-Reply-To: <2B1B87BF-B78F-4205-8ACF-8B54B8AE7317@akamai.com> References: <2B1B87BF-B78F-4205-8ACF-8B54B8AE7317@akamai.com> Message-ID: <87jz8mucy9.fsf@haruna.fsij.org> Hello, Ahern, William wrote: > When libgcrypt is in FIPS mode GnuPG g10/keygen.c:keygen_set_std_prefs > fails entirely in the absence of an explicit preference list, > resulting in the symmetric cipher preference list and similar > subpackets being omitted from the generated public key. Well, I'd suggest posting this question to gnupg-devel. This is not a problem of libgcrypt. In my opinion... this use case is not (yet) supported by GnuPG. With libgcrypt API of 1.12, a program can use the libgcrypt under FIPS mode in non-rejecting way, so that crypt computations can be done in non-approved ways. Possibly, GnuPG could be run using this feature. Or, we need to modify GnuPG so that it can run under FIPS mode. -- From wk at gnupg.org Tue Mar 18 15:45:22 2025 From: wk at gnupg.org (Werner Koch) Date: Tue, 18 Mar 2025 15:45:22 +0100 Subject: LIBGCRYPT-1.11-BRANCH In-Reply-To: (Lucas Mulling via Gcrypt-devel's message of "Mon, 17 Mar 2025 13:19:41 -0300") References: <87ecz04016.fsf@haruna.fsij.org> Message-ID: <87ldt2bdod.fsf@jacob.g10code.de> Hi! On Mon, 17 Mar 2025 13:19, Lucas Mulling said: > This there any expected date for the release? We should wait a couple of days to see whether bugs are reported ... and use this time to write the NEWS. This month I'd say. Salam-Shalom, Werner -- The pioneers of a warless world are the youth that refuse military service. - A. Einstein -------------- next part -------------- A non-text attachment was scrubbed... Name: openpgp-digital-signature.asc Type: application/pgp-signature Size: 247 bytes Desc: not available URL: From ametzler at bebt.de Tue Mar 18 19:41:04 2025 From: ametzler at bebt.de (Andreas Metzler) Date: Tue, 18 Mar 2025 19:41:04 +0100 Subject: LIBGCRYPT-1.11-BRANCH In-Reply-To: <87ecz04016.fsf@haruna.fsij.org> References: <87ecz04016.fsf@haruna.fsij.org> Message-ID: On 2025-03-14 NIIBE Yutaka via Gcrypt-devel wrote: > 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. Hello, I had uploaded it to Debian/experimental to doublecheck buildability without finding new issues in release architectures https://buildd.debian.org/status/package.php?p=libgcrypt20&suite=experimental it also did not triggger CI errors of depending packages, but that is a little bit spotty for Debian/experimental. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' From lucas.mulling at suse.com Tue Mar 25 20:15:17 2025 From: lucas.mulling at suse.com (Lucas Mulling) Date: Tue, 25 Mar 2025 16:15:17 -0300 Subject: LIBGCRYPT-1.11-BRANCH In-Reply-To: <87ldt2bdod.fsf@jacob.g10code.de> References: <87ecz04016.fsf@haruna.fsij.org> <87ldt2bdod.fsf@jacob.g10code.de> Message-ID: Hello, On Tue Mar 18, 2025 at 11:45 AM -03, Werner Koch wrote: > On Mon, 17 Mar 2025 13:19, Lucas Mulling said: > >> This there any expected date for the release? > > We should wait a couple of days to see whether bugs are reported > ... and use this time to write the NEWS. > > This month I'd say. Thanks! I've tested the branch against our openSUSE:Factory and all packages that depend on libgcrypt in some way have built successfully.