From gniibe at fsij.org  Wed Jul  2 04:57:55 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed,  2 Jul 2025 11:57:55 +0900
Subject: [PATCH] build: Allow build with no Kyber.
Message-ID: <f2b7d7862ff91457966b7f14ce92bf15655766cd.1751425058.git.gniibe@fsij.org>


* configure.ac (GCRYPT_PUBKEY_CIPHERS): It's kyber.lo.
* tests/Makefile.am (tests_bin): [USE_KYBER]: Add t-mlkem only when
USE_KYBER.
* tests/t-kem.c: Allow building with no Kyber.

--

Fixes-commit: 7eaa43bf0931494afccbd413d83a3010aa80cee0
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 configure.ac      | 2 +-
 tests/Makefile.am | 6 +++++-
 tests/t-kem.c     | 8 ++++++++
 3 files changed, 14 insertions(+), 2 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Allow-build-with-no-Kyber.patch
Type: text/x-patch
Size: 2910 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250702/ac6f64ff/attachment.bin>

From gniibe at fsij.org  Thu Jul  3 03:26:20 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu,  3 Jul 2025 10:26:20 +0900
Subject: [PATCH] build: More changes to allow build with no Kyber.
Message-ID: <d9acecb02a90f8a746d7a9349782a08b014c82ba.1751505974.git.gniibe@fsij.org>


* cipher/Makefile.am (libcipher_la_SOURCES): Move kyber.c and kyber.h
to ...
(EXTRA_libcipher_la_SOURCES): ... here.
* cipher/kem.c: [USE_KYBER]: Only include kyber.h when USE_KYBER.
(_gcry_kem_genkey, _gcry_kem_encap, _gcry_kem_decap): [USE_KYBER]:
Enable Kyber when USE_KYBER.
* tests/keygen.c (check_kem_keys): [USE_KYBER]: Enable Kyber when
USE_KYBER.

--

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/Makefile.am | 3 ++-
 cipher/kem.c       | 8 ++++++++
 tests/keygen.c     | 2 ++
 3 files changed, 12 insertions(+), 1 deletion(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-More-changes-to-allow-build-with-no-Kyber.patch
Type: text/x-patch
Size: 2791 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250703/65371a9d/attachment.bin>

From gniibe at fsij.org  Thu Jul  3 04:21:58 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu,  3 Jul 2025 11:21:58 +0900
Subject: [PATCH] cipher:rsa: Fix missing initialization in generate_fips.
Message-ID: <292cb75a723c74b79ccd482c48620bd5f75c9e2e.1751509309.git.gniibe@fsij.org>


* cipher/rsa.c (generate_fips): Initialize E, P and Q.

--

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/rsa.c | 1 +
 1 file changed, 1 insertion(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-rsa-Fix-missing-initialization-in-generate_fi.patch
Type: text/x-patch
Size: 356 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250703/30b35ea4/attachment.bin>

From gniibe at fsij.org  Thu Jul  3 07:16:56 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu,  3 Jul 2025 14:16:56 +0900
Subject: [PATCH] cipher:kem: Provide each enum constant as macro.
Message-ID: <e9b1c3ec91a17c62f46e6ffd5909d0ed95a89121.1751519806.git.gniibe@fsij.org>


src/gcrypt.h.in (GCRY_KEM_CM6688128F, GCRY_KEM_DHKEM25519)
(GCRY_KEM_DHKEM448, GCRY_KEM_DHKEMP256R1, GCRY_KEM_DHKEMP384R1)
(GCRY_KEM_DHKEMP521R1, GCRY_KEM_RAW_BP256, GCRY_KEM_RAW_BP384)
(GCRY_KEM_RAW_BP512, GCRY_KEM_RAW_MLKEM512, GCRY_KEM_RAW_MLKEM768)
(GCRY_KEM_RAW_MLKEM1024, GCRY_KEM_RAW_P256K1, GCRY_KEM_RAW_P256R1)
(GCRY_KEM_RAW_P384R1, GCRY_KEM_RAW_P521R1, GCRY_KEM_RAW_X25519)
(GCRY_KEM_RAW_X448, GCRY_KEM_SNTRUP761): New defines.

--

GnuPG-bug-id: 7698
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 src/gcrypt.h.in | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-kem-Provide-each-enum-constant-as-macro.patch
Type: text/x-patch
Size: 2203 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250703/a2a8cbee/attachment.bin>

From gniibe at fsij.org  Fri Jul  4 02:58:05 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri,  4 Jul 2025 09:58:05 +0900
Subject: [PATCH 1/2] cipher:gcm: Minor fix for buffer size.
Message-ID: <e414699f5da7b54665c5496487beb68b753514f2.1751590666.git.gniibe@fsij.org>


* cipher/cipher-internal.h (struct gcry_cipher_handle): Use
GCRY_GCM_BLOCK_LEN.

--

The constants are same, but it's good to use "GCM" semantically.

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/cipher-internal.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-gcm-Minor-fix-for-buffer-size.patch
Type: text/x-patch
Size: 485 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250704/f78b312d/attachment.bin>

From gniibe at fsij.org  Fri Jul  4 02:58:06 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri,  4 Jul 2025 09:58:06 +0900
Subject: [PATCH 2/2] cipher:ecc: Silence GCC 15 warning.
In-Reply-To: <e414699f5da7b54665c5496487beb68b753514f2.1751590666.git.gniibe@fsij.org>
References: <e414699f5da7b54665c5496487beb68b753514f2.1751590666.git.gniibe@fsij.org>
Message-ID: <f06e90f4137a3dfaead69c21a8993c3530e0d913.1751590666.git.gniibe@fsij.org>


* cipher/ecc-eddsa.c (_gcry_ecc_eddsa_ensure_compact): Initialize
ENC and ENCLEN before use.

--

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/ecc-eddsa.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-cipher-ecc-Silence-GCC-15-warning.patch
Type: text/x-patch
Size: 770 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250704/d7422111/attachment.bin>

From gniibe at fsij.org  Sat Jul  5 03:03:36 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 05 Jul 2025 10:03:36 +0900
Subject: GCC 15 warning for GCM implementation
Message-ID: <87a55jsb2v.fsf@haruna.fsij.org>

Hello,

I encountered a warning when I use GCC 15.

==========================
libgcrypt/cipher/cipher-gcm.c: In function 'do_ghash_buf.constprop':
libgcrypt/cipher/cipher-gcm.c:764:23: warning: array subscript 17 is above array bounds of 'unsigned char[16]' [-Warray-bounds=]
  764 |               memset (&c->u_mode.gcm.macbuf[unused], 0, n);
      |                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
==========================

It's not the case actually.  The size_t type of n (unsigned) might be
the cause of confusion, I suppose.

To silence the warning, I tried this patch:
==========================
diff --git a/cipher/cipher-gcm.c b/cipher/cipher-gcm.c
index 5bb98015..ef657742 100644
--- a/cipher/cipher-gcm.c
+++ b/cipher/cipher-gcm.c
@@ -753,14 +753,12 @@ do_ghash_buf(gcry_cipher_hd_t c, byte *hash, const byte *buf,
         }
       if (!buflen)
         {
-          if (!do_padding && unused < blocksize)
+	  if (unused < blocksize)
 	    {
-	      break;
-	    }
+              if (!do_padding)
+                break;
 
-	  n = blocksize - unused;
-	  if (n > 0)
-	    {
+              n = blocksize - unused;
 	      memset (&c->u_mode.gcm.macbuf[unused], 0, n);
 	      unused = blocksize;
 	    }
==========================

That is, new code will be following:
==========================
      if (!buflen)
        {
	  if (unused < blocksize)
	    {
              if (!do_padding)
                break;

              n = blocksize - unused;
	      memset (&c->u_mode.gcm.macbuf[unused], 0, n);
	      unused = blocksize;
	    }
        }
==========================

I think that new code has clean semantics and read easier (computing
N only when the condition holds).

Any suggestions are welcome.
-- 


From jussi.kivilinna at iki.fi  Sat Jul  5 13:37:21 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sat, 5 Jul 2025 14:37:21 +0300
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <1749905259.23240.10.camel@trentalancia.com>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <1749905259.23240.10.camel@trentalancia.com>
Message-ID: <9e05985f-c5f8-4b19-9371-0f984091a7d4@iki.fi>

On 14/06/2025 15:47, Guido Trentalancia via Gcrypt-devel wrote:
> Three runs of timed "make check" (with suppressed output) on libgcrypt
> version 1.11.1, with and without the safety feature enabled, provide
> the following meaningful results:
> 
> safe (avg): 54.26 seconds
> 
> unsafe (avg): 52.94 seconds
> 
> Therefore, the performance loss of safe versus unsafe is 2.5%.

Seems high given that "make check" is mostly single threaded test code
running mostly in user-space and checking libgcrypt implementation.

Changing these prctl settings will affect the application where libgcrypt
was loaded (directly or indirectly) and can also affect performance
of other processes running on system (see discussion & push back on
L1d flush change in linux kernel).

-Jussi



From jussi.kivilinna at iki.fi  Sat Jul  5 13:41:28 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sat, 5 Jul 2025 14:41:28 +0300
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <9e05985f-c5f8-4b19-9371-0f984091a7d4@iki.fi>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <1749905259.23240.10.camel@trentalancia.com>
 <9e05985f-c5f8-4b19-9371-0f984091a7d4@iki.fi>
Message-ID: <c8ef2818-3c81-428e-8f46-c91a215f8b74@iki.fi>

On 05/07/2025 14:37, Jussi Kivilinna wrote:
> On 14/06/2025 15:47, Guido Trentalancia via Gcrypt-devel wrote:
>> Three runs of timed "make check" (with suppressed output) on libgcrypt
>> version 1.11.1, with and without the safety feature enabled, provide
>> the following meaningful results:
>>
>> safe (avg): 54.26 seconds
>>
>> unsafe (avg): 52.94 seconds
>>
>> Therefore, the performance loss of safe versus unsafe is 2.5%.
> 
> Seems high given that "make check" is mostly single threaded test code
> running mostly in user-space and checking libgcrypt implementation.
> 
> Changing these prctl settings will affect the application where libgcrypt
> was loaded (directly or indirectly) and can also affect performance
> of other processes running on system (see discussion & push back on
> L1d flush change in linux kernel).
> 

Which means that just benchmarking libgcrypt test suite does not quite
cut it when estimating performance loss. Do you have break down how much
each prctl did affect performance individually?

-Jussi


From collin.funk1 at gmail.com  Sun Jul  6 03:12:59 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Sat, 05 Jul 2025 18:12:59 -0700
Subject: GCC 15 warning for GCM implementation
In-Reply-To: <87a55jsb2v.fsf@haruna.fsij.org>
References: <87a55jsb2v.fsf@haruna.fsij.org>
Message-ID: <878ql2m89w.fsf@gmail.com>

NIIBE Yutaka via Gcrypt-devel <gcrypt-devel at gnupg.org> writes:

> I think that new code has clean semantics and read easier (computing
> N only when the condition holds).
>
> Any suggestions are welcome.

The patch looks reasonable to me, but FYI I am not able to see the
warning with:

    $ uname -a
    Linux fedora 6.15.4-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 27 15:32:46 UTC 2025 x86_64 GNU/Linux
    $ gcc --version | sed 1q
    gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)

Collin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250705/48929882/attachment.sig>

From eggert at cs.ucla.edu  Sun Jul  6 04:39:01 2025
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Sat, 5 Jul 2025 19:39:01 -0700
Subject: GCC 15 warning for GCM implementation
In-Reply-To: <878ql2m89w.fsf@gmail.com>
References: <87a55jsb2v.fsf@haruna.fsij.org> <878ql2m89w.fsf@gmail.com>
Message-ID: <aa9e6b35-3a8d-4057-b632-3c413387290b@cs.ucla.edu>

On 2025-07-05 18:12, Collin Funk via Gcrypt-devel wrote:

> The patch looks reasonable to me, but FYI I am not able to see the
> warning with:
> 
>      $ uname -a
>      Linux fedora 6.15.4-200.fc42.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jun 27 15:32:46 UTC 2025 x86_64 GNU/Linux
>      $ gcc --version | sed 1q
>      gcc (GCC) 15.1.1 20250521 (Red Hat 15.1.1-2)

In my experience the latest GCC (which you're using) is better about not 
generating -Warray-bounds false alarms. I typically don't bother 
pacifying older GCCs; it's not worth the trouble.