Add ML-KEM and ML-DSA support

[aidangarske]

ML-KEM (FIPS 203) and ML-DSA (FIPS 204) via wolfSSL backend.

Algorithms: ML-KEM-512/768/1024, ML-DSA-44/65/87 hybrid schemes supported now as well

Opt-in: ./scripts/build-wolfprovider.sh --enable-pqc (adds --enable-mlkem --enable-mldsa to wolfSSL).

• PQC is not auto detected its only enabled when specifically built.
• Ability to enable either algo only or both
• Reject pqc with debian bookworm build could test with trixie eventually
• ML-DSA CertificateVerify signing and verification both work in TLS
• wolfProvider now generates ML-DSA certs
• wolfProvider X509 ML-DSA sigs are valid
• osp integration with https://github.com/open-quantum-safe/oqs-demos/tree/main/nginx using ML-DSA and hybrid schemes and tested in CI

Validation: three independent paths cross-checked, all pass.

• Internal unit tests (11 functions x 3 levels = 33 assertions) in make test
• wolfProvider <-> OpenSSL 3.6+ default provider (12 cross-pairs)
• wolfProvider <-> wolfSSL direct wc_* API (12 cross-pairs)
• entire openssl mldsa mlkem test suite exercised in CI for full compatibility
• Interop tests with hybrid in place as well

CI: new wolfssl-versions-pqc.yml runs three matrix rows - pre-PQC wolfSSL, latest stable, master -- and the three-way interop validator on the PQC-enabled rows.

• Put floor to 3.6 where mldsa apis solid and 5.9.2 for pqc in general; added note that we could do lower than 3.6 if reuqested but offically support and test those higher versions

supplemental PR for interop test in wolfCrypt: wolfSSL/wolfssl#10603

Test plan

• make test passes (all 11 PQC tests + existing suite)
• ./test/pqc_interop.test -- ALL PASS (24 cross-pairs)
• Build against pre-PQC wolfSSL: PQC code paths skip, make test clean
• CI green on all three matrix rows

[Frauschi]

Some smaller findings. The biggest "issue" imo is the usage of the now old ML-DSA API instead of the new one. But moving this to the new one should be easy.

[Frauschi]

Jenkins retest this please

[aidangarske]

Jenkins retest this please

[Frauschi]

LGTM

[SparkiDev]

Use a digest object that is updated with the data.
Should be using wc_MlDsaKey_SignCtxHash() and wc_MlDsaKey_SignCtxHashWithSeed() and wc_MlDsaKey_VerifyCtxHash().
Leave the random generation to the MlDsa if possible - that is use different API when random is test random.
wc_MlDsaKey_SignMuWithSeed() - Mu contains the hash.

[aidangarske]

I think I got the streaming sorted. The pure path doesn't buffer anymore; it runs the message straight through wc_Shake256_Update into mu and signs with SignMuWithSeed / verifies with VerifyMu (your "Mu contains the hash" route). SignCtxHash is in there too, just on the pre-hash path where it belongs.

I couldn't use SignCtxHash for the pure path though it's HashML-DSA and native OpenSSL rejects those sigs when it verifies pure ML-DSA, which is exactly what TLS and X509 do so it blows up interop (confirmed against 3.6.2).

Only thing I couldn't land is leaving the random to MlDsa on the streaming path. SignMuWithSeed forces a seed and there's no rng variant, so for now I generate it on the wolfProvider side (same DRBG, just one layer out). If you're open to adding a wc_MlDsaKey_SignMu(key, sig, sigLen, mu, muLen, rng) the mu version of SignCtx's rng path I could rip the seed gen out and hand it back to MlDsa.

[aidangarske]

jenkins retest this please