pq_crypto 0.6.5 → 0.6.7

data/ext/pqcrypto/vendor/mldsa-native/mldsa/src/sys.h

@@ -39,6 +39,21 @@
 #define MLD_SYS_AARCH64
 #endif
 
+/* Check if the AArch64 compilation target supports NEON (Advanced SIMD).
+ *
+ * Some compilers also define __ARM_NEON__, but __ARM_NEON is the most reliable
+ * signal. Specifically, clang on Apple appears to keep __ARM_NEON__ set even if
+ * -march=armv8-a+nosimd is set.
+ *
+ * gcc 4.8 -- the first gcc version introducing Neon support -- sets neither
+ * __ARM_NEON nor __ARM_NEON__; in fact, there is no preprocessor signal that
+ * Neon is enabled. If you use gcc 4.8 and need Neon, you should set
+ * MLD_SYS_AARCH64_NEON manually. gcc 4.9 onwards do set __ARM_NEON.
+ */
+#if defined(MLD_SYS_AARCH64) && defined(__ARM_NEON)
+#define MLD_SYS_AARCH64_NEON
+#endif
+
 /* Check if we're running on an AArch64 big endian system. */
 #if defined(__AARCH64EB__)
 #define MLD_SYS_AARCH64_EB
@@ -49,12 +64,13 @@
 #define MLD_SYS_ARMV81M_MVE
 #endif
 
-#if defined(__x86_64__)
+/* Check if we're running on an x86_64 system. */
+#if defined(__x86_64__) || defined(_M_X64) || defined(_M_AMD64)
 #define MLD_SYS_X86_64
 #if defined(__AVX2__)
 #define MLD_SYS_X86_64_AVX2
 #endif
-#endif /* __x86_64__ */
+#endif /* __x86_64__ || _M_X64 || _M_AMD64 */
 
 #if defined(MLD_SYS_LITTLE_ENDIAN) && defined(__powerpc64__)
 #define MLD_SYS_PPC64LE
@@ -153,6 +169,22 @@
 #endif
 #endif /* !MLD_ALWAYS_INLINE */
 
+/*
+ * MLD_NOINLINE: Prevent inlining.
+ * - MSVC: __declspec(noinline)
+ * - GCC/Clang: __attribute__((noinline))
+ * - Other: empty
+ */
+#if !defined(MLD_NOINLINE)
+#if defined(_MSC_VER)
+#define MLD_NOINLINE __declspec(noinline)
+#elif defined(__GNUC__) || defined(__clang__)
+#define MLD_NOINLINE __attribute__((noinline))
+#else
+#define MLD_NOINLINE
+#endif
+#endif /* !MLD_NOINLINE */
+
 #ifndef MLD_STATIC_TESTABLE
 #define MLD_STATIC_TESTABLE static
 #endif
@@ -185,7 +217,7 @@
 #endif
 
 
-/* New X86_64 CPUs support Conflow-flow protection using the CET instructions.
+/* New X86_64 CPUs support control-flow protection using the CET instructions.
  * When enabled (through -fcf-protection=), all compilation units (including
  * empty ones) need to support CET for this to work.
  * For assembly, this means that source files need to signal support for
@@ -233,15 +265,42 @@
 #define MLD_MUST_CHECK_RETURN_VALUE
 #endif
 
+/* The x86_64 assembly backend uses the SysV calling convention. On Windows,
+ * where the Microsoft x64 calling convention is the default, it can still be
+ * used with compilers that allow choosing the calling convention per
+ * function: GCC and Clang support __attribute__((sysv_abi)), which makes
+ * calls to the annotated function follow the SysV calling convention.
+ *
+ * MLD_SYSV_ABI_SUPPORTED signals that the toolchain can call SysV assembly
+ * routines; the x86_64 assembly backend is only enabled if it is defined.
+ * MLD_SYSV_ABI is the attribute carried by declarations of x86_64 assembly
+ * routines. Both macros can be set externally for toolchains offering an
+ * equivalent mechanism that is not recognized here. */
+#if defined(MLD_SYS_X86_64) && !defined(MLD_SYSV_ABI_SUPPORTED)
+#if !defined(MLD_SYS_WINDOWS) || defined(__GNUC__) || defined(__clang__)
+#define MLD_SYSV_ABI_SUPPORTED
+#endif
+#endif
+
+#if !defined(MLD_SYSV_ABI)
+#if defined(MLD_SYS_WINDOWS) && defined(MLD_SYSV_ABI_SUPPORTED)
+#define MLD_SYSV_ABI __attribute__((sysv_abi))
+#else
+#define MLD_SYSV_ABI
+#endif
+#endif /* !MLD_SYSV_ABI */
 
 #if !defined(__ASSEMBLER__)
 /* System capability enumeration */
 typedef enum
 {
   /* x86_64 */
-  MLD_SYS_CAP_AVX2,
+  MLD_SYS_CAP_X86_64_AVX2,
   /* AArch64 */
-  MLD_SYS_CAP_SHA3
+  MLD_SYS_CAP_AARCH64_NEON,
+  MLD_SYS_CAP_AARCH64_SHA3,
+  /* Armv8.1-M */
+  MLD_SYS_CAP_ARMV81M_MVE
 } mld_sys_cap;
 
 #if !defined(MLD_CONFIG_CUSTOM_CAPABILITY_FUNC)

data/ext/pqcrypto/vendor/mlkem-native/BUILDING.md

@@ -73,11 +73,14 @@ For detailed information on how to use the script, please refer to
 
 You can also build **mlkem-native** on Windows using `nmake` and an MSVC compiler.
 
-To build and run the tests (only support functional testing for non-opt implementation for now), use the following `nmake` targets:
+To build and run the tests, use the following `nmake` target:
 ```powershell
-nmke /f .\Makefile.Microsoft_nmake quickcheck
+nmake /f .\Makefile.Microsoft_nmake quickcheck
 ```
 
+This runs the functional, RNG-failure, allocation, ACVP, KAT and Wycheproof tests. The assembly backends are not yet
+supported on Windows, so the tests are built for the C backend only.
+
 # Checking the proofs
 
 ## CBMC

data/ext/pqcrypto/vendor/mlkem-native/LICENSE

@@ -6,14 +6,32 @@ of the Apache-2.0 license OR the ISC license OR the MIT license.
 These licenses are reproduced at the bottom of this file.
 The copyright holders are indicated at the top of each file.
 
-The code in test/notrandombytes/* is derived from
+Files outside the library itself may carry different terms. Every file
+states its own SPDX-License-Identifier, which determines the terms that
+apply to it. In particular:
+
+The code in test/notrandombytes/*, and its copies in
+examples/*/test_only_rng/* and scripts/notrandombytes, is derived from
 https://cr.yp.to/papers.html#surf and licensed under
 LicenseRef-PD-hp OR CC0-1.0 OR 0BSD OR MIT-0 OR MIT.
 It is only used for testing purposes.
 
-The benchmarking code in test/hal/hal.c carries the
+The benchmarking code in test/hal/* carries the
 MIT license. It is only used for testing purposes.
 
+The tiny_sha3 code in
+examples/bring_your_own_fips202/custom_fips202/tiny_sha3/* and
+examples/custom_backend/mlkem_native/src/fips202/native/custom/src/*
+carries the MIT license. It is only used to demonstrate custom
+FIPS-202 implementations.
+
+The proofs in proofs/* are in part derived from Amazon Web Services
+verification infrastructure. Individual files carry, among others,
+Apache-2.0 OR ISC OR MIT-0, MIT-0, and MIT-0 AND Apache-2.0. None of the
+proofs are part of the library.
+
+Documentation is licensed under CC-BY-4.0.
+
 ```
 Copyright (c) The mlkem-native project authors
 Copyright (c) 2020 Dougall Johnson
@@ -39,7 +57,7 @@ OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
 SOFTWARE.
 ```
 
-The tiny_sha3 implementation in examples/custom_backend/mlkem_native/mlkem/fips202/native/custom/src/
+The tiny_sha3 implementation in examples/custom_backend/mlkem_native/src/fips202/native/custom/src/
 carries the MIT license. It is only used for testing purposes.
 
 ```

data/ext/pqcrypto/vendor/mlkem-native/README.md

@@ -3,7 +3,6 @@
 # mlkem-native
 
 ![CI](https://github.com/pq-code-package/mlkem-native/actions/workflows/all.yml/badge.svg)
-![Proof: HOL-Light](https://github.com/pq-code-package/mlkem-native/actions/workflows/hol_light.yml/badge.svg)
 ![Benchmarks](https://github.com/pq-code-package/mlkem-native/actions/workflows/bench.yml/badge.svg)
 ![C90](https://img.shields.io/badge/language-C90-blue.svg)
 
@@ -166,6 +165,8 @@ For CI benchmark results and historical performance data, see the [benchmarking
 If you want to use mlkem-native, import [mlkem](mlkem) into your project's source tree and build using your favourite build system. See [mlkem](mlkem) for more information, and
 [examples/basic](examples/basic) for a simple example. The build system provided in this repository is for development purposes only.
 
+See [API-CONVENTIONS.md](API-CONVENTIONS.md) for conventions that apply to all public functions, such as return values, pointer validity, and the state of output buffers on error.
+
 ### Can I bring my own FIPS-202?
 
 mlkem-native relies on and comes with an implementation of FIPS-202[^FIPS202]. If your library has its own FIPS-202 implementation, you
@@ -215,7 +216,6 @@ through the [PQCA Discord](https://discord.com/invite/xyVnwzfg5R). See also [CON
 [^FIPS202]: National Institute of Standards and Technology: FIPS202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, [https://csrc.nist.gov/pubs/fips/202/final](https://csrc.nist.gov/pubs/fips/202/final)
 [^FIPS203]: National Institute of Standards and Technology: FIPS 203 Module-Lattice-Based Key-Encapsulation Mechanism Standard, [https://csrc.nist.gov/pubs/fips/203/final](https://csrc.nist.gov/pubs/fips/203/final)
 [^HOL-Light]: John Harrison: HOL-Light Theorem Prover, [https://hol-light.github.io/](https://hol-light.github.io/)
-[^HYBRID]: Becker, Kannwischer: Hybrid scalar/vector implementations of Keccak and SPHINCS+ on AArch64, [https://eprint.iacr.org/2022/1243](https://eprint.iacr.org/2022/1243)
 [^KyberSlash]: Bernstein, Bhargavan, Bhasin, Chattopadhyay, Chia, Kannwischer, Kiefer, Paiva, Ravi, Tamvada: KyberSlash: Exploiting secret-dependent division timings in Kyber implementations, [https://kyberslash.cr.yp.to/papers.html](https://kyberslash.cr.yp.to/papers.html)
 [^REF]: Bos, Ducas, Kiltz, Lepoint, Lyubashevsky, Schanck, Schwabe, Seiler, Stehlé: CRYSTALS-Kyber C reference implementation, [https://github.com/pq-crystals/kyber/tree/main/ref](https://github.com/pq-crystals/kyber/tree/main/ref)
 [^SLOTHY_Paper]: Abdulrahman, Becker, Kannwischer, Klein: Fast and Clean: Auditable high-performance assembly via constraint solving, [https://eprint.iacr.org/2022/1303](https://eprint.iacr.org/2022/1303)

data/ext/pqcrypto/vendor/mlkem-native/RELEASE.md

@@ -1,5 +1,118 @@
 [//]: # (SPDX-License-Identifier: CC-BY-4.0)
 
+mlkem-native v2.0.0
+===================
+
+Release notes
+-------------
+
+mlkem-native v2.0.0 is the second major release of mlkem-native. It follows
+mlkem-native v1.3 and makes minor API changes: It removes the SUPERCOP `crypto_kem_*`
+aliases and the legacy `MLK_CONFIG_API_*` path, splits the ambiguous `MLK_ERR_FAIL`
+return code into specific error codes, and renames the FIPS-202 backend and
+system-capability macros.
+
+See the full change log here:
+https://github.com/pq-code-package/mlkem-native/compare/v1.3.0...v2.0.0
+
+Long-Term Support
+-----------------
+
+[`release/v1.3`](https://github.com/pq-code-package/mlkem-native/tree/release/v1.3) will
+act as a support branch until February 2027 (inclusive). It will receive bugfixes, but no
+new features. We do currently not plan to offer long-term support for mlkem-native v1.x beyond that timeframe.
+
+If you are deploying mlkem-native v1.3 and expect to be unable to upgrade to
+mlkem-native v2 by February 2027, please contact us to discuss a potential extension
+of the support schedule.
+
+Breaking changes since v1.3.0
+-----------------------------
+
+- Split the ambiguous `MLK_ERR_FAIL` return code into `MLK_ERR_INVALID_PK`
+  (`-4`), `MLK_ERR_INVALID_SK` (`-5`), and `MLK_ERR_PCT_FAIL` (`-6`), returned
+  respectively for a public key rejected by the FIPS 203 modulus check, a secret
+  key rejected by the hash check, and a failed keygen pairwise consistency test.
+  The codes `-1`..`-3` are unchanged; `MLK_ERR_FAIL` remains defined but is no
+  longer returned by any function. Integrators mapping return codes into their
+  own error space must handle the new values.
+  ([#1852](https://github.com/pq-code-package/mlkem-native/pull/1852))
+- Remove the SUPERCOP `crypto_kem_*` API aliases, the `MLK_CONFIG_NO_SUPERCOP`
+  option, and the `CRYPTO_{PUBLICKEY,SECRETKEY,CIPHERTEXT}BYTES`,
+  `CRYPTO_SYMBYTES` and `CRYPTO_BYTES` size constants. Consumers must use the
+  namespaced API (e.g. `mlkem_keypair`) and derive sizes from
+  `MLK_CONFIG_PARAMETER_SET`.
+  ([#1857](https://github.com/pq-code-package/mlkem-native/pull/1857))
+- Remove the legacy `MLK_CONFIG_API_*` configuration path. Configure builds
+  through the configuration file instead, renaming `MLK_CONFIG_API_PARAMETER_SET`
+  to `MLK_CONFIG_PARAMETER_SET`, `MLK_CONFIG_API_NAMESPACE_PREFIX` to
+  `MLK_CONFIG_NAMESPACE_PREFIX`, `MLK_CONFIG_API_CONSTANTS_ONLY` to
+  `MLK_CONFIG_CONSTANTS_ONLY`, and `MLK_CONFIG_API_QUALIFIER` to
+  `MLK_CONFIG_EXTERNAL_API_QUALIFIER`. For a multi-level build, set
+  `MLK_CONFIG_MULTILEVEL_BUILD`; the parameter set is now appended to the
+  namespace prefix automatically.
+  ([#1853](https://github.com/pq-code-package/mlkem-native/pull/1853))
+- Prefix the `mlk_sys_cap` enum values with their architecture:
+  `MLK_SYS_CAP_{AVX2,NEON,SHA3,MVE}` become
+  `MLK_SYS_CAP_{X86_64_AVX2,AARCH64_NEON,AARCH64_SHA3,ARMV81M_MVE}`. Custom
+  capability functions must use the new names.
+  ([#1770](https://github.com/pq-code-package/mlkem-native/pull/1770))
+- Rename the FIPS-202 backend function-support flags to the
+  `MLK_USE_NATIVE_<function>` convention used by the arithmetic backend:
+  `MLK_USE_FIPS202_X1_NATIVE` to `MLK_USE_NATIVE_FIPS202_X1`,
+  `MLK_USE_FIPS202_X4_NATIVE` to `MLK_USE_NATIVE_FIPS202_X4`,
+  `MLK_USE_FIPS202_X4_XOR_BYTES_NATIVE` to `MLK_USE_NATIVE_FIPS202_X4_XOR_BYTES`,
+  and `MLK_USE_FIPS202_X4_EXTRACT_BYTES_NATIVE` to
+  `MLK_USE_NATIVE_FIPS202_X4_EXTRACT_BYTES`. Custom FIPS-202 backends must rename
+  these flags accordingly.
+  ([#1775](https://github.com/pq-code-package/mlkem-native/pull/1775))
+
+What's New
+----------
+
+### Assurance
+
+- Axiomatize the default `mlk_zeroize` in CBMC via a contract for its
+  zeroed-output postcondition, and configure the proofs with a failing custom
+  `mlk_zeroize` so they must rely on the contract rather than the concrete
+  implementation.
+  ([#1850](https://github.com/pq-code-package/mlkem-native/pull/1850))
+- Strengthen the top-level API contracts to check that output buffers are
+  zeroized or left unmodified on error.
+  ([#1850](https://github.com/pq-code-package/mlkem-native/pull/1850))
+
+### Configuration / API
+
+- Add the error codes `MLK_ERR_INVALID_PK`, `MLK_ERR_INVALID_SK`, and
+  `MLK_ERR_PCT_FAIL`, distinguishing a rejected public key, a rejected secret
+  key, and a failed keygen self-test. `mlk_check_pct` maps a key-check rejection
+  of the freshly generated key to `MLK_ERR_PCT_FAIL` and passes platform
+  failures through unmodified.
+  ([#1852](https://github.com/pq-code-package/mlkem-native/pull/1852))
+
+### Testing
+
+- Support the FIPS 203-tr1 encapDecap revision in the ACVP client, accepting a
+  decapsulation key supplied either as an expanded `dk` or as a `seed` (`d||z`)
+  to expand, with `keyFormat` inspected per group. mlkem-native now supports and
+  is tested against ACVP v1.1.0.43 in addition to the preceding two versions.
+  ([#1811](https://github.com/pq-code-package/mlkem-native/pull/1811))
+- Use runtime checks in the Wycheproof client instead of `assert`, which is
+  stripped under `python -O` and could report a mismatching vector as passing.
+  ([#1840](https://github.com/pq-code-package/mlkem-native/pull/1840))
+
+### Documentation
+
+- Add `API-CONVENTIONS.md` describing the conventions shared by all public
+  functions: return values and the meaning of the `MLK_ERR_XXX` codes, pointer
+  validity, and the state of output buffers on error. Link it from `README.md`
+  and the `mlkem_native.h` preamble.
+  ([#1843](https://github.com/pq-code-package/mlkem-native/pull/1843))
+- Document the `MLK_ERR_RNG_FAIL` error returned by keygen.
+  ([#1851](https://github.com/pq-code-package/mlkem-native/pull/1851))
+- Clarify the scope and customization of `mlk_zeroize`.
+  ([#1855](https://github.com/pq-code-package/mlkem-native/pull/1855))
+
 mlkem-native v1.3.0
 ===================
 

data/ext/pqcrypto/vendor/mlkem-native/mlkem/README.md

@@ -8,7 +8,7 @@ This is the main source tree of mlkem-native.
 
 To build a mlkem-native for a fixed parameter set (ML-KEM-512/768/1024), build the compilation in units in `src/*` separately, and link to an RNG and your application. See [examples/basic](../examples/basic) for a simple example.
 
-Alternatively, you can use the auto-geneated helper files [mlkem_native.c](mlkem_native.c) and [mlkem_native_asm.S](mlkem_native_asm.S), which bundle all *.c and *.S files together. See [examples/monolithic_build](../examples/monolithic_build) and [examples/monolithic_build_native](../examples/monolithic_build_native) for examples with and without native code.
+Alternatively, you can use the auto-generated helper files [mlkem_native.c](mlkem_native.c) and [mlkem_native_asm.S](mlkem_native_asm.S), which bundle all *.c and *.S files together. See [examples/monolithic_build](../examples/monolithic_build) and [examples/monolithic_build_native](../examples/monolithic_build_native) for examples without and with native code.
 
 ## Configuration
 
@@ -20,4 +20,4 @@ The public API is defined in [mlkem_native.h](mlkem_native.h).
 
 ## Supporting multiple parameter sets
 
-If you want to support multiple parameter sets, build the library once per parameter set you want to support. Set `MLK_CONFIG_MULTILEVEL_WITH_SHARED` for one of the builds, and `MLK_CONFIG_MULTILEVEL_NO_SHARED` for the others, to avoid duplicating shared functionality. Finally, link with RNG and your application as before. This is demonstrated in the examples [examples/multilevel_build](../examples/multilevel_build), [examples/multilevel_build_native](../examples/multilevel_build_native), [examples/monolithic_build_multilevel](../examples/monolithic_build_multilevel) and [examples/monolithic_build_multilevel_native](../examples/monolithic_build_multilevel_native).
+If you want to support multiple parameter sets, build the library once per parameter set you want to support. Set `MLK_CONFIG_MULTILEVEL_BUILD` for all of these builds; this is what appends the parameter set to the namespace prefix, keeping the level-specific symbols apart. To avoid duplicating shared functionality, additionally set `MLK_CONFIG_MULTILEVEL_WITH_SHARED` for exactly one of the builds, and `MLK_CONFIG_MULTILEVEL_NO_SHARED` for the others. Finally, link with RNG and your application as before. This is demonstrated in the examples [examples/multilevel_build](../examples/multilevel_build), [examples/multilevel_build_native](../examples/multilevel_build_native), [examples/monolithic_build_multilevel](../examples/monolithic_build_multilevel) and [examples/monolithic_build_multilevel_native](../examples/monolithic_build_multilevel_native).

data/ext/pqcrypto/vendor/mlkem-native/mlkem/mlkem_native.c

@@ -121,11 +121,6 @@
  * Undefine macros from MLK_CONFIG_PARAMETER_SET-specific files
  */
 /* mlkem/mlkem_native.h */
-#undef CRYPTO_BYTES
-#undef CRYPTO_CIPHERTEXTBYTES
-#undef CRYPTO_PUBLICKEYBYTES
-#undef CRYPTO_SECRETKEYBYTES
-#undef CRYPTO_SYMBYTES
 #undef MLKEM1024_BYTES
 #undef MLKEM1024_CIPHERTEXTBYTES
 #undef MLKEM1024_PUBLICKEYBYTES
@@ -152,17 +147,15 @@
 #undef MLK_API_CONCAT
 #undef MLK_API_CONCAT_
 #undef MLK_API_CONCAT_UNDERSCORE
-#undef MLK_API_LEGACY_CONFIG
 #undef MLK_API_MUST_CHECK_RETURN_VALUE
 #undef MLK_API_NAMESPACE
+#undef MLK_API_NAMESPACE_PREFIX
 #undef MLK_API_QUALIFIER
-#undef MLK_CONFIG_API_CONSTANTS_ONLY
-#undef MLK_CONFIG_API_NAMESPACE_PREFIX
-#undef MLK_CONFIG_API_NO_SUPERCOP
-#undef MLK_CONFIG_API_PARAMETER_SET
-#undef MLK_CONFIG_API_QUALIFIER
 #undef MLK_ERR_FAIL
+#undef MLK_ERR_INVALID_PK
+#undef MLK_ERR_INVALID_SK
 #undef MLK_ERR_OUT_OF_MEMORY
+#undef MLK_ERR_PCT_FAIL
 #undef MLK_ERR_RNG_FAIL
 #undef MLK_H
 #undef MLK_MAX3_
@@ -184,13 +177,6 @@
 #undef MLK_TOTAL_ALLOC_768_KEYPAIR
 #undef MLK_TOTAL_ALLOC_768_KEYPAIR_NO_PCT
 #undef MLK_TOTAL_ALLOC_768_KEYPAIR_PCT
-#undef crypto_kem_check_pk
-#undef crypto_kem_check_sk
-#undef crypto_kem_dec
-#undef crypto_kem_enc
-#undef crypto_kem_enc_derand
-#undef crypto_kem_keypair
-#undef crypto_kem_keypair_derand
 /* mlkem/src/common.h */
 #undef MLK_ADD_PARAM_SET
 #undef MLK_ALLOC
@@ -204,7 +190,10 @@
 #undef MLK_CONCAT_
 #undef MLK_EMPTY_CU
 #undef MLK_ERR_FAIL
+#undef MLK_ERR_INVALID_PK
+#undef MLK_ERR_INVALID_SK
 #undef MLK_ERR_OUT_OF_MEMORY
+#undef MLK_ERR_PCT_FAIL
 #undef MLK_ERR_RNG_FAIL
 #undef MLK_EXTERNAL_API
 #undef MLK_FIPS202X4_HEADER_FILE
@@ -313,6 +302,7 @@
 #undef MLK_CONTEXT_PARAMETERS_2
 #undef MLK_CONTEXT_PARAMETERS_3
 #undef MLK_CONTEXT_PARAMETERS_4
+#undef MLK_CONTEXT_UNUSED
 /* mlkem/src/debug.h */
 #undef MLK_DEBUG_H
 #undef mlk_assert
@@ -466,23 +456,23 @@
 /* mlkem/src/fips202/native/aarch64/x1_scalar.h */
 #undef MLK_FIPS202_AARCH64_NEED_X1_SCALAR
 #undef MLK_FIPS202_NATIVE_AARCH64_X1_SCALAR_H
-#undef MLK_USE_FIPS202_X1_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X1
 /* mlkem/src/fips202/native/aarch64/x1_v84a.h */
 #undef MLK_FIPS202_AARCH64_NEED_X1_V84A
 #undef MLK_FIPS202_NATIVE_AARCH64_X1_V84A_H
-#undef MLK_USE_FIPS202_X1_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X1
 /* mlkem/src/fips202/native/aarch64/x2_v84a.h */
 #undef MLK_FIPS202_AARCH64_NEED_X2_V84A
 #undef MLK_FIPS202_NATIVE_AARCH64_X2_V84A_H
-#undef MLK_USE_FIPS202_X4_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X4
 /* mlkem/src/fips202/native/aarch64/x4_v8a_scalar.h */
 #undef MLK_FIPS202_AARCH64_NEED_X4_V8A_SCALAR_HYBRID
 #undef MLK_FIPS202_NATIVE_AARCH64_X4_V8A_SCALAR_H
-#undef MLK_USE_FIPS202_X4_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X4
 /* mlkem/src/fips202/native/aarch64/x4_v8a_v84a_scalar.h */
 #undef MLK_FIPS202_AARCH64_NEED_X4_V8A_V84A_SCALAR_HYBRID
 #undef MLK_FIPS202_NATIVE_AARCH64_X4_V8A_V84A_SCALAR_H
-#undef MLK_USE_FIPS202_X4_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X4
 #endif /* MLK_SYS_AARCH64 */
 #if defined(MLK_SYS_X86_64)
 /*
@@ -491,7 +481,7 @@
 /* mlkem/src/fips202/native/x86_64/keccak_f1600_x4_avx2.h */
 #undef MLK_FIPS202_NATIVE_X86_64_KECCAK_F1600_X4_AVX2_H
 #undef MLK_FIPS202_X86_64_NEED_X4_AVX2
-#undef MLK_USE_FIPS202_X4_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X4
 /* mlkem/src/fips202/native/x86_64/src/fips202_native_x86_64.h */
 #undef MLK_FIPS202_NATIVE_X86_64_SRC_FIPS202_NATIVE_X86_64_H
 #undef mlk_keccak_f1600_x4_avx2_asm
@@ -507,9 +497,9 @@
 #undef MLK_FIPS202_ARMV81M_NEED_X4
 #undef MLK_FIPS202_NATIVE_ARMV81M
 #undef MLK_FIPS202_NATIVE_ARMV81M_MVE_H
-#undef MLK_USE_FIPS202_X4_EXTRACT_BYTES_NATIVE
-#undef MLK_USE_FIPS202_X4_NATIVE
-#undef MLK_USE_FIPS202_X4_XOR_BYTES_NATIVE
+#undef MLK_USE_NATIVE_FIPS202_X4
+#undef MLK_USE_NATIVE_FIPS202_X4_EXTRACT_BYTES
+#undef MLK_USE_NATIVE_FIPS202_X4_XOR_BYTES
 #undef mlk_keccak_f1600_x4_native_impl
 /* mlkem/src/fips202/native/armv81m/src/fips202_native_armv81m.h */
 #undef MLK_FIPS202_NATIVE_ARMV81M_SRC_FIPS202_NATIVE_ARMV81M_H