gate ML‑KEM/ML‑DSA specific SHA3 APIs behind optional features (#1532)

[Arul-Sujith]

This PR gates the ML‑KEM and ML‑DSA specific SHA3 APIs behind optional Cargo features (mlkem and mldsa). The change cleans up the public API surface of libcrux-sha3 by hiding specialized incremental functions (e.g., x4::incremental, x2::incremental, and portable::incremental) unless one of the new features is enabled.

Changes

• Added mlkem and mldsa optional features to crates/algorithms/sha3/Cargo.toml.
• Guarded ML‑KEM/ML‑DSA specific modules (avx2::x4, neon::x2, portable::incremental) with #[cfg(any(feature = "mlkem", feature = "mldsa"))].
• Updated dependent crates (libcrux-ml-kem, libcrux-ml-dsa, ctgrind-test) to enable these features where needed.
• Modified unit tests and benchmarks to be conditionally compiled under the same feature gate.

Fixes #1532

[robinhundt]

Thanks for the PR! We recently added a policy on LLM-assisted submissions.

Did you use any AI tooling? If yes, to what capacity?

[Arul-Sujith]

Yes, I used an LLM to assist with this PR. Primarily to understand codebase, apply fixes, and generate PR descriptions.

Then manually review the fixes and run tests. I will make sure to include this disclosure upfront in future PR descriptions.

[robinhundt]

Is there a reason for this PR being stacked on top of #1541 ?

[Arul-Sujith]

That was an accident! I forgot to branch off of main when starting this SHA3 work, so it included the commits from my previous PR. There is no intentional dependency between them. I have rebased this branch cleanly onto main to un-stack it!

[robinhundt]

Thanks for the PR!

I don't think it is needed to have two features. In this PR, the mlkem and mldsa features are only ever used together in sha3. The cargo features should not be named by who is using them, but by what they enable. In this case, I think one "incremental" feature makes more sense, as this is the main thing consumed by ml-kem and ml-dsa.

Also note that when adding a new cargo feature, the CI tests need to be adapted so the now cfg-gated code is actually tested in CI.

It seems that kmac is also using the incremental API (see CI failure), so it also needs to enable the sha3 cargo feature.

[robinhundt]

blocking: Please only cfg exclude those tests which test the functions gated by these features. As it is, none of these tests, even the portable implementation ones, are executed if neither the mlkem or mldsa feature is enabled.

[robinhundt]

blocking: See cavp tests.

[robinhundt]

nit: The APIs gated by these features are currently not tested in the ctgrind-test crate, so no need to enable them here.

[robinhundt]

blocking: I think this can just be a single feature, e.g. "incremental".

[robinhundt]

Ah, one more thing. I think with the cargo feature for the incremental sha3 APIs, this will probably break the hax extraction for libcrux-ml-dsa and libcrux-ml-kem. You probably need to include the feature in the cargo hax calls in the hax.{py,sh} script in ml-dsa/ml-kem so that it properly extracts.

Setting up the hax toolchain is a bit of a hassle. I think the easiest option is to use the dev-shell in the flake.nix (building it the first time takes a while, as it is quite large).