portable implementation in incremental API generate state inconsistent with SIMD implementation

[GuuJiang]

Description

The SIMD256 (AVX2) branch of encapsulate1 and encapsulate2 generates incorrect results compared to the SIMD128 (NEON) and portable branches.

Root Cause

The root cause is incorrect endianness handling in the from_bytes and to_bytes methods in libcrux-ml-kem/src/vector/avx2.rs. These functions do not properly swap bytes when converting between byte arrays and SIMD vectors.

Impact

The issue is not obviously apparent if encapsulate1 and encapsulate2 always run on the same machine. In this case, the endianness error cancels out during the two calls, and the implementation still generates the correct key and message compared to the non-incremental version.

However, some scenarios like SPQR (Sparse Post-Quantum Ratchet) choose to run encapsulate1 and encapsulate2 on different machines. This leads to incorrect results if one party enters the SIMD256 branch and the other enters the SIMD128 or portable branch.

[GuuJiang]

The PR1276 fixes this issue

[GuuJiang]

Follow up

After further investigation, I discovered that the initial assessment was incorrect. The issue is not with the AVX2 implementation, but rather with the portable implementation being inconsistent with the SIMD versions (AVX2 and NEON).

While the original issue mentions scenarios like SPQR where encapsulate1 and encapsulate2 might run on different machines, in practice (e.g., Signal's implementation), these functions always run on the same machine. The state is internal data that is not transmitted to other parties. And the endianness error cancels out, so the final ciphertext (ct1 and ct2) remains correct.

However, due to issue #1201, when running on Apple Silicon, there is a possibility that the same machine may enter different implementation branches during the computation of ct1 and ct2 and leading to incorrect final results.

The PR has updated to fix the portable implementation instead.