feat: Post-Quantum signature support — ML-DSA (FIPS 204) + ML-KEM (FIPS 203)

[cschanhniem]

Feature request: Post-quantum cryptographic primitives

Now that NIST has standardized FIPS 204 (ML-DSA / Dilithium) and FIPS 203 (ML-KEM / Kyber), adding post-quantum support to rscrypto would align the crate with the emerging PQC landscape. Several Rust crypto crates (pqcrypto-*, ml-kem, libcrux) already have implementations, but none under rscryptos "one coherent primitive stack" model.

Why rscrypto is well-positioned

1. no_std + WASM support — PQC primitives are especially valuable in embedded and WASM contexts (IoT firmware signing, WASM module attestation). rscryptos existing no_std / WASM target model maps directly.
2. zero default deps — Introducing PQC via the rscrypto API surface means projects get lattice-based KEM/signatures under the same default-features = false discipline, without pulling in a separate libcrux or pqcrypto-* tree.
3. Benchmarking infrastructure — rscryptos existing CI benchmark harness (with per-primitive scorecards) would immediately show ML-KEM vs. ECDH and ML-DSA vs. Ed25519 overhead, helping users make informed trade-offs.

Suggested scope

Phase 1: ML-KEM (Kyber, FIPS 203)

• rscrypto::kem::MlKem512 / MlKem768 / MlKem1024
• encapsulate(&pk) → (ciphertext, shared_secret)
• decapsulate(&sk, ciphertext) → shared_secret
• Key generation, serialization, no_std-compatible randomness interface

Phase 2: ML-DSA (Dilithium, FIPS 204)

• rscrypto::sign::MlDsa44 / MlDsa65 / MlDsa87
• sign(&sk, message) → signature
• verify(&pk, message, signature) → Result
• Deterministic vs. hedged signing (FIPS 204 §5.2)

Implementation considerations

• Portable Rust first — lattice operations are polynomial-ring arithmetic in Zq[X]/(X^n+1); a clean portable impl is the reference, with AVX2/Neon acceleration added later (existing rscrypto pattern).
• Constant-time — ML-KEM and ML-DSA both require rejection sampling and bit packing that must be constant-time to avoid side channels. rscryptos existing portable-only feature would provide the audit-safe path.
• NIST KAT vectors — official ACVP test vectors exist for both standards; integration-testing against them is feasible.
• Crate scope — these would live under a pqc feature flag (or ml-kem, ml-dsa leaf features), keeping the full feature including them without pulling them in unconditionally.

References

• FIPS 203 (ML-KEM)
• FIPS 204 (ML-DSA)
• libcrux ML-KEM audit (formally verified Rust)
• rscrypto existing benchmark harness: benches/ directory in repo

Would this fit the rscrypto roadmap? Happy to help scope the API further.

[loadingalias]

Hey @cschanhniem. Thanks for taking the time. Yeah, your feature-request fits the roadmap. I'm working on it as we speak and have been for a while.

As of today (06/19), ML-KEM is implemented, but not release ready yet. I can't cut that release until I can validate constant-time and perf. I have been working on it for a LONG time and have ID'd the last major blocker (side-channel issues and perf issues on IBM Z).

Currently, this is what's done and will ship in v0.6.0 (tonight, I hope, but maybe tomorrow):
• MlKem512, MlKem768, and MlKem1024 are implemented behind the ml-kem feature.
• The API uses FIPS 203 naming: encapsulation keys, decapsulation keys, ciphertexts, shared secrets, generate_keypair, encapsulate, and decapsulate.
• NIST ACVP/FIPS 203 vectors, property tests, implicit-rejection tests, parser/validation tests, and prepared-key paths are covered.
• Constant-time work is still being checked, as mentioned briefly earlier. The impl is "CT-intended" for keygen secret noise, encapsulation coins, decapsulation secret-key material, and implicit rejection, but I do not want to call it final/release ready until the current CI runs are green.
• Bench coverage now includes ML-KEM-512/768/1024 keygen, encapsulation, and decapsulation against libcrux, fips203, RustCrypto, and AWS-LC where available. Benches have ML-KEM winning 44/81 comparisons agianst the fastest-external competitor/s I can find. My IBM Z impl is getting hammered and it's dragging those numbers way down. I should have this ironed out in the next 24-48 hours. This obviously, like other primitives, includes the no-std/wasm portable path. In fact, the portable ML-KEM is already unbeaten against the competitors. The issues are currently ASM, SIMD, arch-specific kernel impls that aren't sound just yet.

My own roadmap/plan places ML-DSA-65 first, then 44/87 once the core is stable, w/ deterministic/randomized signing modes, strict encodings, FIPS 204 vectors, malformed-input tests, CT review, fuzzing, and benchmark rows. It's going to take me a little while, though.

For now, for today/tomorrow, I’m focused on getting ML-KEM correct, measured, and side-channel resistant before expanding the PQC surface. I appreciate the time/energy to write the Issue here.

[loadingalias]

Hey @cschanhniem, I've just release v0.6.0 - it includes the ML-KEM primitives. It does not include ML-DSA. I will continue working, but ML-DSA will definitely take longer. I need it, too... so it will start immediately, though.

Let me know what you think and if you identify issues!