Adds interesting test cases to ML-DSA SigGen #1525
Conversation
|
Chris, these vectors do not work any more with the final FIPS 204 keygen definition as the seed turns them into different keys. I have converted these edge case test cases by generating the key pairs. The expected signature value is left unchanged. To use these edge case test vectors, simply invoke them with the ML-DSA.Sign_internal algorithm defined in FIPS 204. The generated signature would now need to be identical to the signature with the edge case test vector. See [1] for the updated test vector. Perhaps you want to update this pull request to replace the seed with the actual keys. |
|
How is the expected signature left unchanged? A different key pair should lead to a different signature? The test cases use a property of the key to ensure a higher likelihood of hitting the ct0 error condition during signing. We searched through billions of signatures to find this set of cases. Due to the change in the key I don't think they can be converted, I think we need to perform the search again. A stop-gap would be to generate the "incorrect" keys using the old KeyGen routine, and serve the private key with the messages. Those tests would be valid. To save space on the page, I wanted to just include the key seed. |
|
Am Donnerstag, 22. August 2024, 16:42:40 MESZ schrieb Chris Celi:
Hi Chris,
How is the expected signature left unchanged? A different key pair should
lead to a different signature?
You provided the seed and the expected signature.
That seed was to be used with the pre-FIPS204 keygen. The signature is to be
generated with ML-DSA.Sign_internal.
All I did is simply to generate the key from the seed with the pre-FIPS204
keygen, as this pre-FIPS 204 keygen should not be available any more.
The signature still can be generated with the FIPS 204 mechanism of ML-
DSA.Sign_internal.
The test cases use a property of the key to ensure a higher likelihood of
hitting the ct0 error condition during signing. We searched through
billions of signatures to find this set of cases. Due to the change in the
key I don't think they can be converted, I think we need to perform the
search again. A stop-gap would be to generate the "incorrect" keys using
the old KeyGen routine, and serve the private key with the messages. Those
tests would be valid. To save space on the page, I wanted to just include
the key seed.
That should still be all testable as only the siggen part is truly tested, not
the keygen, right?
Ciao
Stephan
|
|
OK, you provided the full key pair instead of the seed. This is good. |
No description provided.