Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

I noticed this recently too on some boxes. Thanks for the good decription. This support for pkg-config style .pc files for our config scripts seems to be a never ending story. The alternative name for libgpg-error-config does not make it easier.

Thanks for report. I've applied this change to master.

I think so. We did not submit a modules for recertification with these changes, but we do not plan this in close future so you can consider it completed.

Can we close this?

Here is current version:

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..bf50b00b 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,61 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  clockid_t id;
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_init (gcry_timedwait_t tw, unsigned int flags)
+{
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw->id = CLOCK_THREAD_CPUTIME_ID;
+  if (clock_gettime (tw->id, &tw->ts) < 0)
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_finish (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (tw->id, &ts) < 0)
+    return gpg_err_code_from_syserror ();
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

API which does not require allocation internally would be better. In this case, it is allocated on stack by the caller.

I mean, something like this (for GNU/Linux):

diff --git a/src/misc.c b/src/misc.c
index 4db2d9a4..74864334 100644
--- a/src/misc.c
+++ b/src/misc.c
@@ -577,3 +577,80 @@ _gcry_divide_by_zero (void)
     gpg_err_set_errno (EDOM);
     _gcry_fatal_error (gpg_err_code_from_errno (errno), "divide by zero");
 }
+
+#ifdef HAVE_CLOCK_GETTIME
+#include <time.h>
+# if defined(CLOCK_THREAD_CPUTIME_ID) && defined(CLOCK_TAI)
+struct gcry_timedwait
+{
+  struct timespec ts;
+};
+
+typedef struct gcry_timedwait *gcry_timedwait_t;
+
+gcry_err_code_t
+_gcry_timedwait_new (gcry_timedwait_t *r_tw, unsigned int flags)
+{
+  gcry_err_code_t err;
+  gcry_timedwait_t tw;
+
+  *r_tw = NULL;
+
+  /* Possibly, it would be good to be able to select the wall clock.
+   * For now, it's CPU time by the thread.  */
+  if (flags != 0)
+    return GPG_ERR_INV_ARG;
+
+  tw = xtrymalloc (sizeof (gcry_timedwait_t));
+  if (!tw)
+    return gpg_err_code_from_syserror ();
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &tw->ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  *r_tw = tw;
+  return 0;
+}
+
+gcry_err_code_t
+_gcry_timedwait_release (gcry_timedwait_t tw, struct timespec ts_r)
+{
+  gcry_err_code_t err;
+  struct timespec ts;
+  u32 negative;
+
+  if (clock_gettime (CLOCK_THREAD_CPUTIME_ID, &ts) < 0)
+    {
+      err = gpg_err_code_from_syserror ();
+      xfree (tw);
+      return err;
+    }
+
+  ts.tv_sec -= tw->ts.tv_sec;
+  ts.tv_nsec -= tw->ts.tv_nsec;
+  negative = ((u32)ts.tv_nsec) >> 31;
+  ts.tv_sec -= negative;
+  ts.tv_nsec += (1000000000 * negative);
+
+  xfree (tw);
+
+  ts_r.tv_sec -= ts.tv_sec;
+  ts_r.tv_nsec -= ts.tv_nsec;
+  negative = ((u32)ts_r.tv_nsec) >> 31;
+  ts_r.tv_sec -= negative;
+  ts_r.tv_nsec += (1000000000 * negative);
+
+  if (ts_r.tv_sec < 0)
+    return GPG_ERR_TIME_CONFLICT;
+
+  if (clock_nanosleep (CLOCK_TAI, 0, &ts_r, &ts_r))
+    return gpg_err_code_from_syserror ();
+
+  return 0;
+}
+# endif
+#endif

Thank you!

Applied to both (master and 1.10 branch).

Looks good to me. __CLOBBER_CC is needed as PA-RISC has carry/borrow bits in status register for add/sub instructions.

Since I don't like to introduce hppa specific workaround in a way like pragma (and I have no time to fix compiler itself), I tried to improve the ec-nist.c for hppa so that register pressure can be lower.
Here is my solution.

Alternatively (more narrow workaround), when I add a line:

#pragma GCC optimize("O1")

before the function _gcry_mpi_ec_nist256_mod in mpi/ec-nist.c, it works for me on panama.debian.net (Debian porterbox for hppa).

No, hardware barrier is not needed here. Compiler barrier is used here to prevent optimization removing mask generation and usage in following constant-time code.

Clarification from Dave:

Thanks, I can confirm that this patch fixes the issue. I'll let Sam decide if this is how we want to handle it downstream or wait for confirmation from gcc.

A way to generated keys in the usual s-expression way has been added. This allows us to get the keygrip for the key.

FWIW, I posted some ideas at https://lists.gnupg.org/pipermail/librepgp-discuss/2024/000043.html . For official use in Germany we will very likely also add Brainpool curves as a replacement for the IETF curves.

Although, we don't use our usual s-expressions we need to add a way to derive a keygrip from Kyber et al and also to wrap the key into an s-expression to that it can be stored by gpg-agent in its usual files. An exported new API to get the keygrip of a KEM key would be good to avoid encapsulation but for other purposes an encapsulation is still required.

Applied the change. I write the ChangeLog entry by commit message.

Fixed in master.

Thanks for your report. It seems the linker for Android is more strict.

Fixed in rC128121e74b66: build: Use @FGREP@ by configure for libgcrypt-config..

Thank you. I recently fixed for use of egrep rC656ca459e3d8: m4: Update acinclude.m4 to use $GREP., but overlooked this one.

Regading Kyber in GnuPG, there are a couple of open questions. For example whether the implicit lengths used for the key parameters match well with the overall protocol structure. Thus, as soon as we have finished the Libgcrypt part we will address this and implement it in some way. Before we do this we have to do a couple of changes to GnuPG required for FIPS compliance.

I just saw that Niibe is already working on the integration of the ML-KEM code into the master branch of libgcrypt. Apparently, this is an entirely new code base. Currently we are working on the integration of our ML-KEM implementation in libgcrypt into GnuPG. But based on what I see now it seems that apparently another approach is planned and already underway for libgcrypt and probably later also for GnuPG. It would be helpful if you could give us a pointer what your exact plans are, this makes it easier for us to direct our efforts in the optimal way.

Fix for i386 assembly pushed to master and 1.10 branch.

It looks that this is a bit more problematic case than I thought. Now building i386 with "-O2 -fsanitize=undefined" flags fails. I need to think little bit more how to handle this.

@jukivili Thanks a lot. Please push the change to 1.10 branch and master.

Sorry for the fallout and thank you for taking care of it.

Ah... it fails by make check because it does change the text in tests/basic.c which requires update of hash value.
I'm going to take care of this regressions.

Thank you. All applied and pushed to master.

You may better ask on gcrypt-devel at gnupg.org for help.

And another question: in the GnuPG code on the master branch I saw that algorithm identifiers for ML-KEM with Ed25519 and Ed448 are already defined in the code base. Do I understand correctly that the maintainers prefer the inclusion of these two algorithms and not necessarily the inclusion of the ones based on ML-KEM with ECDH using NIST or Brainpool curves?

We have addressed all comments regarding ML-KEM (Kyber) and KMAC. Currently I am working on the GnuPG integration of the the ML-KEM composites. For that purpose I will need a branch of libgcrypt with both ML-KEM and KMAC. I am not sure if you are considering to integrate the ML-KEM version already now before the final NIST standards are release. Some libraries do it, for instance Botan. Appropriate naming of the algorithms can ensure that there arises no confusion which version of the algorithm one is using.

RSA improvement is not that worth now.

OK. When we will need and do, I will open new one.

The fix is in 1.10.3.

Fix is in 1.10.3.

@gniibe: This is a pretty old bug; given all the changes of the last year, should we close it now?

In master, when fixing padding issue, libgcrypt/src/const-time.h is just introduced.
I will replace your functions.

In T6637#177217, @jukivili wrote:

Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).

In T6637#176910, @fse wrote:

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

Yes, int8_t/int16_t/int32_t/uint8_t/uint16_t/uint32_t should not be used. There is size-specific integer types defined in src/types.h which can be used instead (byte/u16/u32). This header does not yet have signed integer types, but those can be added (for example, s8/s16/s32).

@jukivilli I have addressed a number of your comments now. You find my comments inline.

Yes, apparently I confused uint8_t and unsigned char here because the former appears in Simon's comments. We also kept to the use of unsigned char* in our implementations (that is even part of the GNU coding guidelines if I remember correctly).

Actually we never use uint8_t* because that is c99 and very uncommon except for some MCU projects. Instead we use unsigned char *. The use of void* is often used because this allows to pass arbitrary types to a function without requiring ugly and error-prone casting at the caller site.

You don't need a library but just one object file.

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

With respect to the function signatures, I see the following issues with the API you reference via the provided link:

@fse: Github is not an option here. We don't use it and thus everything relevant to Libgcrypt needs to be documented here and not at some external platform.

For length information, we can find that Simon's patch (let me call it v1) has length argument:
https://gitlab.com/jas/libgcrypt/-/commit/3af635afca052a9575912b257fe7518a58bfe810

Hi Jussi,

• There's many functions that use buffers on stack. Do those contain secrets? Should those buffers be wiped before returning from function (with wipememory())? For example, "mlkem_check_secret_key" has two buffers "shared_secret_1" and "shared_secret_2" which are not wiped.
• mlkem.c: mlkem_check_secret_key: "memcmp" is used to compare shared secrets. Should this use constant time comparison instead?
• mlkem-common.c: _gcry_mlkem_mlkem_shake256_rkprf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close.
• mlkem-symmetric.c: _gcry_mlkem_shake256_prf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close. Temporary buffer usage can be avoided by passing input buffers through two IOV to _gcry_md_hash_buffers_extract.

Few comments on the patches.

Our own internal function signatures is not necessarily a good refernce. The main objection to all what you list above is the lack of explicit length information. For each uint8_t* there should also be a size_t ...len in my opinion. Otherwise the API will be highly prone to memory access errors.

@fse Thank you for your comment (quick ! :-).

The API that you quote at the end is indeed what is comonly understood as how a KEM functions and is exactly what fits to ML-KEM.

Please send us patches (to this branch).

One question on the future cooperation: is it from now on possible to directly commit to these branches or will we continue to work with uploading patches to this task?

Pushed the change into kem-kyber branch.
https://dev.gnupg.org/source/libgcrypt/history/kem-kyber/

I'll create a branch for this work. Then, I'll incorporate changes to master.

Uploading two patches for review: