[cryptotest] Add ML-KEM tests using Wycheproof and ACVP test vectors

[mkannwischer]

• Depends on [cryptotest] Test AES-KWP against CAVP and Wycheproof testvectors #214 (for the updated Wycheproof testvectors)

Adds ML-KEM to the cryptotest framework with support for all three
parameter sets (ML-KEM-512, ML-KEM-768, ML-KEM-1024) and four
test operations:

• keygen: deterministic key generation from seed (d||z)
• encaps: deterministic encapsulation with provided ek and
  randomness m
• decaps: decapsulation with provided dk and ciphertext
• keygen_decaps: keygen followed by decapsulation (Wycheproof
  mlkem_*_test.json provides seed + ciphertext, firmware generates
  keys then decapsulates)

Test vector sources:

• Wycheproof (C2SP): keygen_seed_test, encaps_test,
  semi_expanded_decaps_test, and the combined test.json
  for all three parameter sets (1695 vectors)
• ACVP (NIST ACVP-Server v1.1.0.41): keyGen and encapDecap
  internalProjection files (240 vectors)

All 1935 test vectors from both sources are covered.

ACVP encapsulationKeyCheck and decapsulationKeyCheck tests are
mapped to encaps and decaps operations respectively: the cryptolib
does not expose dedicated key validation functions, but
encapsulate_derand and decapsulate perform internal checks (FIPS 203
modulus check, hash consistency) that reject invalid keys. We test
this by calling the operations with the provided (possibly invalid)
key and dummy randomness/ciphertext, and verifying success/failure.

The biggest challenge here is that ML-KEM data structures are
large (ek up to 1568B, dk up to 3168B).
Naively serializing these as ujson output arrays results in a test
runtime of >2.5 hours - the vast majority of which appears to be
spent on JSON encoding in the firmware.
To address this, we instead compute the SHA3-256 hash of the
outputs in the firmware and the parses.
This brings down test time for everything to ~265s.

[mkannwischer]

I have reworked this PR a bit making it easier to also accommodate ML-DSA in #223.
What I wasn't aware of before is that if I statically allocate a buffer in mlkem.c this will be allocated in all cryptotests. This PR is now changed so this actually gets allocated in firmware.c and passed to the ML-KEM handlers as an argument. This way, if multiple tests need large buffers, we can use a union (as I have done in the ML-DSA test).

[jadephilipoom]

LGTM, thanks Matthias!

[jadephilipoom]

CI failure looks unrelated and perhaps like the FPGA may have gotten disconnected, I'd suggest just rerunning it to see if it works.

[mkannwischer]

CI failure looks unrelated and perhaps like the FPGA may have gotten disconnected, I'd suggest just rerunning it to see if it works.

I have done that twice now, but it does not seem to help.
Do you know what I am doing wrong?

[jadephilipoom]

Looks like a broader CI issue unfortunately :/