The second assurance is correctness under all rejection paths. Within ML-DSA sigGen, i.e., in Algorithm 7 `ML-DSA.Sign_internal()`, the algorithm enters a loop until a valid signature is found. The loop contains four potential reasons to reject a candidate signature: if the z infinity norm is too large, if the r infinity norm is too large, if there are too many hints in h, or if the ct0 infinity norm is too large. These conditions occur at various rarities that can make it difficult to test each error condition with randomized testing. If an implementation adheres strictly to the pseudocode in Algorithm 7 `ML-DSA.Sign_internal()` <<FIPS204>>, the following table provides helpful known answer tests that trigger each rejection case exactly once. If the implementation varies from the psuedocode, it would be prudent to use a debugger or other tooling to ensure that all rejection cases are triggered by testing. To save on space, the table will provide the seed used to generate the key pair, a hash of the keys, SHA2-256(pk || sk), and a hash of the resulting signature, SHA2-256(sig). All cases are defined using the deterministic signature method, Algorithm 7 `ML-DSA.Sign_internal()`. Note that the ct0 infinity norm check only applies to ML-DSA-44. This condition is not possible on the other security levels. Thanks to Qinglai Xiao and Mike Hamburg (Rambus Inc) for providing code to generate these test cases; more information on their technique is available on the NIST PQC-Forum <<PQCForum>>.
0 commit comments