Here's patches for adding CET support to x86-64 and i386 assembly.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

There is -O flag munging for "tiger.o" in "cipher/Makefile.am", an old workaround for broken compiler I think. IMHO tiger.o case can and should be removed.

OpenBSD carries libgcrypt patch for CET which adds endbr64 instruction to CFI_STARTPROC() macro in "asm-common-amd64.h". We could do the same and also add endbr32 to i386 too. That would be easiest way to add required endbr instructions. OpenBSD also has patch for arm64 to add similar BTI instructions to aarch64 variant of CFI_STARTPROC.

I tried to reproduce issue with clang/w32 toolchain from https://github.com/mstorsjo/llvm-mingw but there build worked even with CFI directives.

Hm, CFI directives should not be used on WIN32 target. This patch should solve the issue for now:

Thanks for testing. I pushed this fix to libgcrypt master.

Just to make sure, did you use the updated version of the patch? I edited the message with fix candidate and changed the attachment.

Here's fix candidate (edit, new try):

Algo 329 and 330 are the new CSHAKE128 and CSHAKE256 digest algos. Looks that s390x only support accelerating SHA3 and SHAKE, as only SHA3 and SHAKE suffix are supported (see keccak_final_s390x()). So s390x acceleration needs to be disabled for CSHAKE algos.

I left review comments in gitlab. One additional concern is license for mpi-mul-cs.c, original code not having copyright information... "does not have any copyright information, assuming public domain".

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

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

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.

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.

Attached patch should workaround the issue:

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

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

Just started wondering how much of this slow down is because of MingW libc not having very well optimized memcpy/memmove/memchr/strlen/etc. Is there profiling tools like 'perf' on Linux that could be used for Windows builds?

Problem with SHA-256 on x86-64 is that it took long time for Intel to introduce SHA acceleration (SHA1 & SHA256) to their main CPU products.

Here's fix for mode specific setkey clearing error code:

About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.

I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.

tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.

That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.

Here's mirroring script that is in place currently:

#!/bin/bash -e