From jussi.kivilinna at iki.fi  Sat Jun 14 08:24:50 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sat, 14 Jun 2025 09:24:50 +0300
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <1748186756.27370.3.camel@trentalancia.com>
References: <1748186756.27370.3.camel@trentalancia.com>
Message-ID: <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>

Hello,

On 25/05/2025 18:25, Guido Trentalancia via Gcrypt-devel wrote:
> Disable CPU speculation-related misfeatures which are in
> fact vulnerabilities causing data leaks:
> 
>   - Speculative Store Bypass
>   - Indirect Branch Speculation
>   - Flush L1D Cache on context switch out of the task
> 
> For further information see the kernel documentation:
> Documentation/userspace-api/spec_ctrl.rst
> 
> Signed-off-by: Guido Trentalancia <guido at trentalancia.com>
> ---
>   src/global.c |   21 +++++++++++++++++++++
>   1 file changed, 21 insertions(+)
> 
> --- a/src/global.c	2024-04-26 14:08:12.000000000 +0200
> +++ b/src/global.c	2025-05-25 16:03:24.718598884 +0200
> @@ -33,6 +33,7 @@
>   #ifdef HAVE_SYSLOG
>   # include <syslog.h>
>   #endif /*HAVE_SYSLOG*/
> +#include <sys/prctl.h>
>   
>   #include "g10lib.h"
>   #include "gcrypt-testapi.h"
> @@ -95,6 +96,26 @@ global_init (void)
>       return;
>     _gcry_global_any_init_done = 1;
>   
> +/* Disable CPU speculation-related misfeatures which are in
> + * fact vulnerabilities causing data leaks: see the kernel
> + * documentation: Documentation/userspace-api/spec_ctrl.rst
> + *
> + * - Speculative Store Bypass
> + * - Indirect Branch Speculation
> + * - Flush L1D Cache on context switch out of the task
> + */
> +#ifdef PR_SPEC_STORE_BYPASS
> +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS, PR_SPEC_FORCE_DISABLE, 0, 0);
> +#endif
> +
> +#ifdef PR_SPEC_INDIRECT_BRANCH
> +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH, PR_SPEC_FORCE_DISABLE, 0, 0);
> +#endif
> +
> +#ifdef PR_SPEC_L1D_FLUSH
> +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH, PR_SPEC_FORCE_DISABLE, 0, 0);
> +#endif
> +

Do other crypto libraries do this? Surely this control should not be in library side but in
application. Libgcrypt could be loaded by application for number of reasons and not all
those use-cases require toggling these knobs (such as file checksumming, CRC or SHA). Even
worse, libgcrypt might be loaded by another library and actual application may not even
have knowledge of that. Libgcrypt might get loaded through library dependencies but
end up not being used by application at all (except initialization, global_init, etc).

-Jussi



From collin.funk1 at gmail.com  Sat Jun 14 08:40:03 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Fri, 13 Jun 2025 23:40:03 -0700
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
Message-ID: <87zfea25do.fsf@gmail.com>

Jussi Kivilinna <jussi.kivilinna at iki.fi> writes:

> Do other crypto libraries do this? Surely this control should not be in library side but in
> application. Libgcrypt could be loaded by application for number of reasons and not all
> those use-cases require toggling these knobs (such as file checksumming, CRC or SHA). Even
> worse, libgcrypt might be loaded by another library and actual application may not even
> have knowledge of that. Libgcrypt might get loaded through library dependencies but
> end up not being used by application at all (except initialization, global_init, etc).

I had the same thought when I saw the patch and checked openssl. It
doesn't do it. Perhaps some others do, but I don't have them cloned to
check. :)

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/20250613/09c91282/attachment.sig>

From jussi.kivilinna at iki.fi  Sat Jun 14 08:13:42 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sat, 14 Jun 2025 09:13:42 +0300
Subject: [PATCH 2/2] blake2s-avx512: mark merged load as such
In-Reply-To: <20250614061342.884757-1-jussi.kivilinna@iki.fi>
References: <20250614061342.884757-1-jussi.kivilinna@iki.fi>
Message-ID: <20250614061342.884757-2-jussi.kivilinna@iki.fi>

* cipher/blake2s-amd64-avx512.S (GATHER_MSG_8): Add comment
on 'vmovq' that is is merged load.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 cipher/blake2s-amd64-avx512.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cipher/blake2s-amd64-avx512.S b/cipher/blake2s-amd64-avx512.S
index 7fd6fe77..26b08df0 100644
--- a/cipher/blake2s-amd64-avx512.S
+++ b/cipher/blake2s-amd64-avx512.S
@@ -166,7 +166,7 @@
                    s9, s10, s11, s12, s13, s14, s15) \
         vmovd (s0)*4(RINBLKS), m1; \
           vmovd (s1)*4(RINBLKS), m2; \
-            vmovq (s8)*4(RINBLKS), m3; \
+            vmovq (s8)*4(RINBLKS), m3; /* merged load */ \
               vmovd (s9)*4(RINBLKS), m4; \
         vpinsrd $1, (s2)*4(RINBLKS), m1, m1; \
           vpinsrd $1, (s3)*4(RINBLKS), m2, m2; \
-- 
2.48.1



From jussi.kivilinna at iki.fi  Sat Jun 14 08:13:41 2025
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Sat, 14 Jun 2025 09:13:41 +0300
Subject: [PATCH 1/2] blake2s-avx512: remove duplicate load
Message-ID: <20250614061342.884757-1-jussi.kivilinna@iki.fi>

* cipher/blake2s-amd64-avx512.S (GATHER_MSG_3): Remove
duplicate load which is already handled with 'vmovdqu32'
earlier.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 cipher/blake2s-amd64-avx512.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/cipher/blake2s-amd64-avx512.S b/cipher/blake2s-amd64-avx512.S
index 543944bf..7fd6fe77 100644
--- a/cipher/blake2s-amd64-avx512.S
+++ b/cipher/blake2s-amd64-avx512.S
@@ -119,7 +119,6 @@
               vpinsrd $1, (s11)*4(RINBLKS), m4, m4; \
         vpinsrd $2, (s4)*4(RINBLKS), m1, m1; \
           vpinsrd $2, (s5)*4(RINBLKS), m2, m2; \
-            vpinsrd $2, (s12)*4(RINBLKS), m3, m3; \
               vpinsrd $2, (s13)*4(RINBLKS), m4, m4; \
         vpinsrd $3, (s6)*4(RINBLKS), m1, m1; \
           vpinsrd $3, (s7)*4(RINBLKS), m2, m2; \
-- 
2.48.1



From guido at trentalancia.com  Sat Jun 14 14:47:39 2025
From: guido at trentalancia.com (Guido Trentalancia)
Date: Sat, 14 Jun 2025 14:47:39 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
Message-ID: <1749905259.23240.10.camel@trentalancia.com>

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%.

In my opinion, such minimal performance loss does not justify the risk
of leaving a vulnerable library around the system !

Consider, you cannot predict what applications (or libraries) are going
to use libgcrypt code (now or in the future). We only know gnupg is
currently using it and so a specific patch has already been posted for
that...

Guido

On Sat, 14/06/2025 at 09.24 +0300, Jussi Kivilinna wrote:
> Hello,
> 
> On 25/05/2025 18:25, Guido Trentalancia via Gcrypt-devel wrote:
> > Disable CPU speculation-related misfeatures which are in
> > fact vulnerabilities causing data leaks:
> > 
> >   - Speculative Store Bypass
> >   - Indirect Branch Speculation
> >   - Flush L1D Cache on context switch out of the task
> > 
> > For further information see the kernel documentation:
> > Documentation/userspace-api/spec_ctrl.rst
> > 
> > Signed-off-by: Guido Trentalancia <guido at trentalancia.com>
> > ---
> >   src/global.c |   21 +++++++++++++++++++++
> >   1 file changed, 21 insertions(+)
> > 
> > --- a/src/global.c	2024-04-26 14:08:12.000000000 +0200
> > +++ b/src/global.c	2025-05-25 16:03:24.718598884 +0200
> > @@ -33,6 +33,7 @@
> >   #ifdef HAVE_SYSLOG
> >   # include <syslog.h>
> >   #endif /*HAVE_SYSLOG*/
> > +#include <sys/prctl.h>
> >   
> >   #include "g10lib.h"
> >   #include "gcrypt-testapi.h"
> > @@ -95,6 +96,26 @@ global_init (void)
> >       return;
> >     _gcry_global_any_init_done = 1;
> >   
> > +/* Disable CPU speculation-related misfeatures which are in
> > + * fact vulnerabilities causing data leaks: see the kernel
> > + * documentation: Documentation/userspace-api/spec_ctrl.rst
> > + *
> > + * - Speculative Store Bypass
> > + * - Indirect Branch Speculation
> > + * - Flush L1D Cache on context switch out of the task
> > + */
> > +#ifdef PR_SPEC_STORE_BYPASS
> > +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_STORE_BYPASS,
> > PR_SPEC_FORCE_DISABLE, 0, 0);
> > +#endif
> > +
> > +#ifdef PR_SPEC_INDIRECT_BRANCH
> > +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_INDIRECT_BRANCH,
> > PR_SPEC_FORCE_DISABLE, 0, 0);
> > +#endif
> > +
> > +#ifdef PR_SPEC_L1D_FLUSH
> > +  prctl(PR_SET_SPECULATION_CTRL, PR_SPEC_L1D_FLUSH,
> > PR_SPEC_FORCE_DISABLE, 0, 0);
> > +#endif
> > +
> 
> Do other crypto libraries do this? Surely this control should not be
> in library side but in
> application. Libgcrypt could be loaded by application for number of
> reasons and not all
> those use-cases require toggling these knobs (such as file
> checksumming, CRC or SHA). Even
> worse, libgcrypt might be loaded by another library and actual
> application may not even
> have knowledge of that. Libgcrypt might get loaded through library
> dependencies but
> end up not being used by application at all (except initialization,
> global_init, etc).
> 
> -Jussi
> 


From gniibe at fsij.org  Tue Jun 17 04:42:23 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 17 Jun 2025 11:42:23 +0900
Subject: ML-DSA (Dilithium) for libgcrypt
Message-ID: <87ikkvqeb4.fsf@haruna.fsij.org>

Hello,

For 1.12, I am working to integrate ML-DSA into libgcrypt.  The ticket is:

    https://dev.gnupg.org/T7640

I created gniibe/t7640 branch for this task.  Please have a look at:

    https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7640/

I go through the same approach of Kyber integration into libgcrypt.

I'm going to merge the changes to master, step by step.


I wonder if use of secure memory is needed or not.  If needed, an
application should have a setting of auto expanding secure memory with
GCRYCTL_AUTO_EXPAND_SECMEM, because the size of things for PQC matters.
-- 


From gniibe at fsij.org  Tue Jun 17 07:31:55 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 17 Jun 2025 14:31:55 +0900
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
Message-ID: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>


* cipher/pubkey-util.c (_gcry_pk_util_data_to_mpi): Remove bogus check
for VALUELEN.

--

Fixes-commit: 37d0a1ebdc2dc74df4fb6bf0621045018122a68f
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/pubkey-util.c | 20 --------------------
 1 file changed, 20 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-pk-sexp-Remove-bogus-checks-in-SEXP-parsing.patch
Type: text/x-patch
Size: 1841 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250617/72548548/attachment-0001.bin>

From jcb62281 at gmail.com  Wed Jun 18 03:55:16 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 17 Jun 2025 20:55:16 -0500
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
Message-ID: <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com>

On 6/17/25 00:31, NIIBE Yutaka via Gcrypt-devel wrote:
> * cipher/pubkey-util.c (_gcry_pk_util_data_to_mpi): Remove bogus check
> for VALUELEN.

NACK!? NACK!? NACK!

Those are checks for integer overflow.? (They may even be correct if 
VALUELEN is unsigned.)

If VALUELEN is a signed type, they are undefined behavior and need to be 
fixed, not removed.


-- Jacob



From collin.funk1 at gmail.com  Wed Jun 18 04:20:38 2025
From: collin.funk1 at gmail.com (Collin Funk)
Date: Tue, 17 Jun 2025 19:20:38 -0700
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
 <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com>
Message-ID: <87ldpprds9.fsf@gmail.com>

Jacob Bachmeyer via Gcrypt-devel <gcrypt-devel at gnupg.org> writes:

> NACK!? NACK!? NACK!
>
> Those are checks for integer overflow.? (They may even be correct if
> VALUELEN is unsigned.)
>
> If VALUELEN is a signed type, they are undefined behavior and need to
> be fixed, not removed.

It is a size_t so it is unsigned.

But it looks harmless to remove to me. The call to 'malloc' in
'_gcry_sexp_nth_buffer' will fail before VALUELEN overflows.

Here is an example program:

    $ cat main.c 
    #include <stdint.h>
    #include <stdlib.h>
    #include <stdio.h>
    #include <string.h>
    #include <errno.h>
    int
    main (void)
    {
      char *p = malloc (SIZE_MAX / 8 / 2);
      if (p)
        abort ();
      printf ("%s\n", strerror (errno));
      return 0;
    }
    $ gcc main.c 
    $ ./a.out 
    Cannot allocate memory

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/20250617/3da24766/attachment.sig>

From jcb62281 at gmail.com  Wed Jun 18 05:27:11 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 17 Jun 2025 22:27:11 -0500
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <87ldpprds9.fsf@gmail.com>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
 <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com> <87ldpprds9.fsf@gmail.com>
Message-ID: <6a2fa8b9-8f66-495e-b5bc-0d8f8058b776@gmail.com>

On 6/17/25 21:20, Collin Funk wrote:
> Jacob Bachmeyer via Gcrypt-devel <gcrypt-devel at gnupg.org> writes:
>
>> NACK!? NACK!? NACK!
>>
>> Those are checks for integer overflow.? (They may even be correct if
>> VALUELEN is unsigned.)
>>
>> If VALUELEN is a signed type, they are undefined behavior and need to
>> be fixed, not removed.
> It is a size_t so it is unsigned.

Then the checks are correct as written.

> But it looks harmless to remove to me. The call to 'malloc' in
> '_gcry_sexp_nth_buffer' will fail before VALUELEN overflows.

I advocate for defense-in-depth, especially in software as 
security-critical as GPG.? Nor are these expensive checks:? one 
multiplication and one comparison are very cheap compared to public key 
operations.


-- Jacob




From gniibe at fsij.org  Wed Jun 18 09:39:10 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 18 Jun 2025 16:39:10 +0900
Subject: [PATCH 1/2] cipher: Add PUBKEY_FLAG_BYTE_STRING to support byte
 string data.
Message-ID: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>


* cipher/pubkey-util.c (_gcry_pk_util_data_to_mpi): Add support for
PUBKEY_FLAG_BYTE_STRING.
* src/cipher.h (PUBKEY_FLAG_BYTE_STRING): New.

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/pubkey-util.c | 33 ++++++++++++++++++++++++++++++++-
 src/cipher.h         |  1 +
 2 files changed, 33 insertions(+), 1 deletion(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-Add-PUBKEY_FLAG_BYTE_STRING-to-support-byte-s.patch
Type: text/x-patch
Size: 2011 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250618/d5319879/attachment.bin>

From gniibe at fsij.org  Wed Jun 18 09:39:11 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 18 Jun 2025 16:39:11 +0900
Subject: [PATCH 2/2] cipher: Support random-override with
 PUBKEY_FLAG_BYTE_STRING.
In-Reply-To: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>
References: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>
Message-ID: <085d6540a6dd2a1a5d2cfb64a0ef7c655a37b259.1750232293.git.gniibe@fsij.org>


* cipher/pubkey-util.c (_gcry_pk_util_init_encoding_ctx): Initialize
RND and RNDLEN field.
(_gcry_pk_util_free_encoding_ctx): Release memory by RND field.
(_gcry_pk_util_data_to_mpi): Support optional "random-override".
* src/cipher.h (struct pk_encoding_ctx): Add RND and RNDLEN.

--

Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/pubkey-util.c | 13 +++++++++++++
 src/cipher.h         |  4 ++++
 2 files changed, 17 insertions(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-cipher-Support-random-override-with-PUBKEY_FLAG_BYTE.patch
Type: text/x-patch
Size: 1577 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250618/a478609e/attachment.bin>

From eggert at cs.ucla.edu  Wed Jun 18 18:53:30 2025
From: eggert at cs.ucla.edu (Paul Eggert)
Date: Wed, 18 Jun 2025 09:53:30 -0700
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <6a2fa8b9-8f66-495e-b5bc-0d8f8058b776@gmail.com>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
 <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com> <87ldpprds9.fsf@gmail.com>
 <6a2fa8b9-8f66-495e-b5bc-0d8f8058b776@gmail.com>
Message-ID: <7735e2c2-2ea6-4a22-96b2-f232dd51811e@cs.ucla.edu>

On 2025-06-17 20:27, Jacob Bachmeyer via Gcrypt-devel wrote:
>> It is a size_t so it is unsigned.
> 
> Then the checks are correct as written.

Not on oddball platforms where SIZE_MAX <= INT_MAX, because in that case 
it's signed integer overflow and behavior is undefined. POSIX allows 
such platforms.

Maybe gcrypt should have a static_assert (INT_MAX < SIZE_MAX)? That 
might be easier than adjusting all its size_t-calculating code to be 
portable to oddball platforms. Unless there's a goal to be fully POSIX 
portable.

More important, the checks are not valid on platforms like x86-64 where 
UINT_MAX < SIZE_MAX, because mpi_set_opaque takes an unsigned int arg.
This looks like a real bug, at least just from local inspection.


> I advocate for defense-in-depth

Although this defense is needed it's not defense in depth, as there's no 
guarantee malloc will fail with sizes close to SIZE_MAX.

However, it's better to use ckd_mul than to try do do multiplication 
overflow checks by hand, and the code would be better if it did that. 
You can use Gnulib's stdckdint module to support ckd_mul on pre-C23 
platforms.


From jcb62281 at gmail.com  Thu Jun 19 04:13:38 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Wed, 18 Jun 2025 21:13:38 -0500
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <7735e2c2-2ea6-4a22-96b2-f232dd51811e@cs.ucla.edu>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
 <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com> <87ldpprds9.fsf@gmail.com>
 <6a2fa8b9-8f66-495e-b5bc-0d8f8058b776@gmail.com>
 <7735e2c2-2ea6-4a22-96b2-f232dd51811e@cs.ucla.edu>
Message-ID: <e16e823a-d0da-4b7b-b1e7-d2d0d25e7448@gmail.com>

On 6/18/25 11:53, Paul Eggert wrote:
> On 2025-06-17 20:27, Jacob Bachmeyer via Gcrypt-devel wrote:
>>> It is a size_t so it is unsigned.
>>
>> Then the checks are correct as written.
>
> Not on oddball platforms where SIZE_MAX <= INT_MAX, because in that 
> case it's signed integer overflow and behavior is undefined. POSIX 
> allows such platforms.
>
> Maybe gcrypt should have a static_assert (INT_MAX < SIZE_MAX)? That 
> might be easier than adjusting all its size_t-calculating code to be 
> portable to oddball platforms. Unless there's a goal to be fully POSIX 
> portable.
>
> More important, the checks are not valid on platforms like x86-64 
> where UINT_MAX < SIZE_MAX, because mpi_set_opaque takes an unsigned 
> int arg.

I was about to say that I thought amd64 would trip that static assert, 
since "int" is 32-bit but "long int" and "size_t" are 64-bit.

> This looks like a real bug, at least just from local inspection.

So the checks are indeed incorrect...

>> I advocate for defense-in-depth
>
> Although this defense is needed it's not defense in depth, as there's 
> no guarantee malloc will fail with sizes close to SIZE_MAX.

... and the checks are also needed.? "Fun."


-- Jacob




From wk at gnupg.org  Sun Jun 22 18:50:37 2025
From: wk at gnupg.org (Werner Koch)
Date: Sun, 22 Jun 2025 18:50:37 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <87zfea25do.fsf@gmail.com> (Collin Funk via Gcrypt-devel's
 message of "Fri, 13 Jun 2025 23:40:03 -0700")
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <87zfea25do.fsf@gmail.com>
Message-ID: <87plevzpnm.fsf@jacob.g10code.de>

On Fri, 13 Jun 2025 23:40, Collin Funk said:

> I had the same thought when I saw the patch and checked openssl. It
> doesn't do it. Perhaps some others do, but I don't have them cloned to
> check. :)

I also agree.  A library should not change properties of the system -
this is the task of the application.  A common exception I recall is to
ignore SIGPIPE because this is actualy a misfeature and libraries which
spawn other processes should make sure that this is ignored.


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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250622/c35eab1c/attachment.sig>

From wk at gnupg.org  Sun Jun 22 19:00:48 2025
From: wk at gnupg.org (Werner Koch)
Date: Sun, 22 Jun 2025 19:00:48 +0200
Subject: [PATCH 1/2] cipher: Add PUBKEY_FLAG_BYTE_STRING to support byte
 string data.
In-Reply-To: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>
 (NIIBE Yutaka via Gcrypt-devel's message of "Wed, 18 Jun 2025 16:39:10
 +0900")
References: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>
Message-ID: <87ldpjzp6n.fsf@jacob.g10code.de>

On Wed, 18 Jun 2025 16:39, NIIBE Yutaka said:
> +      /* Get VALUE.  */
> +      value = sexp_nth_buffer (lvalue, 1, &valuelen);
> +      if (!value)
> +        rc = GPG_ERR_INV_OBJ;
> +      if (rc)
> +        goto leave;

Please change the above to 

> +      if (!value)
> +        {
> +          rc = GPG_ERR_INV_OBJ;
> +          goto leave;
> +        }

just because this is easier to understand and the same pattern we use
above.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250622/59cb6880/attachment.sig>

From guido at trentalancia.com  Mon Jun 23 13:57:04 2025
From: guido at trentalancia.com (Guido Trentalancia)
Date: Mon, 23 Jun 2025 13:57:04 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <87plevzpnm.fsf@jacob.g10code.de>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi> <87zfea25do.fsf@gmail.com>
 <87plevzpnm.fsf@jacob.g10code.de>
Message-ID: <1750679824.6157.2.camel@trentalancia.com>

It does not change the property of the system, it only changes the
properties of the process (or thread).

# info prctl | sed -n 4,4p

prctl - operations on a process or thread

Regards,

Guido

On Sun, 22/06/2025 at 18.50 +0200, Werner Koch wrote:
> On Fri, 13 Jun 2025 23:40, Collin Funk said:
> 
> > I had the same thought when I saw the patch and checked openssl. It
> > doesn't do it. Perhaps some others do, but I don't have them cloned
> > to
> > check. :)
> 
> I also agree.  A library should not change properties of the system -
> this is the task of the application.  A common exception I recall is
> to
> ignore SIGPIPE because this is actualy a misfeature and libraries
> which
> spawn other processes should make sure that this is ignored.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 


From wk at gnupg.org  Mon Jun 23 19:58:11 2025
From: wk at gnupg.org (Werner Koch)
Date: Mon, 23 Jun 2025 19:58:11 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <1750679824.6157.2.camel@trentalancia.com> (Guido Trentalancia
 via Gcrypt-devel's message of "Mon, 23 Jun 2025 13:57:04 +0200")
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <87zfea25do.fsf@gmail.com> <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
Message-ID: <87pleuxrv0.fsf@jacob.g10code.de>

On Mon, 23 Jun 2025 13:57, Guido Trentalancia said:
> It does not change the property of the system, it only changes the

Sorry, with "system" I meant the process with its main application and
all other libraries.  Libgcrypt is a library usally linked at runtime
and thus it would be surprising if it changes such process properties.


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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250623/e231e79d/attachment.sig>

From guido at trentalancia.com  Mon Jun 23 20:22:53 2025
From: guido at trentalancia.com (Guido Trentalancia)
Date: Mon, 23 Jun 2025 20:22:53 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <87pleuxrv0.fsf@jacob.g10code.de>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi> <87zfea25do.fsf@gmail.com>
 <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
 <87pleuxrv0.fsf@jacob.g10code.de>
Message-ID: <1750702973.6301.12.camel@trentalancia.com>

All parts of the cryptographic code can change the process through
prctl(), in order to avoid the information disclosure vulnerabilities.
The best way to achieve protection is obviously by calling prctl()
during the cryptographic application startup and this is precisely what
the gnupg patch does:
https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035904.html
However it is not possible to foresee all the other applications using
libgcrypt, so another preventive patch has been submitted so that
prctl() is also called by the cryptographic library and this is what
the libgcrypt patch does:
https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005856.html
By applying the companion libgcrypt patch we offer some kind of
protection to applications other than gnupg, even though the level of
protection is not the same as if prctl() was called at application
startup.
Please note that calling prctl() twice in gnupg and then in libgcrypt
has no side-effects.
The fact that other cryptographic libraries such as openssl do not do
the same only means that they are vulnerable those cryptographic
information disclosure vulnerabilities.
Regards,
Guido
On Mon, 23/06/2025 at 19.58 +0200, Werner Koch wrote:
> On Mon, 23 Jun 2025 13:57, Guido Trentalancia said:
> > It does not change the property of the system, it only changes the
> 
> Sorry, with "system" I meant the process with its main application
> and
> all other libraries.  Libgcrypt is a library usally linked at runtime
> and thus it would be surprising if it changes such process
> properties.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250623/60b5c882/attachment.html>

From gniibe at fsij.org  Tue Jun 24 08:23:01 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 24 Jun 2025 15:23:01 +0900
Subject: [PATCH] cipher:pk:sexp: Remove bogus checks in SEXP parsing.
In-Reply-To: <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com>
References: <45476b1c3c831973ef54c757ee0b81579091ecf5.1750138237.git.gniibe@fsij.org>
 <31950c3f-a2ed-4519-a954-ed7bfdc23eeb@gmail.com>
Message-ID: <87frfp64l6.fsf@haruna.fsij.org>

Hello, again,

I wrote:
> * cipher/pubkey-util.c (_gcry_pk_util_data_to_mpi): Remove bogus check
> for VALUELEN.

I withdraw the proposal of this patch.


Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
> NACK!? NACK!? NACK!

Thank you for your feedback.

Looking the commit log and other use cases, I learned that it is the
check when we use opaque MPI; Internally, when MPI is opaque, it holds a
information of number of bits.

The check:

	8*VALUELEN < VALUELEN

detects the case where it cannot be represented by an opaque MPI.
-- 


From gniibe at fsij.org  Tue Jun 24 08:39:53 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 24 Jun 2025 15:39:53 +0900
Subject: [PATCH 1/2] cipher: Add PUBKEY_FLAG_BYTE_STRING to support byte
 string data.
In-Reply-To: <87ldpjzp6n.fsf@jacob.g10code.de>
References: <4edf8e38cbe795a2568a15e5c94e46be5fa12416.1750232293.git.gniibe@fsij.org>
 <87ldpjzp6n.fsf@jacob.g10code.de>
Message-ID: <87cyat63t2.fsf@haruna.fsij.org>

Werner Koch <wk at gnupg.org> wrote:
>> +      /* Get VALUE.  */
>> +      value = sexp_nth_buffer (lvalue, 1, &valuelen);
>> +      if (!value)
>> +        rc = GPG_ERR_INV_OBJ;
>> +      if (rc)
>> +        goto leave;
>
> Please change the above to 
>
>> +      if (!value)
>> +        {
>> +          rc = GPG_ERR_INV_OBJ;
>> +          goto leave;
>> +        }
>
> just because this is easier to understand and the same pattern we use
> above.

I see.  Following your suggestion, applied those patches and pushed to master.
-- 


From gniibe at fsij.org  Wed Jun 25 03:36:48 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 25 Jun 2025 10:36:48 +0900
Subject: [PATCH] cipher:kem:ecc: Support secp256k1 by KEM API.
Message-ID: <ca896fe55184a0e65646e06faedaa11a5c3086b8.1750815394.git.gniibe@fsij.org>


* src/gcrypt.h.in (GCRY_KEM_RAW_P256K1): New.
* cipher/kem-ecc.c (algo_to_curve, algo_to_seckey_len): Support
GCRY_KEM_RAW_P256K1.

--

GnuPG-bug-id: 7698
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/kem-ecc.c |  6 ++++++
 src/gcrypt.h.in  | 13 +++++++------
 2 files changed, 13 insertions(+), 6 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-kem-ecc-Support-secp256k1-by-KEM-API.patch
Type: text/x-patch
Size: 1622 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250625/0c7a5e76/attachment.bin>

From jcb62281 at gmail.com  Wed Jun 25 04:11:58 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Tue, 24 Jun 2025 21:11:58 -0500
Subject: [PATCH] cipher:kem:ecc: Support secp256k1 by KEM API.
In-Reply-To: <ca896fe55184a0e65646e06faedaa11a5c3086b8.1750815394.git.gniibe@fsij.org>
References: <ca896fe55184a0e65646e06faedaa11a5c3086b8.1750815394.git.gniibe@fsij.org>
Message-ID: <5c182fdc-6d49-4c78-b0ea-288d5dc1395f@gmail.com>

On 6/24/25 20:36, NIIBE Yutaka via Gcrypt-devel wrote:
> * src/gcrypt.h.in (GCRY_KEM_RAW_P256K1): New.
> * cipher/kem-ecc.c (algo_to_curve, algo_to_seckey_len): Support
> GCRY_KEM_RAW_P256K1.

Possible typo?? The entry for GCRY_KEM_RAW_P256K1 (39) is commented 
"SECP256R1".? Is that correct?? Should it be "SECP256K1" instead?


-- Jacob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250624/d38ba1fa/attachment-0001.html>

From gniibe at fsij.org  Wed Jun 25 07:09:31 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 25 Jun 2025 14:09:31 +0900
Subject: [PATCH] cipher:kem:ecc: Support secp256k1 by KEM API.
In-Reply-To: <5c182fdc-6d49-4c78-b0ea-288d5dc1395f@gmail.com>
References: <ca896fe55184a0e65646e06faedaa11a5c3086b8.1750815394.git.gniibe@fsij.org>
 <5c182fdc-6d49-4c78-b0ea-288d5dc1395f@gmail.com>
Message-ID: <87zfdwo19w.fsf@haruna.fsij.org>

Hello,

Thanks for your check, as always.

Jacob Bachmeyer <jcb62281 at gmail.com> wrote:
> Should it be "SECP256K1" instead?

Yes.  You are right.

I should have done double check (or not to be so hurry when preparing
breakfast :-).


GnuPG are adopting KEM API for ECC encryption/decryption, that's the
background of this change.
-- 


From wk at gnupg.org  Wed Jun 25 18:12:51 2025
From: wk at gnupg.org (Werner Koch)
Date: Wed, 25 Jun 2025 18:12:51 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <1750702973.6301.12.camel@trentalancia.com> (Guido Trentalancia
 via Gcrypt-devel's message of "Mon, 23 Jun 2025 20:22:53 +0200")
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <87zfea25do.fsf@gmail.com> <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
 <87pleuxrv0.fsf@jacob.g10code.de>
 <1750702973.6301.12.camel@trentalancia.com>
Message-ID: <87cyarx0jg.fsf@jacob.g10code.de>

On Mon, 23 Jun 2025 20:22, Guido Trentalancia said:
> The best way to achieve protection is obviously by calling prctl()
> during the cryptographic application startup and this is precisely what
> the gnupg patch does:
> https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035904.html

Right.  I replied with

  If that is a misfeature it needs to be fixed at the pl?ce where it was
  introduced and not just in a single binary.  If this code is really
  needed it would first of all be useful in Libgcrypt only then then you
  should put it into gnupg/common/init.c:early_system_init.
  
  Specific Linux code is in general not a good idea, if that is required,
  please write a proper configure test for this feature and use a
  dedicated macro.  A more detailed explanation of the pro and cons would
  also be appreciated.

But you did not came up with a fixed patch but instead you wrote

  A test in the autoconf-generated "configure" script is not needed,
  because the patch automatically detects whether the glibc and kernel
  versions support disabling those vulnerabilities.

and refused my above advise.  If you don't want to write the respective
autoconf checks you may also add a configure option to enable your code.

I would also suggest to use an environemnt variabale to activate the
tests.  For example, for signature verification the whole code is
superflous.  An envar let the admin decide whether it is worth to do
that.

One may also want to extend ld and ld.so to process a dedicated ELF
segment to enable linking in that code.  This way a library can demand
the use of this code.








> However it is not possible to foresee all the other applications using
> libgcrypt, so another preventive patch has been submitted so that
> prctl() is also called by the cryptographic library and this is what
> the libgcrypt patch does:
> https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005856.html
> By applying the companion libgcrypt patch we offer some kind of
> protection to applications other than gnupg, even though the level of
> protection is not the same as if prctl() was called at application
> startup.
> Please note that calling prctl() twice in gnupg and then in libgcrypt
> has no side-effects.
> The fact that other cryptographic libraries such as openssl do not do
> the same only means that they are vulnerable those cryptographic
> information disclosure vulnerabilities.
> Regards,
> Guido
> On Mon, 23/06/2025 at 19.58 +0200, Werner Koch wrote:
>> On Mon, 23 Jun 2025 13:57, Guido Trentalancia said:
>> > It does not change the property of the system, it only changes the
>> 
>> Sorry, with "system" I meant the process with its main application
>> and
>> all other libraries.  Libgcrypt is a library usally linked at runtime
>> and thus it would be surprising if it changes such process
>> properties.
>> 
>> 
>> Salam-Shalom,
>> 
>>    Werner
>> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
>

-- 
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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250625/e2eac941/attachment.sig>

From guido at trentalancia.com  Wed Jun 25 18:24:10 2025
From: guido at trentalancia.com (Guido Trentalancia)
Date: Wed, 25 Jun 2025 18:24:10 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <87cyarx0jg.fsf@jacob.g10code.de>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi> <87zfea25do.fsf@gmail.com>
 <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
 <87pleuxrv0.fsf@jacob.g10code.de>
 <1750702973.6301.12.camel@trentalancia.com>
 <87cyarx0jg.fsf@jacob.g10code.de>
Message-ID: <1750868650.17852.3.camel@trentalancia.com>

There is no profit in changing additional parts of the code, for that
only overcomplicates the underlying problem and the source code, so
further changes won't happen.

The patch is provided as it is.

Regards,

Guido

On Wed, 25/06/2025 at 18.12 +0200, Werner Koch wrote:
> On Mon, 23 Jun 2025 20:22, Guido Trentalancia said:
> > The best way to achieve protection is obviously by calling prctl()
> > during the cryptographic application startup and this is precisely
> > what
> > the gnupg patch does:
> > https://lists.gnupg.org/pipermail/gnupg-devel/2025-May/035904.html
> 
> Right.  I replied with
> 
>   If that is a misfeature it needs to be fixed at the pl?ce where it
> was
>   introduced and not just in a single binary.  If this code is really
>   needed it would first of all be useful in Libgcrypt only then then
> you
>   should put it into gnupg/common/init.c:early_system_init.
>   
>   Specific Linux code is in general not a good idea, if that is
> required,
>   please write a proper configure test for this feature and use a
>   dedicated macro.  A more detailed explanation of the pro and cons
> would
>   also be appreciated.
> 
> But you did not came up with a fixed patch but instead you wrote
> 
>   A test in the autoconf-generated "configure" script is not needed,
>   because the patch automatically detects whether the glibc and
> kernel
>   versions support disabling those vulnerabilities.
> 
> and refused my above advise.  If you don't want to write the
> respective
> autoconf checks you may also add a configure option to enable your
> code.
> 
> I would also suggest to use an environemnt variabale to activate the
> tests.  For example, for signature verification the whole code is
> superflous.  An envar let the admin decide whether it is worth to do
> that.
> 
> One may also want to extend ld and ld.so to process a dedicated ELF
> segment to enable linking in that code.  This way a library can
> demand
> the use of this code.
> 
> 
> 
> 
> 
> 
> 
> 
> > However it is not possible to foresee all the other applications
> > using
> > libgcrypt, so another preventive patch has been submitted so that
> > prctl() is also called by the cryptographic library and this is
> > what
> > the libgcrypt patch does:
> > https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005856.html
> > By applying the companion libgcrypt patch we offer some kind of
> > protection to applications other than gnupg, even though the level
> > of
> > protection is not the same as if prctl() was called at application
> > startup.
> > Please note that calling prctl() twice in gnupg and then in
> > libgcrypt
> > has no side-effects.
> > The fact that other cryptographic libraries such as openssl do not
> > do
> > the same only means that they are vulnerable those cryptographic
> > information disclosure vulnerabilities.
> > Regards,
> > Guido
> > On Mon, 23/06/2025 at 19.58 +0200, Werner Koch wrote:
> > > On Mon, 23 Jun 2025 13:57, Guido Trentalancia said:
> > > > It does not change the property of the system, it only changes
> > > > the
> > > 
> > > Sorry, with "system" I meant the process with its main
> > > application
> > > and
> > > all other libraries.  Libgcrypt is a library usally linked at
> > > runtime
> > > and thus it would be surprising if it changes such process
> > > properties.
> > > 
> > > 
> > > Salam-Shalom,
> > > 
> > >    Werner
> > > 
> > 
> > _______________________________________________
> > Gcrypt-devel mailing list
> > Gcrypt-devel at gnupg.org
> > https://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> > 
> 
> 


From gniibe at fsij.org  Thu Jun 26 07:10:40 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 26 Jun 2025 14:10:40 +0900
Subject: [PATCH 1/2] tests:common: Increse buffer size to allow input for PQC
 testing.
Message-ID: <b945002e44ce79227599e723fc1faa961494062b.1750914546.git.gniibe@fsij.org>


* tests/t-common.h (read_textline): Increase the buffer size.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 tests/t-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-tests-common-Increse-buffer-size-to-allow-input-for-.patch
Type: text/x-patch
Size: 300 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250626/72a04e0b/attachment.bin>

From jcb62281 at gmail.com  Thu Jun 26 08:00:15 2025
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 26 Jun 2025 01:00:15 -0500
Subject: [PATCH 1/2] tests:common: Increse buffer size to allow input for
 PQC testing.
In-Reply-To: <b945002e44ce79227599e723fc1faa961494062b.1750914546.git.gniibe@fsij.org>
References: <b945002e44ce79227599e723fc1faa961494062b.1750914546.git.gniibe@fsij.org>
Message-ID: <89bfdb3c-3df6-45a7-b67b-acccbd9ecb9e@gmail.com>

On 6/26/25 00:10, NIIBE Yutaka via Gcrypt-devel wrote:
> * tests/t-common.h (read_textline): Increase the buffer size.

I understand that this is testsuite code, so a fixed stack buffer is not 
the serious problem it could otherwise be, but why not replace the fixed 
buffer with a heap-allocated buffer, expanded as needed using 
realloc()?? This would also allow the working buffer to be returned and 
freed by the caller, eliminating the final xstrdup() call.

A quick glance at src/stdmem.c suggests that libgcrypt already has the 
infrastructure to implement this.

I suggest making the buffer expansion power-of-2 starting from some 
initial size (256?) and doubling each time the buffer is filled without 
having read a complete line.? A hard limit (1MiB?) could be useful as well.


-- Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250626/b4697fe5/attachment.html>

From wk at gnupg.org  Thu Jun 26 09:27:26 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jun 2025 09:27:26 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <1750868650.17852.3.camel@trentalancia.com> (Guido Trentalancia's
 message of "Wed, 25 Jun 2025 18:24:10 +0200")
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi>
 <87zfea25do.fsf@gmail.com> <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
 <87pleuxrv0.fsf@jacob.g10code.de>
 <1750702973.6301.12.camel@trentalancia.com>
 <87cyarx0jg.fsf@jacob.g10code.de>
 <1750868650.17852.3.camel@trentalancia.com>
Message-ID: <8734bnvu75.fsf@jacob.g10code.de>

On Wed, 25 Jun 2025 18:24, Guido Trentalancia said:
> There is no profit in changing additional parts of the code, for that
> only overcomplicates the underlying problem and the source code, so
> further changes won't happen.

If you want to get patches upstream you should consider to play by the
rules of the project.  This includes to listen to the discussion.


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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250626/62bc3aca/attachment.sig>

From wk at gnupg.org  Thu Jun 26 09:36:45 2025
From: wk at gnupg.org (Werner Koch)
Date: Thu, 26 Jun 2025 09:36:45 +0200
Subject: [PATCH 1/2] tests:common: Increse buffer size to allow input
 for PQC testing.
In-Reply-To: <89bfdb3c-3df6-45a7-b67b-acccbd9ecb9e@gmail.com> (Jacob Bachmeyer
 via Gcrypt-devel's message of "Thu, 26 Jun 2025 01:00:15 -0500")
References: <b945002e44ce79227599e723fc1faa961494062b.1750914546.git.gniibe@fsij.org>
 <89bfdb3c-3df6-45a7-b67b-acccbd9ecb9e@gmail.com>
Message-ID: <87y0tfuf76.fsf@jacob.g10code.de>

On Thu, 26 Jun 2025 01:00, Jacob Bachmeyer said:

> I suggest making the buffer expansion power-of-2 starting from some
> initial size (256?) and doubling each time the buffer is filled
> without having read a complete line.? A hard limit (1MiB?) could be

If we get such a long line something is wrong with the data.  After all
it should be easily editable by an editor.

In case someone wants to invest the time and regression risk; a switch
to es_read_line might be useful.  Something like

  maxlen = 16384; /* Set limit.  */
  while ((len = es_read_line (fp, &line, &length_of_line, &maxlen)) > 0)
    {
      if (!maxlen)
        {
          err = gpg_error (GPG_ERR_LINE_TOO_LONG);
          goto leave;
        }
      /* Strip newline and carriage return, if present.  */
      while (len > 0 && (line[len - 1] == '\n' || line[len - 1] == '\r'))
	line[--len] = '\0';

      if (split_fields (line, fields, DIM (fields)) < DIM(fields))
        continue; /* Skip empty lines and names w/o a value.  */
      if (*fields[0] == '#')
        continue; /* Skip comments.  */


libgpg-error (aka gpgrt) is anyway required.


Shalom-Salam,

   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: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250626/46cf6cc9/attachment-0001.sig>

From guido at trentalancia.com  Thu Jun 26 14:42:38 2025
From: guido at trentalancia.com (Guido Trentalancia)
Date: Thu, 26 Jun 2025 14:42:38 +0200
Subject: [PATCH libgcrypt] Disable CPU speculation-related misfeatures
In-Reply-To: <8734bnvu75.fsf@jacob.g10code.de>
References: <1748186756.27370.3.camel@trentalancia.com>
 <a7ee31fc-6859-4fca-82f4-5b284693f310@iki.fi> <87zfea25do.fsf@gmail.com>
 <87plevzpnm.fsf@jacob.g10code.de>
 <1750679824.6157.2.camel@trentalancia.com>
 <87pleuxrv0.fsf@jacob.g10code.de>
 <1750702973.6301.12.camel@trentalancia.com>
 <87cyarx0jg.fsf@jacob.g10code.de>
 <1750868650.17852.3.camel@trentalancia.com>
 <8734bnvu75.fsf@jacob.g10code.de>
Message-ID: <1750941758.6481.11.camel@trentalancia.com>

Some changes have been approved, indeed a v2 version of the patch has
been created which fixes a build problem, following advice from Collin
Funk, see:

https://lists.gnupg.org/pipermail/gcrypt-devel/2025-May/005858.html

I do not approve the other proposed changes and the reasons have been
already explained.

In particular I do not approve the creation of autoconf configure tests
or autoconf configure options, because the patch automatically detects
whether or not prctl() is available in glibc and whether or not the
kernel supports disabling those vulnerabilities using prctl().

It has already pointed out that prctl() is available since Linux kernel
2.1.57.

Other changes, such as enabling the code only for cryptographic
algorithms, bring no profit and are not approved, as the performance
loss is only 2.5% as already explained in:

https://lists.gnupg.org/pipermail/gcrypt-devel/2025-June/005867.html

Regards,

Guido

On Thu, 26/06/2025 at 09.27 +0200, Werner Koch wrote:
> On Wed, 25 Jun 2025 18:24, Guido Trentalancia said:
> > There is no profit in changing additional parts of the code, for
> > that
> > only overcomplicates the underlying problem and the source code, so
> > further changes won't happen.
> 
> If you want to get patches upstream you should consider to play by
> the
> rules of the project.  This includes to listen to the discussion.
> 
> 
> Salam-Shalom,
> 
>    Werner
> 


From gniibe at fsij.org  Sat Jun 28 05:44:39 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:39 +0900
Subject: [PATCH 02/17] cipher: Add headers to the Dilithium implementation.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <a7fdda036591dd9022e58b6613e25b23c8d9a50f.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c: Add headers from the reference implementation.

--

Generated the header by:

    for f in fips202.h ntt.h packing.h params.h poly.h polyvec.h \
             randombytes.h reduce.h rounding.h sign.h symmetric.h
      do echo "/*************** dilithium/ref/$f */"
         grep -v NAMESPACE $f | grep -v '^#include'
      done > /tmp/headers

And paste into the file.

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 389 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 389 insertions(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-cipher-Add-headers-to-the-Dilithium-implementation.patch
Type: text/x-patch
Size: 12114 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/840c7c29/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:40 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:40 +0900
Subject: [PATCH 03/17] cipher: Editorial clean up cipher/dilithium.c for
 headers.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <cb15a5563ade6828312311682ddbdc0e5ae1eb6e.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c: Clean up.

--

Manually edit polyvecl_pointwise_acc_montgomery for (no-)namespace.

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 58 ----------------------------------------------
 1 file changed, 58 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-cipher-Editorial-clean-up-cipher-dilithium.c-for-hea.patch
Type: text/x-patch
Size: 4246 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/6ba249d7/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:41 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:41 +0900
Subject: [PATCH 04/17] cipher:dilithium: Export the external API only.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <7bb5d828710461c4a9ee1dcf0e7bd090be6cde55.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c: Don't export other functions.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 140 ++++++++++++++++++++++-----------------------
 1 file changed, 70 insertions(+), 70 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-cipher-dilithium-Export-the-external-API-only.patch
Type: text/x-patch
Size: 10732 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/7817a583/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:44 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:44 +0900
Subject: [PATCH 07/17] cipher:dilithium: Fix comment style.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <caba6463ed257ff8b43827f0b14927e1171ec2ea.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c: Fix comments.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-cipher-dilithium-Fix-comment-style.patch
Type: text/x-patch
Size: 511 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/e5f19daa/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:45 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:45 +0900
Subject: [PATCH 08/17] cipher:dilithium: Functions of poly for different
 DILITHIUM_MODE.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <148a2255b26dc71f081ca110a5e7bf7c40b513c3.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-common.c (decompose): Make it into...
(decompose_88, decompose_32): ... these two functions.
(make_hint): Make it into...
(make_hint_88, make_hint_32): ... these two functions.
(use_hint): Make it into...
(use_hint_88, use_hint_32): ... these two functions.
(poly_decompose): Make it into...
(poly_decompose_88, poly_decompose_32): ... these two functions.
(poly_make_hint): Make it into...
(poly_make_hint_88, poly_make_hint_32): ... these two functions.
(poly_use_hint): Make it into...
(poly_use_hint_88, poly_use_hint_32): ... these two functions.
(rej_eta): Make it into...
(rej_eta_2, rej_eta_4): ... these two functions.
(poly_uniform_eta): Make it into...
(poly_uniform_eta_2, poly_uniform_eta_4): ... these two functions.
(POLY_UNIFORM_ETA_NBLOCKS): Make it into...
(POLY_UNIFORM_ETA_NBLOCKS_2, POLY_UNIFORM_ETA_NBLOCKS_4): ... these
two macros.
(poly_uniform_gamma1): Make it into...
(poly_uniform_gamma1_17, poly_uniform_gamma1_19): ... these two
functions.
(POLY_UNIFORM_GAMMA1_NBLOCKS): Make it into...
(POLY_UNIFORM_GAMMA1_NBLOCKS_17, POLY_UNIFORM_GAMMA1_NBLOCKS_19):
... these two macros.
(polyeta_pack): Make it into...
(polyeta_pack_2, polyeta_pack_4): ... these two functions.
(polyeta_unpack): Make it into...
(polyeta_unpack_2, polyeta_unpack_4): ... these two functions.
(polyz_pack): Make it into...
(polyz_pack_17, polyz_pack_19): ... these two functions.
(polyz_unpack): Make it into...
(polyz_unpack_17, polyz_unpack_19): ... these two functions.
(polyw1_pack): Make it into...
(polyw1_pack_88, polyw1_pack_32): ... these two functions.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-common.c | 371 ++++++++++++++++++++++++++++----------
 1 file changed, 271 insertions(+), 100 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-cipher-dilithium-Functions-of-poly-for-different-DIL.patch
Type: text/x-patch
Size: 21652 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/e3e3d8b7/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:47 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:47 +0900
Subject: [PATCH 10/17] cipher:dilithium: Add DILITHIUM_INTERNAL_API_ONLY.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <3fc2e56dc3eba77b06760963f55e27f6b380b0ed.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-dep.c (crypto_sign_keypair_internal): New.
(crypto_sign_signature) [DILITHIUM_INTERNAL_API_ONLY]: Don't define.
(crypto_sign) [DILITHIUM_INTERNAL_API_ONLY]: Don't define.
(crypto_sign_verify) [DILITHIUM_INTERNAL_API_ONLY]: Don't define.
(crypto_sign_open) [DILITHIUM_INTERNAL_API_ONLY]: Don't define.
* cipher/dilithium.c: Define DILITHIUM_INTERNAL_API_ONLY for use
within libgcrypt.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-dep.c | 60 ++++++++++++++++++++++++++++++++++++++++++
 cipher/dilithium.c     | 24 +++++++++++++++++
 2 files changed, 84 insertions(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0010-cipher-dilithium-Add-DILITHIUM_INTERNAL_API_ONLY.patch
Type: text/x-patch
Size: 5394 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/533f51c8/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:48 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:48 +0900
Subject: [PATCH 11/17] cipher:dilithium: Have cipher/dilithium.h.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <f542ffdda1936a7cacdbb007536e36423293a8ad.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.h: New.
* cipher/dilithium-common.c: Add static qualifier to functions.
* cipher/dilithium-dep.c: Move function delclarations from
dilithium.c and add undef-s.
* cipher/dilithium.c: Support use of DILITHIUM_MODE.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-common.c |  43 +++-
 cipher/dilithium-dep.c    |  76 ++++++
 cipher/dilithium.c        | 473 ++++++++++++++++++++++++++++----------
 cipher/dilithium.h        | 171 ++++++++++++++
 4 files changed, 634 insertions(+), 129 deletions(-)
 create mode 100644 cipher/dilithium.h

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0011-cipher-dilithium-Have-cipher-dilithium.h.patch
Type: text/x-patch
Size: 37140 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/40cb1a09/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:49 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:49 +0900
Subject: [PATCH 12/17] cipher:dilithium: Don't include unused freeze function.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <80bb6f75d719ceb5fca3f7d7c608ec7fddc2d19f.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-common.c (freeze): Remove.
* cipher/dilithium.c (freeze): Remove.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-common.c | 2 ++
 cipher/dilithium.c        | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0012-cipher-dilithium-Don-t-include-unused-freeze-functio.patch
Type: text/x-patch
Size: 788 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/300375c4/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:50 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:50 +0900
Subject: [PATCH 13/17] cipher:dilithium: List the dilithium implementation to
 Makefile.am.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <96220d1217483f275eba215081d4ed9263bf3fc9.1751080340.git.gniibe@fsij.org>


* cipher/Makefile.am (EXTRA_DIST): Add dilithium-common.c and
dilithium-dep.c.
(EXTRA_libcipher_la_SOURCES): Add dilithium.c and dilithium.h.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/Makefile.am | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0013-cipher-dilithium-List-the-dilithium-implementation-t.patch
Type: text/x-patch
Size: 672 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/25d5e6b6/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:51 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:51 +0900
Subject: [PATCH 14/17] cipher:dilithium: Add dilithium functions for libgcrypt
 internal use.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <4331bad92e25c17220eef835c9a5359fe5ada698.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c (dilithium_keypair, dilithium_sign)
(dilithium_verify): New.
* cipher/dilithium.h: Likewise.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 96 ++++++++++++++++++++++++++++++++++++++++++++++
 cipher/dilithium.h | 19 +++++++++
 2 files changed, 115 insertions(+)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0014-cipher-dilithium-Add-dilithium-functions-for-libgcry.patch
Type: text/x-patch
Size: 4309 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/0bfa500e/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:43 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:43 +0900
Subject: [PATCH 06/17] cipher:dilithium: Fix indentation.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <0d03a4cea71e554aba592a5b3298c0f6716401a7.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-dep.c, cipher/dilithium.c: Fic indentation.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-dep.c | 32 ++++++++++++++++----------------
 cipher/dilithium.c     | 20 ++++++++++----------
 2 files changed, 26 insertions(+), 26 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-cipher-dilithium-Fix-indentation.patch
Type: text/x-patch
Size: 5021 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/572b98e7/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:46 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:46 +0900
Subject: [PATCH 09/17] cipher:dilithium: For _GCRYPT_IN_LIBGCRYPT,
 add *_close function.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <479085097a97fc1eb750d65ae4403ae44022c326.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-common.c (poly_uniform): Add stream128_close.
(poly_uniform_eta_2, poly_uniform_eta_4): Add stream256_close.
(poly_uniform_gamma1_17, poly_uniform_gamma1_19): Likewise.
* cipher/dilithium-dep.c (poly_challenge): Add shake256_close.
(crypto_sign_signature_internal): Likewise.
(crypto_sign_verify_internal): Likewise.
* cipher/dilithium.c [_GCRYPT_IN_LIBGCRYPT]: Add glue code
for shake128_* and shake256_*.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-common.c |   5 ++
 cipher/dilithium-dep.c    |   6 ++
 cipher/dilithium.c        | 181 ++++++++++++++++++++++++++++++++++----
 3 files changed, 175 insertions(+), 17 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0009-cipher-dilithium-For-_GCRYPT_IN_LIBGCRYPT-add-_close.patch
Type: text/x-patch
Size: 10804 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/c39ef500/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:53 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:53 +0900
Subject: [PATCH 16/17] cipher:dilithium: Support "no-prefix" flag for
 Dilithium testing.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <24be322f28571145c0497685572a0783de3f9260.1751080340.git.gniibe@fsij.org>


* src/cipher.h (PUBKEY_FLAG_NO_PREFIX): New.
* cipher/pubkey-dilithium.c (mldsa_sign, mldsa_verify): Support
PUBKEY_FLAG_NO_PREFIX.
* cipher/pubkey-util.c (_gcry_pk_util_parse_flaglist): Support
PUBKEY_FLAG_NO_PREFIX.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/pubkey-dilithium.c | 16 ++++++++++++----
 cipher/pubkey-util.c      |  2 ++
 src/cipher.h              |  1 +
 3 files changed, 15 insertions(+), 4 deletions(-)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0016-cipher-dilithium-Support-no-prefix-flag-for-Dilithiu.patch
Type: text/x-patch
Size: 2342 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/f8f9e8bf/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:52 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:52 +0900
Subject: [PATCH 15/17] cipher:dilithium: Add ML-DSA into libgcrypt pubkey
 interface.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <dfb7d8fc720c764cc22b85a13aadff24708d5a74.1751080340.git.gniibe@fsij.org>


* configure.ac (available_pubkey_ciphers): Add dilithium.
(USE_DILITHIUM): New.
* cipher/Makefile.am (EXTRA_libcipher_la_SOURCES): Add
pubkey-dilithium.c.
* cipher/pubkey-dilithium.c: New.
* cipher/pubkey.c (pubkey_list): Add _gcry_pubkey_spec_mldsa.
* src/cipher.h (_gcry_pubkey_spec_mldsa): New.
* src/gcrypt-int.h (enum gcry_mldsa_algos): New.
* src/gcrypt.h.in (GCRY_PK_MLDSA): New.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/Makefile.am        |   2 +-
 cipher/pubkey-dilithium.c | 383 ++++++++++++++++++++++++++++++++++++++
 cipher/pubkey.c           |   3 +
 configure.ac              |  10 +-
 src/cipher.h              |   1 +
 src/gcrypt-int.h          |   7 +
 src/gcrypt.h.in           |   1 +
 7 files changed, 405 insertions(+), 2 deletions(-)
 create mode 100644 cipher/pubkey-dilithium.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0015-cipher-dilithium-Add-ML-DSA-into-libgcrypt-pubkey-in.patch
Type: text/x-patch
Size: 13414 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/dd6274aa/attachment.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:38 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:38 +0900
Subject: [PATCH 01/17] cipher: Put the original Dilithium implementation.
Message-ID: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>


* cipher/dilithium.c: Add the Dilithium reference implementation into
one file.

--

At dilithium/ref directory of the reference implementation,
it is generated by:

    for f in ntt.c packing.c poly.c polyvec.c reduce.c rounding.c \
             sign.c symmetric-shake.c
      do echo "/*************** dilithium/ref/$f */"
      grep -v '^#include' $f
    done > /tmp/dilithium.c

And added the top comment manually.

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium.c | 2264 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 2264 insertions(+)
 create mode 100644 cipher/dilithium.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-cipher-Put-the-original-Dilithium-implementation.patch
Type: text/x-patch
Size: 73904 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/20fe8066/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:42 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:42 +0900
Subject: [PATCH 05/17] cipher:dilithium: Make the implementation into three
 files.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <a1ebc8c7e005b508bfe004d7ad639e382ca6f6a2.1751080340.git.gniibe@fsij.org>


* cipher/dilithium-common.c: New.  Common part.
* cipher/dilithium-dep.c: New.  DILITHIUM_MODE dependent part.
* cipher/dilithium.c: Move functions and variables to two files.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 cipher/dilithium-common.c | 1168 +++++++++++++++++++
 cipher/dilithium-dep.c    | 1228 +++++++++++++++++++
 cipher/dilithium.c        | 2332 +------------------------------------
 3 files changed, 2422 insertions(+), 2306 deletions(-)
 create mode 100644 cipher/dilithium-common.c
 create mode 100644 cipher/dilithium-dep.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-cipher-dilithium-Make-the-implementation-into-three-.patch
Type: text/x-patch
Size: 157833 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/68fe4607/attachment-0001.bin>

From gniibe at fsij.org  Sat Jun 28 05:44:54 2025
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Sat, 28 Jun 2025 12:44:54 +0900
Subject: [PATCH 17/17] tests: Add a test for Dilithium.
In-Reply-To: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
References: <1b422366e2b3b5438713418b50f8a0a1abf8d365.1751080340.git.gniibe@fsij.org>
Message-ID: <93d39c62a1d70b8195d3c83271c6ff2c686ee6ff.1751080340.git.gniibe@fsij.org>


* tests/Makefile.am (tests_bin) [USE_DILITHIUM]: Add t-mldsa.
(EXTRA_DIST): Add t-mldsa.inp.
* tests/t-mldsa.c: New.
* tests/t-mldsa.inp: New.

--

GnuPG-bug-id: 7640
Signed-off-by: NIIBE Yutaka <gniibe at fsij.org>
---
 tests/Makefile.am |   5 +-
 tests/t-mldsa.c   | 702 ++++++++++++++++++++++++++++++++++++++++++++++
 tests/t-mldsa.inp |  71 +++++
 3 files changed, 777 insertions(+), 1 deletion(-)
 create mode 100644 tests/t-mldsa.c
 create mode 100644 tests/t-mldsa.inp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3D"0017-tests-Add-a-test-for-Dilithium.pat=
Type: text/x-patch
Size: 180551 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20250628/3a34ba26/attachment-0001.bin>