Add libcrux-intrinsics entry

[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?

[jschneider-bensch]

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

I agree, that makes sense, since the bug was in that crate.

[pinkforest]

On platforms without

It would be correct to say that .. or upon compilation when using either a toolchain that does not by default provide SHA3 instruction set enabled or when the SHA3 instruction set was explicitly disabled ..

Given even with platforms that support SHA3, the compiler doesn't make assumption through the toolchain (as was the case in linux / musl toolchain) that CPU has such instruction set/s available and where it has to be enabled explicitly.

This was the case for me running (in a platform that supports all those features) didn't enable in the virtual host through the toolchain used.

Work/around for the aarch64 platforms that are SHA3 capable at runtime, people could always enable SHA3 manually if supported at the runtime environment per bjorn3.

People who compiled their projects using the unaffected CPU & target_features with SHA3 enabled are not affected.

[ctz]

Updated to target the right crate and incorporated the text from above.

I don't think this advisory is a good place to teach people about target_feature, or the gate on the relevant intrinsic, or the default availability of the sha3 target_feature for different targets. I think the rust reference does a better job on those topics.