From gniibe at fsij.org  Thu Dec  5 08:11:14 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 05 Dec 2024 16:11:14 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87mshm4m06.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
Message-ID: <875xny8uzx.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Here are ongoing changes:
>
> * Change 1: use of a new internal API for the FIPS service indicator.
>   Current proposal is using thread local storage, with compiler support
>   (__thread), to be conservative (not by modern C11 _Thread_local or C23
>   thread_local).
>
> * Change 2: new libgcrypt API for the FIPS service indicator (by macro
>   and gcry_control with new number), for applications.

These parts are pushed to master.

Also, for gcry_kdf_derive function, following was done.

> * Change 3: using the new internal API, modify libgcrypt; put
>   initialization (of false), put update (of true) in a success path, for
>   all relevant functions.
>
> * Change 4 (possibly, some parts would be optional): modify libgcrypt so
>   that it doesn't reject computation under FIPS mode for parameters, but
>   continue to finish the computation.  After this change, it won't
>   return an error for parameters issue (if it's not fatal), only setting
>   a failure with the FIPS service indicator.

It's tracked by:

   https://dev.gnupg.org/T7338

I'm going to try #3 and #4 for gcry_md_buffer function.
-- 


From simon at josefsson.org  Thu Dec  5 13:47:47 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 05 Dec 2024 13:47:47 +0100
Subject: Classic McEliece on arch which doesn't like unaligned access
In-Reply-To: <878qxbo38e.fsf@kaka.sjd.se> (Simon Josefsson via Gcrypt-devel's
 message of "Mon, 05 Aug 2024 09:09:21 +0200")
References: <87jzk69xrd.fsf@akagi.fsij.org> <87wmo5pc7m.fsf@kaka.sjd.se>
 <878qxbo38e.fsf@kaka.sjd.se>
Message-ID: <878qsuthxo.fsf@kaka.sjd.se>

Hi.  Just a gentle ping on this patch, it seems to still apply cleanly
to master.  Do you have any concerns over this?  It paves the road for
making further fixes that are aligned with the external code.

/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/20241205/3c9f6ed1/attachment.sig>

From gmazyland at gmail.com  Tue Dec 10 13:53:11 2024
From: gmazyland at gmail.com (Milan Broz)
Date: Tue, 10 Dec 2024 13:53:11 +0100
Subject: [PATCH] kdf: Fix memory cost overflow in Argon2 KDF
Message-ID: <20241210125325.249032-1-gmazyland@gmail.com>

* cipher/kdf.c (argon2_init) Fix memory cost overflow in Argon2 KDF.
--

Argon2 memory cost is set kilobytes, so for memory allocation
it must be converted to bytes (multiplied by 1024).

This patch fixes integer overflow for 64bit platforms, so more than
4GB of memory can be allocated.

For 32bit platforms (where size_t is 32bit) it cannot allocate
such amount of memory, so the code tries to detect the issue early
before overflow.

The issue can be easily reproduced with Argon2 mcost set to:
  m_cost = 4194304 (= 4 * 1024 * 1024, set in param[2])

Originally reported for cryptsetup with libgcrypt backend
https://gitlab.com/cryptsetup/cryptsetup/-/issues/922

Signed-off-by: Milan Broz <gmazyland at gmail.com>
---
 cipher/kdf.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/cipher/kdf.c b/cipher/kdf.c
index 52e6a9ba..1771bac4 100644
--- a/cipher/kdf.c
+++ b/cipher/kdf.c
@@ -494,6 +494,7 @@ argon2_init (argon2_ctx_t a, unsigned int parallelism,
 {
   gpg_err_code_t ec = 0;
   unsigned int memory_blocks;
+  size_t memory_bytes;
   unsigned int segment_length;
   void *block;
   struct argon2_thread_data *thread_data;
@@ -514,13 +515,17 @@ argon2_init (argon2_ctx_t a, unsigned int parallelism,
   a->block = NULL;
   a->thread_data = NULL;
 
-  block = xtrymalloc (1024 * memory_blocks);
+  if (1024ULL * memory_blocks > SIZE_MAX)
+    return GPG_ERR_INV_VALUE;
+
+  memory_bytes = 1024 * (size_t)memory_blocks;
+  block = xtrymalloc (memory_bytes);
   if (!block)
     {
       ec = gpg_err_code_from_errno (errno);
       return ec;
     }
-  memset (block, 0, 1024 * memory_blocks);
+  memset (block, 0, memory_bytes);
 
   thread_data = xtrymalloc (a->lanes * sizeof (struct argon2_thread_data));
   if (!thread_data)
@@ -873,6 +878,9 @@ argon2_open (gcry_kdf_hd_t *hd, int subalgo,
   if (parallelism == 0)
     return GPG_ERR_INV_VALUE;
 
+  if (1024ULL * m_cost > SIZE_MAX)
+    return GPG_ERR_INV_VALUE;
+
   n = offsetof (struct argon2_context, out) + taglen;
   a = xtrymalloc (n);
   if (!a)
-- 
2.45.2



From wk at gnupg.org  Tue Dec 10 18:01:53 2024
From: wk at gnupg.org (Werner Koch)
Date: Tue, 10 Dec 2024 18:01:53 +0100
Subject: [PATCH] kdf: Fix memory cost overflow in Argon2 KDF
In-Reply-To: <20241210125325.249032-1-gmazyland@gmail.com> (Milan Broz via
 Gcrypt-devel's message of "Tue, 10 Dec 2024 13:53:11 +0100")
References: <20241210125325.249032-1-gmazyland@gmail.com>
Message-ID: <87jzc7xyim.fsf@jacob.g10code.de>

On Tue, 10 Dec 2024 13:53, Milan Broz said:

> +  if (1024ULL * memory_blocks > SIZE_MAX)

I am not sure whether unsigned long long is available on all platforms
supported by Libgcrypt.  Using u64 is probably a better way.  See
src/types.h


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/20241210/e330ffdb/attachment-0001.sig>

From gmazyland at gmail.com  Tue Dec 10 19:49:35 2024
From: gmazyland at gmail.com (Milan Broz)
Date: Tue, 10 Dec 2024 19:49:35 +0100
Subject: [PATCH v2] kdf: Fix memory cost overflow in Argon2 KDF
In-Reply-To: <87jzc7xyim.fsf@jacob.g10code.de>
References: <87jzc7xyim.fsf@jacob.g10code.de>
Message-ID: <20241210185018.20349-1-gmazyland@gmail.com>

* cipher/kdf.c (argon2_init) Fix memory cost overflow in Argon2 KDF.
--

Argon2 memory cost is set kilobytes, so for memory allocation
it must be converted to bytes (multiplied by 1024).

This patch fixes integer overflow for 64bit platforms, so more than
4GB of memory can be allocated.

For 32bit platforms (where size_t is 32bit) it cannot allocate
such amount of memory, so the code tries to detect the issue early
before overflow.

The issue can be easily reproduced with Argon2 mcost set to:
  m_cost = 4194304 (= 4 * 1024 * 1024, set in param[2])

Originally reported for cryptsetup with libgcrypt backend
https://gitlab.com/cryptsetup/cryptsetup/-/issues/922

Signed-off-by: Milan Broz <gmazyland at gmail.com>
---
 cipher/kdf.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/cipher/kdf.c b/cipher/kdf.c
index 52e6a9ba..1eae2b90 100644
--- a/cipher/kdf.c
+++ b/cipher/kdf.c
@@ -494,6 +494,7 @@ argon2_init (argon2_ctx_t a, unsigned int parallelism,
 {
   gpg_err_code_t ec = 0;
   unsigned int memory_blocks;
+  size_t memory_bytes;
   unsigned int segment_length;
   void *block;
   struct argon2_thread_data *thread_data;
@@ -514,13 +515,17 @@ argon2_init (argon2_ctx_t a, unsigned int parallelism,
   a->block = NULL;
   a->thread_data = NULL;
 
-  block = xtrymalloc (1024 * memory_blocks);
+  if (U64_C(1024) * memory_blocks > SIZE_MAX)
+    return GPG_ERR_INV_VALUE;
+
+  memory_bytes = 1024 * (size_t)memory_blocks;
+  block = xtrymalloc (memory_bytes);
   if (!block)
     {
       ec = gpg_err_code_from_errno (errno);
       return ec;
     }
-  memset (block, 0, 1024 * memory_blocks);
+  memset (block, 0, memory_bytes);
 
   thread_data = xtrymalloc (a->lanes * sizeof (struct argon2_thread_data));
   if (!thread_data)
@@ -873,6 +878,9 @@ argon2_open (gcry_kdf_hd_t *hd, int subalgo,
   if (parallelism == 0)
     return GPG_ERR_INV_VALUE;
 
+  if (U64_C(1024) * m_cost > SIZE_MAX)
+    return GPG_ERR_INV_VALUE;
+
   n = offsetof (struct argon2_context, out) + taglen;
   a = xtrymalloc (n);
   if (!a)
-- 
2.45.2



From gniibe at fsij.org  Wed Dec 11 08:23:25 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 11 Dec 2024 16:23:25 +0900
Subject: [PATCH v2] kdf: Fix memory cost overflow in Argon2 KDF
In-Reply-To: <20241210185018.20349-1-gmazyland@gmail.com>
References: <87jzc7xyim.fsf@jacob.g10code.de>
 <20241210185018.20349-1-gmazyland@gmail.com>
Message-ID: <874j3an0nm.fsf@akagi.fsij.org>

Milan Broz wrote:
> * cipher/kdf.c (argon2_init) Fix memory cost overflow in Argon2 KDF.

Thank you.  Applied to master.
-- 


From kamlesh0hrs at gmail.com  Wed Dec 11 19:09:25 2024
From: kamlesh0hrs at gmail.com (Kamlesh Kumar)
Date: Wed, 11 Dec 2024 23:39:25 +0530
Subject: ml-dsa (Dilithium) support in libgcrypt
Message-ID: <CAPLSBBC6d0AdKtchyY9Bpp1OLHvei4HR9kh5DCET-m_qEG=UCw@mail.gmail.com>

Hi Team,

I saw an old thread where it was mentioned that libgcrypt will have support
of ml-dsa.
https://lists.gnupg.org/pipermail/gcrypt-devel/2023-October/005572.html
<https://lists.gnupg.org/pipermail/gcrypt-devel/2023-October/005572.html>

I dont see it in the master branch yet. By any chance we are planning to
support it ?

Thanks & Regards,
Kamlesh Kumar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241211/51b3e3eb/attachment.html>

From gniibe at fsij.org  Thu Dec 12 06:42:00 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 12 Dec 2024 14:42:00 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <875xny8uzx.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org>
Message-ID: <875xnp5ufr.fsf@akagi.fsij.org>

Hello, again,

I think that the behavior changes will be inevitably introduced, with
the FIPS 140 service indicator revamp.  Under the FIPS mode, currently,
(in many cases,) it rejects computation in existing code of libgcrypt.
After the revamp, libgcrypt API won't reject the computation, but a
FIPS-conscious application needs to check if it's compliant or not
(using gcry_get_fips_service_indicator macro).

Perhaps, we need to introduce compatible flag to keep old behavior for
an application expecting rejection.

NIIBE Yutaka <gniibe at fsij.org> wrote:
> I'm going to try #3 and #4 for gcry_md_buffer function.

This was done by the commit to master:

	3478caac62c712547f7c0e07f4cf9602bc317997

Then, I proceed to modifying a set of functions which starts with
gcry_md_open.

Modifying those, I realized that the approach with the internal API of

	fips_service_indicator
	fips_service_indicator_mark_sucess

doesn't work well.  That's because there may be multiple components
involved.  For example, external API gcry_pk_* function may call
internal _gcry_md_* functions.  External API gcry_mac_* function may
call internal _gcry_cipher_* functions, and/or _gcry_md_* functions.
Here, all calls should be compliant, not only one.  When there are
multiple calls, a single path including mark_sucess doesn't mean it's
compliant.

Because of this, I'd like to propose a different apporach with:

	fips_service_indicator
	fips_service_indicator_mark_non_compliant

That is, initially, it assumes it's compliant and when anything
non-compliant computation involved, it marks non-compliant.  In the
existing code of libgcrypt, it tries to reject non-compliant computation
actually, so, this approach matches well to the existing code.

Well, evaluating correctness with mark_success would be easier but this
approach limited to simple functions.


Attached are two patches.  One for the internal API change.  Another for
modifying a set of functions which starts with gcry_md_open.  An
application which expects rejection can use the
GCRY_MD_FLAG_REJECT_NON_FIPS with gcry_md_open.


It's tracked by:

    https://dev.gnupg.org/T7338
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fips-Change-the-internal-API-for-new-FIPS-service-in.patch
Type: text/x-diff
Size: 4519 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241212/8480d61b/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-fips-md-Implement-new-FIPS-service-indicator-for-gcr.patch
Type: text/x-diff
Size: 10058 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241212/8480d61b/attachment-0003.patch>

From gniibe at fsij.org  Thu Dec 12 07:11:02 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 12 Dec 2024 15:11:02 +0900
Subject: Classic McEliece on arch which doesn't like unaligned access
In-Reply-To: <878qsuthxo.fsf@kaka.sjd.se>
References: <87jzk69xrd.fsf@akagi.fsij.org> <87wmo5pc7m.fsf@kaka.sjd.se>
 <878qxbo38e.fsf@kaka.sjd.se> <878qsuthxo.fsf@kaka.sjd.se>
Message-ID: <8734it5t3d.fsf@akagi.fsij.org>

Hello,

Sorry, it was forgotten by me in the hottest summer.

Simon Josefsson wrote:
> Just a gentle ping on this patch, it seems to still apply cleanly
> to master.

Applied and pushed.  Please go ahead for the update (which hopefully
fixes the original unaligned problem).
-- 


From simon at josefsson.org  Thu Dec 12 09:20:46 2024
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 12 Dec 2024 09:20:46 +0100
Subject: Classic McEliece on arch which doesn't like unaligned access
In-Reply-To: <8734it5t3d.fsf@akagi.fsij.org> (NIIBE Yutaka via Gcrypt-devel's
 message of "Thu, 12 Dec 2024 15:11:02 +0900")
References: <87jzk69xrd.fsf@akagi.fsij.org> <87wmo5pc7m.fsf@kaka.sjd.se>
 <878qxbo38e.fsf@kaka.sjd.se> <878qsuthxo.fsf@kaka.sjd.se>
 <8734it5t3d.fsf@akagi.fsij.org>
Message-ID: <87pllx8g81.fsf@kaka.sjd.se>

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

> Hello,
>
> Sorry, it was forgotten by me in the hottest summer.
>
> Simon Josefsson wrote:
>> Just a gentle ping on this patch, it seems to still apply cleanly
>> to master.
>
> Applied and pushed.  Please go ahead for the update (which hopefully
> fixes the original unaligned problem).

Thank you!  I will resumse work on that.  Alas, it seems upstream has
evolved quite a lot and added some things that are more difficult to
back-port, but I recall that the alignment problem was relatively small.
Still, it is best to start from verbatim upstream sources and apply
libgcrypt-specific patches via the import-script like we do in git now.

/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/20241212/d3989016/attachment.sig>

From gniibe at fsij.org  Mon Dec 16 02:27:12 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Mon, 16 Dec 2024 10:27:12 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <875xnp5ufr.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
Message-ID: <87wmg0l8nj.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Attached are two patches.  One for the internal API change.  Another for
> modifying a set of functions which starts with gcry_md_open.  An
> application which expects rejection can use the
> GCRY_MD_FLAG_REJECT_NON_FIPS with gcry_md_open.

Another patch adding tests for gcry_md_open API.

After pushing those changes, I'll continue on gcry_mac_open
and gcry_cipher_open API.

-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-fips-tests-Add-tests-for-md_open-write-read-close-fo.patch
Type: text/x-diff
Size: 5817 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241216/02a199b6/attachment.patch>

From gniibe at fsij.org  Tue Dec 17 05:51:58 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Tue, 17 Dec 2024 13:51:58 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87wmg0l8nj.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
 <87wmg0l8nj.fsf@akagi.fsij.org>
Message-ID: <87wmfy6he9.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> I'll continue on gcry_mac_open and gcry_cipher_open API.

Here are the patches for those API.

I'll add tests and continue on gcry_pk_hash_* functions.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-fips-mac-Implement-new-FIPS-service-indicator-for-gc.patch
Type: text/x-diff
Size: 3776 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241217/11aa6486/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-fips-cipher-Implement-new-FIPS-service-indicator-for.patch
Type: text/x-diff
Size: 4026 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241217/11aa6486/attachment-0001.patch>

From gniibe at fsij.org  Wed Dec 18 06:57:20 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 18 Dec 2024 14:57:20 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87wmfy6he9.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
 <87wmg0l8nj.fsf@akagi.fsij.org> <87wmfy6he9.fsf@akagi.fsij.org>
Message-ID: <87ed25fs8v.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> continue on gcry_pk_hash_* functions.

Here are changes for gcry_pk_hash_* functions.

This change includes stop rejecting non-compliant cases.

With LIBGCRYPT_FORCE_FIPS_MODE=true, "make check" result 7 failures.

FAIL: basic
FAIL: t-kem
FAIL: dsa-rfc6979
FAIL: curves
FAIL: t-cv25519
FAIL: t-x448
FAIL: basic-disable-all-hwf

Perhaps, to keep old behavior, we would introduce

	GCRYCTL_FIPS_NO_REJECTION

for a thread (of new code) which wants no-rejection behavior.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fips-md-gcry_md_copy-should-care-about-FIPS-service-.patch
Type: text/x-diff
Size: 2168 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241218/dd514e27/attachment-0002.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-fips-cipher-Implement-FIPS-service-indicator-for-gcr.patch
Type: text/x-diff
Size: 12035 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241218/dd514e27/attachment-0003.patch>

From gniibe at fsij.org  Thu Dec 19 03:39:38 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 19 Dec 2024 11:39:38 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87ed25fs8v.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
 <87wmg0l8nj.fsf@akagi.fsij.org> <87wmfy6he9.fsf@akagi.fsij.org>
 <87ed25fs8v.fsf@akagi.fsij.org>
Message-ID: <87a5cs8kgl.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Here are changes for gcry_pk_hash_* functions.
>
> This change includes stop rejecting non-compliant cases.
>
> With LIBGCRYPT_FORCE_FIPS_MODE=true, "make check" result 7 failures.
>
> FAIL: basic
> FAIL: t-kem
> FAIL: dsa-rfc6979
> FAIL: curves
> FAIL: t-cv25519
> FAIL: t-x448
> FAIL: basic-disable-all-hwf

To support old behavior, I introduced GCRYCTL_FIPS_REJECT_NON_FIPS.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-fips-Introduce-GCRYCTL_FIPS_REJECT_NON_FIPS.patch
Type: text/x-diff
Size: 8997 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241219/cc841e45/attachment.patch>

From gniibe at fsij.org  Fri Dec 20 02:49:33 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 20 Dec 2024 10:49:33 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87a5cs8kgl.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
 <87wmg0l8nj.fsf@akagi.fsij.org> <87wmfy6he9.fsf@akagi.fsij.org>
 <87ed25fs8v.fsf@akagi.fsij.org> <87a5cs8kgl.fsf@akagi.fsij.org>
Message-ID: <87seqjktsi.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> To support old behavior, I introduced GCRYCTL_FIPS_REJECT_NON_FIPS.

The expression "old" is not good.  It's the behavior of libgcrypt 1.10
(and older).

Here is another patch to prefer GCRYCTL_FIPS_REJECT_NON_FIPS, removing
GCRY_CIPHER_FLAG_REJECT_NON_FIPS, GCRY_MD_FLAG_REJECT_NON_FIPS, and
GCRY_MAC_FLAG_REJECT_NON_FIPS in master.

I'm going to push those changes to master.

Then, I'll work on other gcry_pk_* API.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fips-Rejection-by-GCRYCTL_FIPS_REJECT_NON_FIPS-not-b.patch
Type: text/x-diff
Size: 17026 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241220/2f740941/attachment-0001.patch>

From gniibe at fsij.org  Fri Dec 20 05:50:24 2024
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Fri, 20 Dec 2024 13:50:24 +0900
Subject: FIPS 140 service indicator revamp
In-Reply-To: <87seqjktsi.fsf@akagi.fsij.org>
References: <eb829629-0de1-409d-b882-94dec5ec426c@atsec.com>
 <87ttc17zxm.fsf@jacob.g10code.de> <878qtbu67h.fsf@akagi.fsij.org>
 <2749479.THHkFifcbA@tauon.atsec.com> <87mshm4m06.fsf@akagi.fsij.org>
 <875xny8uzx.fsf@akagi.fsij.org> <875xnp5ufr.fsf@akagi.fsij.org>
 <87wmg0l8nj.fsf@akagi.fsij.org> <87wmfy6he9.fsf@akagi.fsij.org>
 <87ed25fs8v.fsf@akagi.fsij.org> <87a5cs8kgl.fsf@akagi.fsij.org>
 <87seqjktsi.fsf@akagi.fsij.org>
Message-ID: <87pllnklf3.fsf@akagi.fsij.org>

NIIBE Yutaka <gniibe at fsij.org> wrote:
> Then, I'll work on other gcry_pk_* API.

Here is a patch which add the behavior of finishing the computation
marking non-compliant if it is the case (instead of rejecting).

We need tests for this.  And there might be other places where we need
to mark non-compliant in public key crypto code.
-- 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fips-cipher-Add-behavior-not-to-reject-but-mark-non-.patch
Type: text/x-diff
Size: 9834 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20241220/fd562240/attachment.patch>