ACVP: Support FIPS203-tr1 encapDecap (v1.1.0.43) - #1811
Draft
mkannwischer wants to merge 2 commits into
Draft
Conversation
Contributor
CBMC Results (ML-KEM-1024)Full Results (191 proofs)
|
Contributor
CBMC Results (ML-KEM-512)Full Results (191 proofs)
|
Contributor
CBMC Results (ML-KEM-768)Full Results (191 proofs)
|
mkannwischer
force-pushed
the
acvp-fips203-tr1
branch
from
July 25, 2026 13:03
600407e to
c64f565
Compare
The FIPS203-tr1 encapDecap revision adds keyFormat 'seed'/'expanded' groups: the decapsulation key may be supplied as a seed (d||z) to expand rather than as the expanded dk. Add a decode_dk() entry point to the ACVP harness accepting either dk=HEX or seed=HEX (expanding the seed via crypto_kem_keypair_derand), and route the decapsulation function through it. keyFormat is inspected per group, so the client copes whether or not a given file carries it. decode_dk is MLK_NOINLINE so its keyGen scratch stays out of main's stack frame, which under -fsanitize=undefined would otherwise overflow AVR RAM. Download and run the ML-KEM-encapDecap-FIPS203-tr1 vectors when the version ships them (v1.1.0.43+); keep the base FIPS203 dataset. Two quirks in the v1.1.0.43 sample vectors are worth recording: - decapsulationKeyCheck cases carry only a tcId with no dk, yet their expected results are a non-trivial mix of pass and fail, so they cannot be reproduced offline. The client drops decapsulationKeyCheck cases that lack a key, from prompt and expected alike; they run normally again once a key is present. This is a known upstream sample bug (usnistgov/ACVP-Server#459), where the maintainers confirm keyFormat there should be 'expanded' with the dk provided. - The base ML-KEM-encapDecap-FIPS203 file also gained keyFormat at v1.1.0.43, whereas for ML-DSA only the -tr1 revision carries it. This looks like an unintended regeneration of the base file; the per-group handling above keeps the client correct whether or not it is fixed. Bump the default ACVP version to v1.1.0.43 and roll the CI matrix forward to the three latest revisions. Signed-off-by: Matthias J. Kannwischer <matthias@zerorisc.com>
The test vectors added in the last commit lead to a stack overflow on AVR for ML-KEM-1024. This commit ports the AVR setup from mldsa-native, including its increase in RAM to nearly 64K. This fixes the AVR test, and also makes future maintenance of the AVR backend across mlkem-native and mldsa-native simpler. - nix/avr: RAMEND 0x81FF -> 0xFFFF, EEPROM E2END 0x3FFF -> 0x7FFF - platform.mk: __stack=0x81FF -> __DATA_REGION_LENGTH__=0xFC00, so .data/.bss grow up from 0x0200 with the stack set at runtime - avr_wrapper.c / init7.S / exec_wrapper.py: place the argc/argv block at the top of RAM and set SP just below it, giving the largest possible stack Keeping this identical (modulo naming) to mldsa-native lets both projects share one AVR baremetal harness, so fixes port across as a prefix diff. Signed-off-by: Hanno Becker <beckphan@amazon.co.uk>
mkannwischer
force-pushed
the
acvp-fips203-tr1
branch
from
July 26, 2026 17:32
c64f565 to
d9f71df
Compare
|
|
||
| Some ML-KEM sample vectors omit dk for these cases; the check cannot run | ||
| without a key. Removed from prompt and expected so the comparison stays | ||
| consistent, and runs normally once a key is present. |
Contributor
There was a problem hiding this comment.
We should open an issue to remove this once upstream is fixed
| { | ||
| unsigned char ek[CRYPTO_PUBLICKEYBYTES]; | ||
| unsigned char coins[2 * MLKEM_SYMBYTES]; | ||
| if (decode_hex("seed", coins, sizeof(coins), arg) != 0) |
Contributor
There was a problem hiding this comment.
NB: We should align this with mldsa-native, where decode_hex operates in-place.
| { | ||
| return 1; | ||
| } | ||
| if (crypto_kem_keypair_derand(ek, dk, coins) != 0) |
Contributor
There was a problem hiding this comment.
This relates to pq-code-package/mldsa-native#1272. It would be nice to avoid the unused ek buffer here.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The FIPS203-tr1 encapDecap revision adds keyFormat 'seed'/'expanded' groups: the decapsulation key may be supplied as a seed (d||z) to expand rather than as the expanded dk.
Add a decode_dk() entry point to the ACVP harness accepting either dk=HEX or seed=HEX (expanding the seed via crypto_kem_keypair_derand), and route the decapsulation function through it. keyFormat is inspected per group, so the client copes whether or not a given file carries it. Download and run the ML-KEM-encapDecap-FIPS203-tr1 vectors when the version ships them (v1.1.0.43+); keep the base FIPS203 dataset.
Two quirks in the v1.1.0.43 sample vectors are worth recording:
decapsulationKeyCheck cases carry only a tcId with no dk, yet their expected results are a non-trivial mix of pass and fail, so they cannot be reproduced offline. The client drops decapsulationKeyCheck cases that lack a key, from prompt and expected alike; they run normally again once a key is present. This is a known upstream sample bug (Encoding issue for ML-KEM decapsulationKeyCheck tests in v1.1.0.43 usnistgov/ACVP-Server#459), where the maintainers confirm keyFormat there should be 'expanded' with the dk provided.
The base ML-KEM-encapDecap-FIPS203 file also gained keyFormat at v1.1.0.43, whereas for ML-DSA only the -tr1 revision carries it. This looks like an unintended regeneration of the base file; the per-group handling above keeps the client correct whether or not it is fixed.
Bump the default ACVP version to v1.1.0.43 and roll the CI matrix forward to the three latest revisions.