pq_crypto 0.6.4 → 0.6.6

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

@@ -2,10 +2,7 @@
 
 # mlkem-native
 
-![Base tests](https://github.com/pq-code-package/mlkem-native/actions/workflows/base.yml/badge.svg)
-![Extended tests](https://github.com/pq-code-package/mlkem-native/actions/workflows/ci.yml/badge.svg)
-![Proof: CBMC](https://github.com/pq-code-package/mlkem-native/actions/workflows/cbmc.yml/badge.svg)
-![Proof: HOL-Light](https://github.com/pq-code-package/mlkem-native/actions/workflows/hol_light.yml/badge.svg)
+![CI](https://github.com/pq-code-package/mlkem-native/actions/workflows/all.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)
 
@@ -102,7 +99,7 @@ mlkem-native currently offers the following backends:
 If you'd like contribute new backends, please reach out or just open a PR.
 
 Our AArch64 assembly is developed using the [SLOTHY](https://github.com/slothy-optimizer/slothy) superoptimizer, following the approach described in the SLOTHY paper[^SLOTHY_Paper]:
-We write 'clean' assembly by hand and automate micro-optimizations (e.g. see the [clean](dev/aarch64_clean/src/ntt_aarch64_asm.S) vs [optimized](dev/aarch64_opt/src/ntt_aarch64_asm.S) AArch64 NTT).
+We write 'clean' assembly by hand and automate micro-optimizations (e.g. see the [clean](dev/aarch64_clean/src/mlkem_ntt_aarch64_asm.S) vs [optimized](dev/aarch64_opt/src/mlkem_ntt_aarch64_asm.S) AArch64 NTT).
 See [dev/README.md](dev/README.md) for more details.
 
 ## Test Vectors
@@ -168,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
@@ -217,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,216 @@
 [//]: # (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
+===================
+
+Release notes
+-------------
+
+mlkem-native v1.3.0 adds configuration options to control which KEM operations
+are included in a build. It also improves AArch64 feature detection and runtime
+dispatch, and introduces ABI compliance checks for assembly backends. Embedded
+testing now uses Zephyr across a broader range of Arm targets, while assembly
+namespacing and source naming improve integration with projects such as AWS-LC.
+
+See the full change log here:
+https://github.com/pq-code-package/mlkem-native/compare/v1.2.0...v1.3.0
+
+What's next? mlkem-native v2
+----------------------------
+
+This is expected to be the last release prior to mlkem-native v2. Between
+v1.3.0 and v2, breaking changes to the `main` branch will be made.
+
+Long-Term Support
+-----------------
+
+`release/v1.3` will act as a support branch until 6 months after
+mlkem-native v2 is established. 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 within 6 months of its release, please contact us to discuss
+a potential extension of the support schedule.
+
+What's New
+----------
+
+### Configuration / API
+
+- Add `MLK_CONFIG_NO_KEYPAIR_API`, `MLK_CONFIG_NO_ENCAPS_API`, and
+  `MLK_CONFIG_NO_DECAPS_API`, allowing unused KEM operations and their internal
+  dependencies to be excluded. All non-empty API combinations are covered in
+  CI. ([#1787](https://github.com/pq-code-package/mlkem-native/pull/1787))
+- Gate the AArch64 arithmetic and FIPS-202 backends on compile-time NEON
+  availability and the new `MLK_SYS_CAP_NEON` runtime capability. Integrators
+  can now fall back to portable C on AArch64 systems without usable NEON.
+  ([#1805](https://github.com/pq-code-package/mlkem-native/pull/1805),
+  [#1809](https://github.com/pq-code-package/mlkem-native/pull/1809))
+- Add `MLK_SYS_AARCH64_FAST_SHA3` to select the pure-Neon Armv8.4-A SHA3
+  implementation on CPUs with sufficient SHA3 execution capacity, including
+  Graviton5. ([#1784](https://github.com/pq-code-package/mlkem-native/pull/1784))
+
+### Assurance / Testing
+
+- Fix deterministic-only builds using `MLK_CONFIG_NO_RANDOMIZED_API`, including
+  test, example, and stack-measurement coverage.
+  ([#1816](https://github.com/pq-code-package/mlkem-native/pull/1816))
+- Upgrade CBMC to v6.10.0, the newest release of CBMC including the fix
+  [cbmc/#9011](https://github.com/diffblue/cbmc/pull/9011) to the Z3 soundness
+  issue [z3/#9550](https://github.com/Z3Prover/z3/issues/9550). mlkem-native v1.2
+  had pinned CBMC to an unstable version between v6.9 and v6.10 which already
+  included that fix.
+  ([#1762](https://github.com/pq-code-package/mlkem-native/pull/1762))
+- Add assembly ABI checkers for AArch64, x86_64 SysV, ppc64le ELFv2, and
+  Armv8.1-M MVE. The checkers verify preservation of callee-saved registers and
+  run as part of the standard test suite.
+  ([#1135](https://github.com/pq-code-package/mlkem-native/pull/1135))
+- Add Zephyr-based testing for QEMU Cortex-M3, M4, M7, M33, and M55 targets,
+  replacing the previous custom MPS baremetal platforms. Add test and benchmark
+  support for the NUCLEO-N657X0-Q board.
+  ([#1750](https://github.com/pq-code-package/mlkem-native/pull/1750),
+  [#1547](https://github.com/pq-code-package/mlkem-native/pull/1547))
+- Strengthen HOL Light tooling with cross-architecture proof execution and
+  checks that every expected theorem is present
+  ([#1634](https://github.com/pq-code-package/mlkem-native/pull/1634))
+- Strengthen Wycheproof validation by checking newly specified fields, rejecting
+  unknown schema fields, and tracking upstream vector changes.
+  ([#1801](https://github.com/pq-code-package/mlkem-native/pull/1801))
+- Extend Windows MSVC coverage to allocation-failure, RNG-failure, and
+  Wycheproof tests ([#1738](https://github.com/pq-code-package/mlkem-native/pull/1738))
+- Add emulated testing on x86_64 without AVX2.
+  ([#1753](https://github.com/pq-code-package/mlkem-native/pull/1753))
+- Correct decapsulation stack measurements, which previously returned before
+  the full operation and understated peak stack use by around 10%.
+  ([#1823](https://github.com/pq-code-package/mlkem-native/pull/1823))
+
+### Integration / Upgrade Notes
+
+- Namespace assembly-local labels with an `mlk_` prefix, preventing collisions
+  when mlkem-native and other projects are combined into one assembly unit.
+  ([#1813](https://github.com/pq-code-package/mlkem-native/pull/1813))
+- Rename backend assembly files to be self-identifying. Arithmetic assembly
+  filenames now use an `mlkem_` prefix. Downstream build systems with explicit
+  source lists must update those paths.
+  ([#1821](https://github.com/pq-code-package/mlkem-native/pull/1821))
+- Move context-parameter support into the new `mlkem/src/context.h`; downstream
+  source manifests must include this file.
+  ([#1768](https://github.com/pq-code-package/mlkem-native/pull/1768))
+
 mlkem-native v1.2.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
@@ -202,14 +188,12 @@
 #undef MLK_COMMON_H
 #undef MLK_CONCAT
 #undef MLK_CONCAT_
-#undef MLK_CONTEXT_PARAMETERS_0
-#undef MLK_CONTEXT_PARAMETERS_1
-#undef MLK_CONTEXT_PARAMETERS_2
-#undef MLK_CONTEXT_PARAMETERS_3
-#undef MLK_CONTEXT_PARAMETERS_4
 #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
@@ -311,6 +295,14 @@
 #undef mlk_poly_frommsg
 #undef mlk_poly_tobytes
 #undef mlk_poly_tomsg
+/* mlkem/src/context.h */
+#undef MLK_CONTEXT_H
+#undef MLK_CONTEXT_PARAMETERS_0
+#undef MLK_CONTEXT_PARAMETERS_1
+#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
@@ -377,6 +369,7 @@
 #undef MLK_SYSV_ABI_SUPPORTED
 #undef MLK_SYS_AARCH64
 #undef MLK_SYS_AARCH64_EB
+#undef MLK_SYS_AARCH64_NEON
 #undef MLK_SYS_APPLE
 #undef MLK_SYS_ARMV81M_MVE
 #undef MLK_SYS_BIG_ENDIAN
@@ -463,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)
 /*
@@ -488,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
@@ -504,12 +497,10 @@
 #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
-#undef mlk_keccak_f1600_x4_state_extract_bytes
-#undef mlk_keccak_f1600_x4_state_xor_bytes
 /* mlkem/src/fips202/native/armv81m/src/fips202_native_armv81m.h */
 #undef MLK_FIPS202_NATIVE_ARMV81M_SRC_FIPS202_NATIVE_ARMV81M_H
 #undef mlk_keccak_f1600_x4_mve_asm