In libgcrypt/cipher/ecc-ecdsa.c, we have:

mpi_mulm (s, k_1, sum, ec->n);    /* s = k^(-1)*(hash+(d*r)) mod n */

I think you are correct.

IIUC, it's GCC 8 which starts the support of __nonstring__ attribute.

Pushed all changes to master.

I applied some to master (generic improvement parts).

I think that this may be the last update.
Don't use mpi_powm to avoid normalizing (and to be faster).

Here is another update (replacing ecc-no-normalize-2025-03-13.patch).
Further, ec_addm is modified to be less leaky.

There are three (or more) remaining things:
(1) ec_addm can be improved by adding U and V with mpih_add_lli , subtracting P with mpih_sub_n, and adding back P with mpih_add_n_cond
(2) Places with mpi_const for the argument when calling ec_mulm, ec_add or ec_subm should be fixed (it may modify the const MPI)
(3) make sure mpi_resize within ec_addm, ec_mulm, or ec_subm if needed

Here is update (replacing ecc-no-normalize-2025-03-07.patch).
ec_subm and ec_mulm are modified to be less leaky.

I think that major signal sources for K have been killed so far.

We should only enable least leak implementation for 64-bit, as it's not as fast on 32-bit architecture.

We should only enable least leak implementation for 64-bit, as it's not as fast on 32-bit architecture.

One more change for _gcry_dsa_gen_k in rC54caef02afa9: cipher:(EC)DSA: Simply use mpi_clear_highbit in _gcry_dsa_gen_k.

One more change for mpi_invm in rCc1da86e45a6e: mpi: Avoid normalizing MPI in _gcry_mpi_invm.

All changes are pushed to master.

Pushed the changes by the commit rC2039d93289db: mpi: Add MPI helper modular exponentiation, Least Leak Intended.

Use of mpi_cmp is now being fixed, by providing _gcry_mpih_cmp_lli function.
Along with that, we need to fix use of mpi_cmp_ui, since it's skips earlier depending its limbs.

diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c
index 170dce12..e010e182 100644
--- a/cipher/dsa-common.c
+++ b/cipher/dsa-common.c
@@ -25,6 +25,7 @@

And then, we need to use less leaky version of mpi_cmp (because mpi_cmp calls mpi_normalize, it's not good).

And this is for less leak for _gcry_dsa_modify_k:

This is needed before we remove leaks by mpi_add in _gcry_dsa_modify_k :

Commit rC35a6a6feb9dc: Fix _gcry_dsa_modify_k. is related, but it doesn't matter for usual compilers (it's an issue for MSVC).

This is needed for RFC6979 flag support.

The commit rC58c11aa8 is the improved version by k-ary exponentiation (while rC6dffd105e2e2 is 1-bit at a time) and using heap.

I created https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7490/
The commit rC6dffd105e2e2 works for me.
It is a bit of exponent at time Montgomery exponentiation.
I don't put an optimization for the reduction as I don't know if it's OK for patent-wise (looks like expired, though).

Re-open, so that I can pursue constant-time modular exponentiation.

Here are changes for gcry_md_open and its friends.

My idea in https://dev.gnupg.org/T7338#195529 doesn't work well when a function call is done multiple times.
Assuming SUCCESS, and marking all non-compliant places in the code works, and it would be good because libgcrypt so far maintains non-compliant path with rejection.

Pushed the change for adding hash tests in rC7faf542f1573: fips,tests: Add t-digest.

It seems that the internal API (as of 2024-12-06) is not enough.
Now, we have _gcry_md_hash_buffer function with the new FIPS service indicator.
It's used for public key crypto, too.
The compliance for hash function is a part of public key crypto, but not all.

A change for gcry_md_hash_* functions are pushed by rC3478caac62c7: fips,md: Implement new FIPS service indicator for gcry_md_hash_*..
It doesn't have tests with FIPS service indicator yet.

New external API is by GCRYCTL_FIPS_SERVICE_INDICATOR and/or the new macro gcry_get_fips_service_indicator.
This change is pushed by rCf51f4e98930e: fips: Introduce GCRYCTL_FIPS_SERVICE_INDICATOR and the macro.

New internal API is introduced with T7340 by the commit rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

Change is pushed by rCe1cf31232825: fips: Introduce an internal API for FIPS service indicator.

I created a branch: https://dev.gnupg.org/source/libgcrypt/history/gniibe%252Ft7340/

Autoconf archive has AX_TLS: https://www.gnu.org/software/autoconf-archive/ax_tls.html
Also, AX_GCC_VAR_ATTRIBUTE(tls_model) could be used: https://www.gnu.org/software/autoconf-archive/ax_gcc_var_attribute.html

Pushed the change in: rC38742196c04c: cipher:kyber: Add gcry_kem_genkey to support deterministic op.
rC4876a1a45c25: tests:kyber: Add genkey and encap KAT tests.

Use --enable-large-data-tests with configure and go out for a real long lunch

As far as I know the practice to have separate -dev packages is very common among Linux distributions.

I wonder how common this practice of splitting development material into a separate file might be? It is in place at Alpine, since the file libgpg-error-dev exists. Once the related component is instaled, these messages/strings are printed:; output filtered:

checking for GPG Error - version >= 1.49... expr: warning: '^x-L': using '^' as the first character of a basic regular expression is not portable; it is ignored  yes (1.49)

Does alpine split the development files of libgpg-error into a separate *-devel (or similar) package like most other distros? If yes, then you need to install this development package.

Thanks. Test works in my nightly builds now.

That's my badness.
I noticed by the CI at https://gitlab.com/redhat-crypto/libgcrypt/libgcrypt-mirror

I do not have Aarch64 machine at hand so what I did was building the package with changes on the build system with previous patches and checking the correct flag are in place (previously in RHEL10, but now in Fedora):

Do you have any way to test PAC/BTI on actual HW that support these extensions?

Thanks! Verified this builds on aarch64 correctly and generates the right flags on the output:

Hardened: /builddir/build/BUILDROOT/libgcrypt-1.11.0-3.el10.aarch64/usr/lib64/libgcrypt.so.20.5.0: Overall: PASS.

This excludes 32-bit ARM assembly from Aarch64 builds:

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

0001-mpi-ec-inline-reduce-register-pressure-on-32-bit-ARM.patch4 KBDownload

Tested in our build environment and indeed, just this patch does not solve the issue for aarch64.

Here's patch:

This patch should fix the issue:

Ok, so aarch64 assembly would need PAC and BTI support. As far as I have understood these, is that PAC instructions are not needed with current assembly as none of those is storing/loading LR register (all aarch64 assembly functions are leaf functions). So only BTI is needed and that is basically same modification as CET on x86.

This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)

Recent changes fixed the issue for the x86_64 builds, but I see similar symptoms in the aarch64 build now. Annocheck reports the following failures:

Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: dynamic-tags test because the BTI_PLT flag is missing from the dynamic tags 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-dynamic-tags.html
Hardened: /usr/lib64/libgcrypt.so.20.5.0: FAIL: property-note test because properly formatted .note.gnu.property not found (it is needed for branch protection support) 
Hardened: /usr/lib64/libgcrypt.so.20.5.0: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-property-note.html

I do not have aarch64 machine at hand now to investigate this further, but this sounds like orthogonal functionality to the CET on Intel.

Thank you. With this patch the IBT flags are present on the shared object and CF protection test passes.

"rijndael-vaes-avx2-i386.S" should not be build for x86-64 but until now that has not had any affect as #ifdefs in that source file result empty object file on x86-64.