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. From gniibe at fsij.org Thu Mar 27 01:06:36 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 09:06:36 +0900 Subject: Less Leaky ECDSA signature generation (in master) Message-ID: <87iknvibg3.fsf@haruna.fsij.org> Hello, I'm working on the task of constant-time (EC)DSA signature generation: https://dev.gnupg.org/T7519 IIUC, possible important signal sources have been fixed for (EC)DSA (for both branchs of 1.11 and master). And I continue on ECC improvement in master. For the first improvement, I realized that runtime checks in ec_mod and its friends could be leaky, because it depends on how small/big the value is. Since it is (or can be) precondition for those routines in the code of libgcrypt, it can be removed. Since it could be leaky, it's good to be removed. Here is a change. -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-mpi-ec-Remove-runtime-check-in-ec_mod.patch Type: text/x-diff Size: 4086 bytes Desc: not available URL: From jcb62281 at gmail.com Thu Mar 27 03:05:28 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Wed, 26 Mar 2025 21:05:28 -0500 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <87iknvibg3.fsf@haruna.fsij.org> References: <87iknvibg3.fsf@haruna.fsij.org> Message-ID: <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> On 3/26/25 19:06, NIIBE Yutaka via Gcrypt-devel wrote: > [...] For the first improvement, > I realized that runtime checks in ec_mod and its friends could be leaky, > because it depends on how small/big the value is. Could these checks instead be improved to run in constant time? > Since it is (or can be) precondition for those routines in the code of > libgcrypt, it can be removed. Since it could be leaky, it's good to be > removed. Hypothetically, if those preconditions are violated, what could go wrong?? How badly does the math fall apart?? Could an invalid result potentially (partially) expose the signing key? Removing runtime checks in this type of code makes me nervous. Maybe it is just paranoia. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From gniibe at fsij.org Thu Mar 27 06:19:03 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:03 +0900 Subject: [PATCH 0/8] More on: Less Leaky ECDSA signature generation (in master) Message-ID: Hello, Here are my changes for https://dev.gnupg.org/T7519 (after applying 0001-mpi-ec-Remove-runtime-check-in-ec_mod.patch) Because libgcrypt exposes lower level API like gcry_mpi_ec_add, gcry_mpi_ec_dup, and gcry_mpi_ec_mul, we need to be conservative to keep exposed behaviors. I introduce new internal flag of GCRYECC_FLAG_LEAST_LEAK to select less-leaky ec_* routines for constant-time computation. NIIBE Yutaka (8): mpi:ec: Use ec_addm for ec_mul2. mpi:ec: Keep A untouched in ec_get_a_is_pminus3. mpi:ec: Refactor _gcry_mpi_ec_mul_point cipher:ecc: Introduce GCRYECC_FLAG_LEAST_LEAK. mpi:ec: Resize when GCRYECC_FLAG_LEAST_LEAK. mpi:ec: Use affine coordinate for mpi_ec_mul_point_lli. mpi:ec: Don't normalize the MPIs when GCRYECC_FLAG_LEAST_LEAK. mpi:ec: Introduce ec_*_lli for Weierstrass curves to be less leaky. cipher/ecc.c | 8 +- mpi/ec-nist.c | 16 +- mpi/ec.c | 739 ++++++++++++++++++++++++++++++++++++++------------ src/cipher.h | 5 + 4 files changed, 582 insertions(+), 186 deletions(-) -- 2.47.2 From gniibe at fsij.org Thu Mar 27 06:19:04 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:04 +0900 Subject: [PATCH 1/8] mpi:ec: Use ec_addm for ec_mul2. In-Reply-To: References: Message-ID: <38cdb7fecc80c7f834bdd4fdc77e37f73ca8149f.1743052412.git.gniibe@fsij.org> * mpi/ec.c (ec_mul2): Use ec_addm. Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-mpi-ec-Use-ec_addm-for-ec_mul2.patch Type: text/x-patch Size: 340 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:06 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:06 +0900 Subject: [PATCH 3/8] mpi:ec: Refactor _gcry_mpi_ec_mul_point In-Reply-To: References: Message-ID: <5e3dbfb8233d5849e5031c527aefed1ff460089c.1743052412.git.gniibe@fsij.org> * mpi/ec.c (montgomery_mul_point, mpi_ec_mul_point_lli): Factor out from _gcry_mpi_ec_mul_point. (_gcry_mpi_ec_mul_point): Use montgomery_mul_point and mpi_ec_mul_point_lli. Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 331 +++++++++++++++++++++++++++++-------------------------- 1 file changed, 175 insertions(+), 156 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-mpi-ec-Refactor-_gcry_mpi_ec_mul_point.patch Type: text/x-patch Size: 10488 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:05 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:05 +0900 Subject: [PATCH 2/8] mpi:ec: Keep A untouched in ec_get_a_is_pminus3. In-Reply-To: References: Message-ID: * mpi/ec.c (ec_get_a_is_pminus3): Change the calculation so that it keeps the MPI of A untouched. -- Note that mpi_cmp with A may normalize the MPI. Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-mpi-ec-Keep-A-untouched-in-ec_get_a_is_pminus3.patch Type: text/x-patch Size: 434 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:07 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:07 +0900 Subject: [PATCH 4/8] cipher:ecc: Introduce GCRYECC_FLAG_LEAST_LEAK. In-Reply-To: References: Message-ID: <6419bd17f034bb7dad17bbd6c1f90c4c28cc4348.1743052412.git.gniibe@fsij.org> * src/cipher.h (GCRYECC_FLAG_LEAST_LEAK): New. * cipher/ecc.c (ecc_generate): Use GCRYECC_FLAG_LEAST_LEAK. (ecc_check_secret_key, ecc_sign, ecc_decrypt_raw): Likewise. -- GnuPG-bug-id: 7519 Signed-off-by: NIIBE Yutaka --- cipher/ecc.c | 8 ++++---- src/cipher.h | 5 +++++ 2 files changed, 9 insertions(+), 4 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-cipher-ecc-Introduce-GCRYECC_FLAG_LEAST_LEAK.patch Type: text/x-patch Size: 1709 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:09 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:09 +0900 Subject: [PATCH 6/8] mpi:ec: Use affine coordinate for mpi_ec_mul_point_lli. In-Reply-To: References: Message-ID: * mpi/ec.c (add_points_weierstrass_a, add_points_edwards_a): New. (mpi_ec_mul_point_lli): Use those routines directly. -- GnuPG-bug-id: 7519 Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 247 ++++++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 237 insertions(+), 10 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-mpi-ec-Use-affine-coordinate-for-mpi_ec_mul_point_ll.patch Type: text/x-patch Size: 8263 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:08 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:08 +0900 Subject: [PATCH 5/8] mpi:ec: Resize when GCRYECC_FLAG_LEAST_LEAK. In-Reply-To: References: Message-ID: <794b8e7378e84c344a0629af61b1154f8830aca4.1743052412.git.gniibe@fsij.org> * mpi/ec.c (ec_p_init): Also resize when GCRYECC_FLAG_LEAST_LEAK. Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 33 ++++++++++++++++++--------------- src/cipher.h | 2 +- 2 files changed, 19 insertions(+), 16 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0005-mpi-ec-Resize-when-GCRYECC_FLAG_LEAST_LEAK.patch Type: text/x-patch Size: 1939 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:11 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:11 +0900 Subject: [PATCH 8/8] mpi:ec: Introduce ec_*_lli for Weierstrass curves to be less leaky. In-Reply-To: References: Message-ID: <845562acfb5ec848897f45db9f9d28ff39793f8e.1743052412.git.gniibe@fsij.org> * mpi/ec.c (ec_addm_lli, ec_subm_lli, ec_mulm_lli): New. (dup_point_weierstrass_lli): New, using ec_*_lli. (add_points_weierstrass_a): Use ec_*_lli. (mpi_ec_mul_point_lli): Use dup_point_weierstrass_lli. Remove mpi_point_resize. -- GnuPG-bug-id: 7519 Signed-off-by: NIIBE Yutaka --- mpi/ec.c | 177 ++++++++++++++++++++++++++++++++++++++++++++++++------- 1 file changed, 155 insertions(+), 22 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0008-mpi-ec-Introduce-ec_-_lli-for-Weierstrass-curves-to-.patch Type: text/x-patch Size: 6723 bytes Desc: not available URL: From gniibe at fsij.org Thu Mar 27 06:19:10 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 27 Mar 2025 14:19:10 +0900 Subject: [PATCH 7/8] mpi:ec: Don't normalize the MPIs when GCRYECC_FLAG_LEAST_LEAK. In-Reply-To: References: Message-ID: * mpi/ec-nist.c (_gcry_mpi_ec_nist192_mod): Don't do MPN_NORMALIZE when GCRYECC_FLAG_LEAST_LEAK. (_gcry_mpi_ec_nist224_mod): Likewise. (_gcry_mpi_ec_nist256_mod): Likewise. (_gcry_mpi_ec_nist384_mod): Likewise. (_gcry_mpi_ec_nist521_mod): Likewise. * mpi/ec.c (ec_mod): Keep ->NLIMBS when GCRYECC_FLAG_LEAST_LEAK. -- GnuPG-bug-id: 7519 Signed-off-by: NIIBE Yutaka --- mpi/ec-nist.c | 16 +++++++++++----- mpi/ec.c | 6 +++++- 2 files changed, 16 insertions(+), 6 deletions(-) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0007-mpi-ec-Don-t-normalize-the-MPIs-when-GCRYECC_FLAG_LE.patch Type: text/x-patch Size: 2478 bytes Desc: not available URL: From jcb62281 at gmail.com Thu Mar 27 06:27:33 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 27 Mar 2025 00:27:33 -0500 Subject: [PATCH 6/8] mpi:ec: Use affine coordinate for mpi_ec_mul_point_lli. In-Reply-To: References: Message-ID: On 3/27/25 00:19, NIIBE Yutaka via Gcrypt-devel wrote: > * mpi/ec.c (add_points_weierstrass_a, add_points_edwards_a): New. > (mpi_ec_mul_point_lli): Use those routines directly. > Found a typo:? "P1 is never same to P1"? -- Jacob From hkario at redhat.com Thu Mar 27 11:34:44 2025 From: hkario at redhat.com (Alicja Kario) Date: Thu, 27 Mar 2025 11:34:44 +0100 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> Message-ID: <205d8463-034e-4e28-9c7d-89396806630d@redhat.com> On Thursday, 27 March 2025 03:05:28 CET, Jacob Bachmeyer via Gcrypt-devel wrote: > On 3/26/25 19:06, NIIBE Yutaka via Gcrypt-devel wrote: > [...] For the first improvement, > I realized that runtime checks in ec_mod and its friends could be leaky, > because it depends on how small/big the value is. > Could these checks instead be improved to run in constant time? > > Since it is (or can be) precondition for those routines in the code of > libgcrypt, it can be removed. Since it could be leaky, it's good to be > removed. > Hypothetically, if those preconditions are violated, what could > go wrong? How badly does the math fall apart? Could an invalid > result potentially (partially) expose the signing key? > Removing runtime checks in this type of code makes me nervous. > Maybe it is just paranoia. All operations on a curve are performed on a ring. There's no mathematical reason to make sure that representations of smaller integers are stored in fewer bytes of memory and thus can skip some computations. Multiplying zeros together gives zero outputs, doesn't matter if they're implicit or explicit. The only possible problem is if the lower level code assumes that the most significant words are not zero, but that should be easy to check... -- Regards, Alicja Kario Principal Quality Engineer, RHEL Crypto team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00, Brno, Czech Republic From gniibe at fsij.org Fri Mar 28 02:21:43 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 28 Mar 2025 10:21:43 +0900 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> Message-ID: <87cye2j6fs.fsf@haruna.fsij.org> Hello, Thank you for your comments and questions. Jacob Bachmeyer wrote: > On 3/26/25 19:06, NIIBE Yutaka wrote: >> [...] For the first improvement, >> I realized that runtime checks in ec_mod and its friends could be leaky, >> because it depends on how small/big the value is. > > Could these checks instead be improved to run in constant time? Possibly. But I don't think it's worth the effort. Let me explain a bit for libgcrypt ECC implementation (of Weierstrass curve); ECC point is represented by (X, Y) in affine coordinates, or (X:Y:Z) in projective coordinates. It uses the MPI representation for the finite field for X, Y, or Z. While, arbitrary integers can be represented in the MPI representation, for a specific curve, the finite field is the one of integers module P (P: a prime defined by the curve). Thus, for an ECC point, we can keep the integer value in the range from 0 to P-1. For an intermediate value of integer (like multiplication), 2*P is enough size. And our internal use of ec_mod is the reduction (from 0 to 2*P-1 to 0 to P-1), actually, not general computation of % P. >> Since it is (or can be) precondition for those routines in the code of >> libgcrypt, it can be removed. Since it could be leaky, it's good to be >> removed. > > Hypothetically, if those preconditions are violated, what could go > wrong?? How badly does the math fall apart?? Could an invalid result > potentially (partially) expose the signing key? For our internal use (signature generation, ECDH computation), there are no places where it's violated. No risk like exposing the private keys, for libgcrypt's own public key crypto. Because we expose the lower level API, it is possible for an application to violate the preconditions, by supplying an ECC point with larger MPIs. By the violation of the preconditions, it used to result the call of log_bug (emitting a message and abort). After the change of mine, it results wrong value, by using lower bits and ignoring upper bits. > Removing runtime checks in this type of code makes me nervous. Maybe it > is just paranoia. No, I'd understand your point. I appreciate your concerns. If we'd take an approach of more kindness, we could add the check for the external API to examine the field in ECC points for preconditions. -- From gniibe at fsij.org Fri Mar 28 02:49:32 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 28 Mar 2025 10:49:32 +0900 Subject: [PATCH 6/8] mpi:ec: Use affine coordinate for mpi_ec_mul_point_lli. In-Reply-To: References: Message-ID: <87a595kjpv.fsf@haruna.fsij.org> Hello, Jacob Bachmeyer wrote: > On 3/27/25 00:19, NIIBE Yutaka via Gcrypt-devel wrote: >> * mpi/ec.c (add_points_weierstrass_a, add_points_edwards_a): New. >> (mpi_ec_mul_point_lli): Use those routines directly. >> > Found a typo:? "P1 is never same to P1"? Thank you. I fixed the comment. It's now: ========================== /* RESULT = P1 + P2 (Weierstrass version). * P2 is represented by affine coordinate (X2,Y2). * P1 is never same to P2. * P1 may be at infinity, in this case, it results invalid RESULT. * It's caller's responsibility not to use the invalid RESULT. */ static void add_points_weierstrass_a (mpi_point_t result, ========================== Before the change, we use general "add two points" routine of (X1:Y1:Z1) + (X2:Y2:Z2) -> (X3:Y3:Z3) for "multiplying a point". We can put the assumption of Z2 == 1 for the computation of "multiplying a point", and the computation can be done simpler. (In future) we could introduce more efficient ECC multiplying routine with precomputed table lookup. This improvement allows the table of (X, Y) which is smaller than the table of (X:Y:Z). -- From jcb62281 at gmail.com Fri Mar 28 03:30:22 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Thu, 27 Mar 2025 21:30:22 -0500 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <87cye2j6fs.fsf@haruna.fsij.org> References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> <87cye2j6fs.fsf@haruna.fsij.org> Message-ID: <9425a09b-e077-40d2-b567-ecf045028ec0@gmail.com> On 3/27/25 20:21, NIIBE Yutaka wrote: > [...] > > Because we expose the lower level API, it is possible for an application > to violate the preconditions, by supplying an ECC point with larger MPIs. > > By the violation of the preconditions, it used to result the call of > log_bug (emitting a message and abort). After the change of mine, it > results wrong value, by using lower bits and ignoring upper bits. Are the ignored upper bits definitely zero or could an application reasonably expect libgcrypt to do something useful with such a point (perhaps reducing a value between P and 2*P to its proper value mod P?)? > [...] > > If we'd take an approach of more kindness, we could add the check for > the external API to examine the field in ECC points for preconditions. That is probably a good idea, along with making certain that the preconditions are documented. -- Jacob -------------- next part -------------- An HTML attachment was scrubbed... URL: From ian at cypherpunks.ca Fri Mar 28 14:11:02 2025 From: ian at cypherpunks.ca (Ian Goldberg) Date: Fri, 28 Mar 2025 09:11:02 -0400 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <87cye2j6fs.fsf@haruna.fsij.org> References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> <87cye2j6fs.fsf@haruna.fsij.org> Message-ID: On Fri, Mar 28, 2025 at 10:21:43AM +0900, NIIBE Yutaka via Gcrypt-devel wrote: > While, arbitrary integers can be represented in the MPI representation, > for a specific curve, the finite field is the one of integers module P > (P: a prime defined by the curve). Thus, for an ECC point, we can keep > the integer value in the range from 0 to P-1. For an intermediate value > of integer (like multiplication), 2*P is enough size. Do you mean P^2, not 2*P, as the bound of the intermediate result of a multiplication? From jcb62281 at gmail.com Sat Mar 29 00:27:58 2025 From: jcb62281 at gmail.com (Jacob Bachmeyer) Date: Fri, 28 Mar 2025 18:27:58 -0500 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> <87cye2j6fs.fsf@haruna.fsij.org> Message-ID: <2a3f78b8-34c3-446a-9447-b55811c2287f@gmail.com> On 3/28/25 08:11, Ian Goldberg via Gcrypt-devel wrote: > On Fri, Mar 28, 2025 at 10:21:43AM +0900, NIIBE Yutaka via Gcrypt-devel wrote: >> While, arbitrary integers can be represented in the MPI representation, >> for a specific curve, the finite field is the one of integers module P >> (P: a prime defined by the curve). Thus, for an ECC point, we can keep >> the integer value in the range from 0 to P-1. For an intermediate value >> of integer (like multiplication), 2*P is enough size. > Do you mean P^2, not 2*P, as the bound of the intermediate result of a > multiplication? I believe that the multiplications are performed modulo P, with incremental modular reductions as the calculation proceeds.? I seem to recall that this can be done (perhaps even most efficiently) on a per-bit basis.? I clearly recall my calculator being able to do "modular exponentiation" much faster than "exponentiation followed by modulus".? (Unfortunately, that calculator has since been severely damaged by leaking batteries and the model is discontinued...) That raises another question:? is the modular reduction (or more importantly its bypass if unneeded) constant-time?? In other words, is the choice of "use intermediate result (0 References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> <87cye2j6fs.fsf@haruna.fsij.org> Message-ID: <871pueqaiv.fsf@haruna.fsij.org> Hello, Thank you for your correction. On Fri, Mar 28, 2025 at 10:21:43AM +0900, I (NIIBE Yutaka) wrote: > While, arbitrary integers can be represented in the MPI representation, > for a specific curve, the finite field is the one of integers module P > (P: a prime defined by the curve). Thus, for an ECC point, we can keep > the integer value in the range from 0 to P-1. For an intermediate value > of integer (like multiplication), 2*P is enough size. Ian Goldberg wrote: > Do you mean P^2, not 2*P, as the bound of the intermediate result of a > multiplication? Yes. It means P^2. (I tried to say: it is enough to have memory, which size is 2 * size of P.) -- From gniibe at fsij.org Mon Mar 31 03:07:07 2025 From: gniibe at fsij.org (NIIBE Yutaka) Date: Mon, 31 Mar 2025 10:07:07 +0900 Subject: Less Leaky ECDSA signature generation (in master) In-Reply-To: <2a3f78b8-34c3-446a-9447-b55811c2287f@gmail.com> References: <87iknvibg3.fsf@haruna.fsij.org> <1640b445-6476-4de1-be69-fd8facf0e724@gmail.com> <87cye2j6fs.fsf@haruna.fsij.org> <2a3f78b8-34c3-446a-9447-b55811c2287f@gmail.com> Message-ID: <87y0wmovno.fsf@haruna.fsij.org> Jacob Bachmeyer wrote: > That raises another question:? is the modular reduction (or more > importantly its bypass if unneeded) constant-time?? In other words, is > the choice of "use intermediate result (0 intermediate result (P this would be a fairly severe timing leak if it is not.) In the context of ECDSA (Weierstrass curve), for NIST curves and secp256k1, it's constant-time. For other curves, it's good to have constant-time implementation, but this goal has not been achieved in libgcrypt yet. --