From wk at gnupg.org  Tue Apr  2 11:24:16 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 02 Apr 2024 11:24:16 +0200
Subject: Adding ECC KEM
In-Reply-To: <87sf09u8tx.fsf@akagi.fsij.org> (NIIBE Yutaka's message of "Fri, 
 29 Mar 2024 10:26:34 +0900")
References: <871q7vugel.fsf@akagi.fsij.org> <87le62fyn3.fsf@jacob.g10code.de>
 <87sf09u8tx.fsf@akagi.fsij.org>
Message-ID: <87frw4dsn3.fsf@jacob.g10code.de>

On Fri, 29 Mar 2024 10:26, NIIBE Yutaka said:

> While I added the ECC KEM API, I'm not sure if gpg-agent should use the
> ECC KEM API for all of its uses of ECC.

Using that API would make FIPS certification easier, right?


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/20240402/b65dc730/attachment.sig>

From jussi.kivilinna at iki.fi  Tue Apr  2 17:47:56 2024
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 2 Apr 2024 18:47:56 +0300
Subject: Adding ECC KEM
In-Reply-To: <871q7vugel.fsf@akagi.fsij.org>
References: <871q7vugel.fsf@akagi.fsij.org>
Message-ID: <22a1edc5-7ca0-4a51-a22f-018ee11c1661@iki.fi>

Hello,

I noticed that t-kem is currently failing with FIPS mode in master:

t-kem: gcry_kem_keypair 40: Not supported
t-kem: gcry_kem_keypair 41: Not supported
t-kem: gcry_kem_keypair 42: Not supported
t-kem: gcry_kem_keypair 43: Not supported
t-kem: gcry_kem_keypair 44: Not supported
t-kem: gcry_kem_keypair 45: Not supported
t-kem: gcry_kem_keypair 46: Not supported
t-kem: gcry_kem_keypair 47: Not supported
t-kem: gcry_kem_keypair 48: Not supported
t-kem: gcry_kem_keypair 49: Not supported
t-kem: gcry_kem_keypair 50: Not supported
t-kem: gcry_kem_keypair 51: Not supported
t-kem: gcry_kem_keypair 52: Not supported
t-kem: gcry_kem_keypair 53: Not supported
t-kem: gcry_kem_keypair 54: Not supported
t-kem: gcry_kem_keypair 55: Not supported
t-kem: gcry_kem_keypair 56: Not supported
t-kem: gcry_kem_keypair 57: Not supported
t-kem: gcry_kem_keypair 58: Not supported
t-kem: gcry_kem_keypair 59: Not supported
t-kem: gcry_kem_keypair 60: Not supported
t-kem: gcry_kem_keypair 61: Not supported
t-kem: gcry_kem_keypair 62: Not supported
t-kem: gcry_kem_keypair 63: Not supported
t-kem: gcry_kem_keypair 64: Not supported
t-kem: gcry_kem_keypair 65: Not supported
t-kem: gcry_kem_keypair 66: Not supported
t-kem: gcry_kem_keypair 67: Not supported
t-kem: gcry_kem_keypair 68: Not supported
t-kem: gcry_kem_keypair 69: Not supported
t-kem: gcry_kem_keypair 70: Not supported
t-kem: gcry_kem_keypair 71: Not supported
t-kem: gcry_kem_keypair 72: Not supported
t-kem: gcry_kem_keypair 73: Not supported
t-kem: gcry_kem_keypair 74: Not supported
t-kem: gcry_kem_keypair 75: Not supported
t-kem: gcry_kem_keypair 76: Not supported
t-kem: gcry_kem_keypair 77: Not supported
t-kem: gcry_kem_keypair 78: Not supported
t-kem: gcry_kem_keypair 79: Not supported
       80 tests done
FAIL: t-kem

-Jussi

On 28.3.2024 6.30, NIIBE Yutaka wrote:
> Hello,
> 
> In the task T6755, we introduced KEM API.  ML-KEM is added.
> 
> Today, I'd like to propose adding ECC KEM implementation in the API.
> The intention of mine is use in gpg-agent to support PQC (task T7014).
> 
> Attached is a patch adding ECC KEM for X25519.
> 
> 
> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel at gnupg.org
> https://lists.gnupg.org/mailman/listinfo/gcrypt-devel



From gniibe at fsij.org  Wed Apr  3 07:19:11 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 03 Apr 2024 14:19:11 +0900
Subject: Adding ECC KEM
In-Reply-To: <22a1edc5-7ca0-4a51-a22f-018ee11c1661@iki.fi>
References: <871q7vugel.fsf@akagi.fsij.org>
 <22a1edc5-7ca0-4a51-a22f-018ee11c1661@iki.fi>
Message-ID: <87h6gjqb00.fsf@akagi.fsij.org>

Hello,

Let me answer two messages by this reply.

Werner Koch <wk at gnupg.org> wrote:
> Using that API would make FIPS certification easier, right?

Yes.  That's my intention.

I think that KEM API will be added in FIPS 140-* when FIPS 203 (for
ML-KEM) is finalized.


Jussi Kivilinna <jussi.kivilinna at iki.fi> wrote:
> I noticed that t-kem is currently failing with FIPS mode in master:
>
> t-kem: gcry_kem_keypair 40: Not supported

Thank you for your report.

The test program t-kem is not good yet for FIPS support.  Since KEM API
is not included in FIPS 140-* yet, all tests should be failed and the
tests should handle the failure as expected.  Currently, ECC KEM with
X25519 fails because Curve25519 is defined with "fips" field = 0 (in
libgcrypt/cipher/ecc-curves.c).

In (near) future, KEM API itself should have check for FIPS.
-- 


From wk at gnupg.org  Fri Apr  5 16:35:51 2024
From: wk at gnupg.org (Werner Koch)
Date: Fri, 05 Apr 2024 16:35:51 +0200
Subject: Adding ECC KEM
In-Reply-To: <87sf09u8tx.fsf@akagi.fsij.org> (NIIBE Yutaka's message of "Fri, 
 29 Mar 2024 10:26:34 +0900")
References: <871q7vugel.fsf@akagi.fsij.org> <87le62fyn3.fsf@jacob.g10code.de>
 <87sf09u8tx.fsf@akagi.fsij.org>
Message-ID: <878r1rc1x4.fsf@jacob.g10code.de>

Hi!

I recently introduced the GCRY_PK_KEM algo which I marked as pseudo
algorithms.  Right now we use a 3 Kyber variants and sntrup761 under
this label.  This would we similar to GCRY_PK_ECC and hthe use of named
curves to identify which algorithm is actually used.  Shall we take this
path and if so, what shall we do with ECDH?  ECDH is a pure ECC
algorithm and does not really fit as a KEM algorithm because we would
need to list all supported curves also there.  Or should we add some
common curves also under the KEM label and thus provide a second
interface for tehse curves?

On Fri, 29 Mar 2024 10:26, NIIBE Yutaka said:

> Possibly, ECC KEM API will be only used for PQC.  In this case,
> gpg-agent uses gcry_kem_* API for PQC hybrid, and keeps using gcry_pk_*
> API for existing non-hybrid use of ECC.

Okay for GnuPG.  But is this also good for other applications?


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/20240405/1e3f2a7d/attachment-0001.sig>

From gniibe at fsij.org  Mon Apr  8 07:09:01 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 08 Apr 2024 14:09:01 +0900
Subject: Adding ECC KEM
In-Reply-To: <878r1rc1x4.fsf@jacob.g10code.de>
References: <871q7vugel.fsf@akagi.fsij.org>
 <87le62fyn3.fsf@jacob.g10code.de> <87sf09u8tx.fsf@akagi.fsij.org>
 <878r1rc1x4.fsf@jacob.g10code.de>
Message-ID: <87jzl8xwya.fsf@akagi.fsij.org>

Werner Koch <wk at gnupg.org> wrote:
> I recently introduced the GCRY_PK_KEM algo which I marked as pseudo
> algorithms.  Right now we use a 3 Kyber variants and sntrup761 under
> this label.

I observed that.  My understanding is that it's needed to support
keygrip for those keys.

> This would we similar to GCRY_PK_ECC and hthe use of named
> curves to identify which algorithm is actually used.  Shall we take this
> path and if so, what shall we do with ECDH?  ECDH is a pure ECC
> algorithm and does not really fit as a KEM algorithm because we would
> need to list all supported curves also there.  Or should we add some
> common curves also under the KEM label and thus provide a second
> interface for tehse curves?

# For the term, I use "composite" KEM (instead of "hybrid"), because of
# avoiding confusion of terms in "hybrid" in DHKEM.

AFAIK, in other areas (than GnuPG), I don't see any changes of practice
for existing ECC computation yet (for example, migration of API).  It
seems for me that (except DHKEM) it's only in the context of composite
KEM where ECC KEM is used.

So, I think that GCRY_KEM_RAW_X25519 for composite KEM is actually
useful for now.

GCRY_KEM_DHKEM25519 is worth to have in libgcrypt, possibly, if there
will be use cases.

These are experimental, mainly for GnuPG experiment of mine:

    GCRY_KEM_OPENPGP_X25519
    GCRY_KEM_CMS_X25519_X963_SHA256
    GCRY_KEM_CMS_X25519_HKDF_SHA256

Current approach of mine (for T7014) is that: let us keep using existing
ECC (as long as it works well) with existing key format.  Here, keygrip
for the ECC key is computed by the existing public key API
(gcy_pk_get_keygrip with name of the curve in SEXP), not introducing new
ones.

In other words, an ECC key can be used for both of:

    gcry_pk_encrypt and gcry_pk_decrypt API (with _gcry_pubkey_spec_ecc)
    gcry_kem_* API

while keygrip is computed by gcy_pk_get_keygrip.

Firstly, let us extend the KEM API by adding GCRY_KEM_RAW_<CURVENAME>.
This is for API for pure ECDH, and it is intended for composite KEM.
KDF should be implemented by application code.
-- 


From gniibe at fsij.org  Wed Apr 17 03:24:35 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 17 Apr 2024 10:24:35 +0900
Subject: [PATCH] cipher: Add Classic McEliece mceliece6688128f.
In-Reply-To: <87le86g6ua.fsf@jacob.g10code.de>
References: <87wmrr9nz0.fsf@kaka.sjd.se> <87le86g6ua.fsf@jacob.g10code.de>
Message-ID: <871q746ass.fsf@akagi.fsij.org>

Hello,

Let us apply the patch of Classic McEliece mceliece6688128f.

(Personally, I need to do this before adding more curves to ECC KEM.)

On Tue, 30 Jan 2024 10:20 +0100, Simon Josefsson wrote:
> This patch adds Classic McEliece mceliece6688128f based on the public
> domain libmceliece code.  What do you think?

On Tue, 30 Jan 2024 16:48 +0100, Werner Koch wrote:
> Seems people want that.

Indeed.  It's good to have different one other than lattice based.

> - I think the name is too long, we should find an abbreviation.
> - C++ comments neeed to be remoced
> - __attribute__ need to be removed or replaced by GGPRT macros.
> - Probably other cleanups.

Let me do these changes after the first push of the patch.

Is there any good shorter name, or an abbreviation?  Libgcrypt tries to
support building by older C compilers (< C99) for older systems.  Older
compiler needs shorter name.
-- 


From simon at josefsson.org  Wed Apr 17 11:57:43 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 17 Apr 2024 11:57:43 +0200
Subject: [PATCH] cipher: Add Classic McEliece mceliece6688128f.
In-Reply-To: <871q746ass.fsf@akagi.fsij.org> (NIIBE Yutaka's message of "Wed, 
 17 Apr 2024 10:24:35 +0900")
References: <87wmrr9nz0.fsf@kaka.sjd.se> <87le86g6ua.fsf@jacob.g10code.de>
 <871q746ass.fsf@akagi.fsij.org>
Message-ID: <87o7a8qpk8.fsf@kaka.sjd.se>

NIIBE Yutaka <gniibe at fsij.org> writes:

> Hello,
>
> Let us apply the patch of Classic McEliece mceliece6688128f.

Thank you.

> (Personally, I need to do this before adding more curves to ECC KEM.)
>
> On Tue, 30 Jan 2024 10:20 +0100, Simon Josefsson wrote:
>> This patch adds Classic McEliece mceliece6688128f based on the public
>> domain libmceliece code.  What do you think?
>
> On Tue, 30 Jan 2024 16:48 +0100, Werner Koch wrote:
>> Seems people want that.
>
> Indeed.  It's good to have different one other than lattice based.
>
>> - I think the name is too long, we should find an abbreviation.
>> - C++ comments neeed to be remoced
>> - __attribute__ need to be removed or replaced by GGPRT macros.
>> - Probably other cleanups.
>
> Let me do these changes after the first push of the patch.
>
> Is there any good shorter name, or an abbreviation?  Libgcrypt tries to
> support building by older C compilers (< C99) for older systems.  Older
> compiler needs shorter name.

Classic McEliece is abbreviated 'CM' in its specification document, so
s/MCELIECE6688128/CM6688128/g' is one approach.

Are pre-C99 compilers supported for real, or is this merely an obsolete
desired feature?  Do you have any example of a pre-C99 compiler that can
build libgcrypt?  I recall trying to get libgcrypt to build with tcc
long time ago and failed.

I think the names aren't unreasonable long, and if someone wants support
a pre-C99 compiler that can be achieved with a conditional #define
GCRY_KEM_MCELIECE6688128F GCRY_KEM_CM6688128F', couldn't it?  But maybe
not worry about it until there is a known real use-case.

/Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20240417/0c759b4e/attachment.sig>

From wk at gnupg.org  Thu Apr 18 12:04:04 2024
From: wk at gnupg.org (Werner Koch)
Date: Thu, 18 Apr 2024 12:04:04 +0200
Subject: [PATCH] cipher: Add Classic McEliece mceliece6688128f.
In-Reply-To: <87o7a8qpk8.fsf@kaka.sjd.se> (Simon Josefsson's message of "Wed, 
 17 Apr 2024 11:57:43 +0200")
References: <87wmrr9nz0.fsf@kaka.sjd.se> <87le86g6ua.fsf@jacob.g10code.de>
 <871q746ass.fsf@akagi.fsij.org> <87o7a8qpk8.fsf@kaka.sjd.se>
Message-ID: <87il0fj8bv.fsf@jacob.g10code.de>

Hi!

On Wed, 17 Apr 2024 11:57, Simon Josefsson said:

> Classic McEliece is abbreviated 'CM' in its specification document, so
> s/MCELIECE6688128/CM6688128/g' is one approach.

Good idea.  I prefer easy to type names and the 6688128 is already long
enough ;-).

> Are pre-C99 compilers supported for real, or is this merely an obsolete
> desired feature?  Do you have any example of a pre-C99 compiler that can

No, it is not obsolete and forces us to keep the code readable.  It is
hard to test these days but things should be limited to what is really
needed.  The __func__ macro and the __VA_ARGS__ are so useful that we
should allow them.  But struct initializers and trailing commas are
problematic (older but still used AIX and HPUX compilers).  //-comments
are a severe aesthetic annoyance.

> build libgcrypt?  I recall trying to get libgcrypt to build with tcc
> long time ago and failed.

Charles H. Beebe used to test on all kinds of Unices.


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/20240418/1e7b4e7b/attachment.sig>

From jcb62281 at gmail.com  Fri Apr 19 04:10:37 2024
From: jcb62281 at gmail.com (Jacob Bachmeyer)
Date: Thu, 18 Apr 2024 21:10:37 -0500
Subject: trailing comma compiler suuport (was: [PATCH] cipher: Add Classic
 McEliece mceliece6688128f.)
In-Reply-To: <87il0fj8bv.fsf@jacob.g10code.de>
References: <87wmrr9nz0.fsf@kaka.sjd.se> <87le86g6ua.fsf@jacob.g10code.de>
 <871q746ass.fsf@akagi.fsij.org> <87o7a8qpk8.fsf@kaka.sjd.se>
 <87il0fj8bv.fsf@jacob.g10code.de>
Message-ID: <6621D29D.6000303@gmail.com>

Werner Koch via Gcrypt-devel wrote:
> Hi!
>
> On Wed, 17 Apr 2024 11:57, Simon Josefsson said:
> [...]
>> Are pre-C99 compilers supported for real, or is this merely an obsolete
>> desired feature?  Do you have any example of a pre-C99 compiler that can
>>     
>
> [...]  But struct initializers and trailing commas are
> problematic (older but still used AIX and HPUX compilers).

Wait... I thought trailing commas in initializer lists had always been 
allowed, since the original K&R C, in order to facilitate tools that 
generate C code.  Is this incorrect or are those compilers outliers?  
(To be fair, this is history for me---when C89 was published, I was not 
old enough to type.)


-- Jacob


From wk at gnupg.org  Sat Apr 20 14:15:18 2024
From: wk at gnupg.org (Werner Koch)
Date: Sat, 20 Apr 2024 14:15:18 +0200
Subject: trailing comma compiler suuport
In-Reply-To: <6621D29D.6000303@gmail.com> (Jacob Bachmeyer via Gcrypt-devel's
 message of "Thu, 18 Apr 2024 21:10:37 -0500")
References: <87wmrr9nz0.fsf@kaka.sjd.se> <87le86g6ua.fsf@jacob.g10code.de>
 <871q746ass.fsf@akagi.fsij.org> <87o7a8qpk8.fsf@kaka.sjd.se>
 <87il0fj8bv.fsf@jacob.g10code.de> <6621D29D.6000303@gmail.com>
Message-ID: <87v84ci621.fsf@jacob.g10code.de>

On Thu, 18 Apr 2024 21:10, Jacob Bachmeyer said:

> Wait... I thought trailing commas in initializer lists had always been
> allowed, since the original K&R C, in order to facilitate tools that
> generate C code.  Is this incorrect or are those compilers outliers?

I always had this issue with HP compilers and some other compilers also
complain/warn about it.  IIRC, even the crippled K&R cc installed by
default on HPUX, which you need to bootstrap gcc, has this problem.  We
should find not too old reports in the bug tracker.


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/20240420/b4ea679f/attachment.sig>

From jussi.kivilinna at iki.fi  Tue Apr 30 21:23:58 2024
From: jussi.kivilinna at iki.fi (Jussi Kivilinna)
Date: Tue, 30 Apr 2024 22:23:58 +0300
Subject: [PATCH] serpent-avx512-x86: fix CBC and CFB decryption with clang-18
Message-ID: <20240430192358.2479396-1-jussi.kivilinna@iki.fi>

* cipher/serpent-avx512-x86.c (serpent_avx512_blk32): Avoid
'_mm512_castsi128_si512' usage to prevent non-initialized
vector register parts getting XOR into calculations for
CBC and CFB decryption.
--

Signed-off-by: Jussi Kivilinna <jussi.kivilinna at iki.fi>
---
 cipher/serpent-avx512-x86.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/cipher/serpent-avx512-x86.c b/cipher/serpent-avx512-x86.c
index 762c09e1..5b5c2483 100644
--- a/cipher/serpent-avx512-x86.c
+++ b/cipher/serpent-avx512-x86.c
@@ -758,10 +758,10 @@ serpent_avx512_blk32(const void *c, unsigned char *output,
 
       case CFB_DEC:
       {
-	__m128i viv = _mm_loadu_si128((const void *)iv);
+	__m128i viv;
 	vin[0] = _mm512_maskz_loadu_epi32(_cvtu32_mask16(0xfff0),
 					  input - 1 * 64 + 48)
-		  ^ _mm512_castsi128_si512(viv);
+		  ^ _mm512_maskz_loadu_epi32(_cvtu32_mask16(0x000f), iv);
 	vin[1] = _mm512_loadu_epi32(input + 0 * 64 + 48);
 	vin[2] = _mm512_loadu_epi32(input + 1 * 64 + 48);
 	vin[3] = _mm512_loadu_epi32(input + 2 * 64 + 48);
@@ -852,10 +852,10 @@ serpent_avx512_blk32(const void *c, unsigned char *output,
 
       case CBC_DEC:
       {
-	__m128i viv = _mm_loadu_si128((const void *)iv);
+	__m128i viv;
 	vout[0] ^= _mm512_maskz_loadu_epi32(_cvtu32_mask16(0xfff0),
 					    input - 1 * 64 + 48)
-		    ^ _mm512_castsi128_si512(viv);
+		    ^ _mm512_maskz_loadu_epi32(_cvtu32_mask16(0x000f), iv);
 	vout[1] ^= _mm512_loadu_epi32(input + 0 * 64 + 48);
 	vout[2] ^= _mm512_loadu_epi32(input + 1 * 64 + 48);
 	vout[3] ^= _mm512_loadu_epi32(input + 2 * 64 + 48);
-- 
2.43.0