Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update ML-KEM vectors to final FIPS-203 version #13

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

Aurum-Vale
Copy link

@Aurum-Vale Aurum-Vale commented Sep 19, 2024

This PR updates the test vectors for "accumulated" cases and the "unlucky samples" cases.
I verified those vectors only with my own implementation: although I'm confident in those enough to submit this PR, the vectors should be tested with other implementations to better assert their correctness.

The modulus and strcmp cases have not been modified. Even if the keys used in those cases probably cannot be generated from valid seeds anymore, it is not important for the purpose of those tests.

I have not regenerated the "intermediate" test cases because of how tedious it is to imitate the current output format and I wanted to prioritize the other test vectors. If this is requested and it's fine to not exactly imitate the format, I can come up with something.

EDIT:
I forgot to mention that the new unlucky vectors have all been bruteforced and verified to ensure they draw at least 384 samples. More precisely:

  • ML-KEM-512: 384 samples (576 bytes)
  • ML-KEM-768: 387 samples (581 bytes)
  • ML-KEM-1024: 386 samples (579 bytes)

@rben-dev
Copy link

rben-dev commented Dec 27, 2024

Hi @Aurum-Vale,

I actually opened an issue #15 before seeing this PR: thanks for working on this update of the ML-KEM accumulated vectors.

I confirm that I have validated the results of the 10k and 1M accumulated tests with my implementation of the finalized FIPS-203 standard for ML-KEM-512, ML-KEM-768, ML-KEM-1024: although this might not be enough for a a formal validation, I guess that this PR should be merged after review (I must precise thought that I have not tested the new unlucky samples yet).

I also precise that for the 10k case of the three variants, I have the same textual output as the reference implementation (the 1M tests produce a too large file to be easily tested).

For the reviewers: what would be missing for merging this very useful PR now that the standard has been finalized?

Regards,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants