Add libcrux-ml-kem and libcrux-ml-dsa entries

[ctz]

This is for cryspen/libcrux#1220 but also affects libcrux-ml-kem.

Ideally these can be updated by the maintainers if they do analysis on the relationship between the incorrect signatures/shared secrets and the correct output.

[djc]

@franziskuskiefer hey, we usually ask maintainers to confirm that they're okay with publishing an advisory. How do you feel about having this? Any additions to the text?

[pinkforest]

It seems to be (also) toolchain / build configuration thing, e.g. only stable-aarch64-unknown-linux-musl cryspen/libcrux#1220 (comment) given musl one doesn't expose target_feature="sha3" via build implicitly w/o -Ctarget_cpu="native" / -Ctarget-feature=+sha3 given explicitly per bjorn3 (cryspen/libcrux#1220 (comment))

so I would say it's limited to a particular aarch64 toolchain/s (used implicitly) and/or build configurations (used explicitly) that don't feature SHA3 instruction set either enabled, available or assumed (w/o cpu=native) like was in the case of alpine musl toolchain.

[jschneider-bensch]

Thank you for creating the issue. We have the following suggestion for the text:

On platforms without the core::arch::aarch64::vxarq_u64 intrinsic, an unverified fallback in libcrux-intrinsics v0.0.3 passed incorrect arguments and produced wrong results. This corrupted SHA-3 digests and caused libcrux-ml-kem and libcrux-ml-dsa to sample incorrectly, yielding incorrect shared secrets and invalid signatures.

The issue has been fixed in v0.0.4.

[djc]

So maybe this should be an advisory for libcrux-intrinsics instead?