ML-DSA and SLH-DSA External Interface Test Vectors
Celi, Christopher T. (Fed)
Hi all,
The CAVP is wrapping up work on adding testing for the external interfaces for SLH-DSA. For completeness, there was a fix to the ML-DSA testing, so those files will also be updated. The compressed files are too large to upload through email.
We are planning to push this out to our Demo ACVTS next week. The algorithms will be available for validation testing at the earliest, one week after that. In general we provide pre-generated vector sets for all NIST-approved algorithms at https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files. Note that we update the repository when we push out to Demo, so the vector sets for ML-DSA and SLH-DSA will not yet be updated.
For brevity, ideally by Thursday 1/16, the GitHub repository will contain the updated JSON files for external interface testing for SLH-DSA and ML-DSA. When it happens, I will update the forum.
As a reminder, there are 4 important JSON files that comprise a vector set.
- Registration.json – Describes the capabilities being tested for a particular cryptographic algorithm.
- Prompt.json – The inputs the implementation must use. They are broken out into test cases, an individual test, with many test cases in a test group, a set of test cases with shared properties.
- ExpectedResults.json – The corresponding outputs. These are linked to the prompt.json test cases through the test group identifier (tgId) and test case identifier (tcId).
- InternalProjection.json – Contains everything, inputs and outputs. Again, these are linked through the tgId and tcId.
We also provide specifications on https://pages.nist.gov/ACVP that describe these JSON files in more detail. Of interest to this group will be https://pages.nist.gov/ACVP/draft-livelsberger-acvp-slh-dsa.html#section-6 and https://pages.nist.gov/ACVP/draft-celi-acvp-ml-dsa.html#section-6 that go into detail on the construction of the tests. Note that for ML-DSA the server does not yet perform all the listed tests for signature generation. This is something we are working on to push out soon. The test cases in Section 6 of the ML-DSA specification are valid. They are pulled from the data we will use on the server to generate vector sets in the future.
Feel free to reach out directly with questions. A lot happens on the pqc-forum and I’m not the best at monitoring it.
Thanks,
Chris Celi
CAVP Program Manager
Markku-Juhani O. Saarinen
Thanks for uploading the updated test vectors yesterday/today! Everything seems well; I believe I have managed to parse and verify all of the new JSON test vectors.
An anecdote: To pass all 360 signature tests for ML-DSA, one need to support four signature APIs: ML-DSA.Sign(), HashML-DSA.Sign() (with 12 different external hash functions), ML-DSA.Sign_internal(), and a variant of HashML-DSA.Sign_internal() that skips line 6 and uses an external mu value. Signature verification naturally also needs similar API features.
SLH-DSA is pretty much the same (with 3 interfaces as "external mu" doesn't apply). The expectation is, of course, not that all implementations would support all of these testable features.I believe most security engineers would agree that they shouldn't!
There were a lot of changes to NIST's own Gen/Vals code when the external interfaces were introduced. I will get around to updating my wrappers NIST's updated C# later. While in the same repo, that code is not a dependency for the self-contained python implementations discussed above.
Celi, Christopher T. (Fed)
For pre-generated vector sets, the repo has been updated: https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files.
Thanks,
Chris Celi
Kris Kwiatkowski
There may be an issue with the KATs. The section 5.4 of FIPS-204 says:
In order to maintain the same level of security strength when the content is hashed at the application level or using HashML-DSA , the digest that is signed needs to be generated using an approved hash function or XOF (e.g., from FIPS 180 [8] or FIPS 202 [7]) that provides at least 𝜆 bits of classical security strength against both collision and second preimage attacks [7, Table 4].
I've reviewed the SigVer KATs for PreHASH-MLDSA (referenced in [1]) and noticed that some KATs require the use of a hash function with a strength weaker than the parameter λ. This results in implementations that would not comply with FIPS-204.
For instance, the KAT with tcId=76 specifies using SHA3-256 to pre-hash a message signed with MLDSA-87. Since the collision resistance of SHA3-256 is 128, while the λ value for MLDSA-87 is 256, this creates a mismatch.
In the case of SigVer, I found the following KATs exhibiting the same issue:
tcId={20, 54, 59, 76, 88}.
Could you confirm if my findings are accurate?
[1] https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files
Kind regards,
Kris
On 15/01/2025 22:00, 'Celi, Christopher T. (Fed)' via pqc-forum wrote:
> > For pre-generated vector sets, the repo has been updated: https:// > github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files. > > > > Thanks, > > Chris Celi > > > > *From: *Markku-Juhani O. Saarinen <mjos....@gmail.com> *Date: > *Wednesday, January 15, 2025 at 3:38 PM *To: *pqc-forum <pqc- > fo...@list.nist.gov> *Cc: *Celi, Christopher T. (Fed) > <christop...@nist.gov> *Subject: *Re: ML-DSA and SLH-DSA > External Interface Test Vectors > > Hi Christopher & CAVP folks, > > > Thanks for uploading the updated test vectors yesterday/today! > Everything seems well; I believe I have managed to parse and verify > all of the new JSON test vectors. > > For those interested: I've updated the fips203.py, fips204.py, > fips205.py implementations and the accompanying test code at https:// > github.com/mjosaarinen/py-acvp-pqc > > > > These particular python implementations were written to closely > mirror the specifications and just need "pycryptodome" as a > dependency. The JSON parsing / testing code is a bit quick-and- > dirty, but I think it has full coverage. There are a lot more tests > now for ML-DSA and SLH-DSA, so testing will take some time > (especially SLH-DSA.). Please see README for more information. > > An anecdote: To pass all 360 signature tests for ML-DSA, one need to > support four signature APIs: ML-DSA.Sign(), HashML-DSA.Sign() (with > 12 different external hash functions), ML-DSA.Sign_internal(), and a > variant of HashML-DSA.Sign_internal() that skips line 6 and uses an > external mu value. Signature verification naturally also needs > similar API features. > > SLH-DSA is pretty much the same (with 3 interfaces as "external mu" > doesn't apply). The expectation is, of course, not that all > implementations would support all of these testable features.I > believe most security engineers would agree that they shouldn't! > > There were a lot of changes to NIST's own Gen/Vals code when the > external interfaces were introduced. I will get around to updating > my wrappers NIST's updated C# later. While in the same repo, that > code is not a dependency for the self-contained python > implementations discussed above. > > > > Cheers, > > -markku > > > > On Monday, January 13, 2025 at 4:26:29 PM UTC Celi, Christopher T. > (Fed) wrote: > > Hi all, > > > > The CAVP is wrapping up work on adding testing for the external > interfaces for SLH-DSA. For completeness, there was a fix to the ML- > DSA testing, so those files will also be updated. The compressed > files are too large to upload through email. > > > > We are planning to push this out to our Demo ACVTS next week. The > algorithms will be available for validation testing at the earliest, > one week after that. In general we provide pre-generated vector sets > for all NIST-approved algorithms at https://github.com/usnistgov/ > ACVP-Server/tree/master/gen-val/json-files. Note that we update the > repository when we push out to Demo, so the vector sets for ML-DSA > and SLH-DSA will not yet be updated. > > > > For brevity, ideally by Thursday 1/16, the GitHub repository will > contain the updated JSON files for external interface testing for > SLH-DSA and ML-DSA. When it happens, I will update the forum. > > > > As a reminder, there are 4 important JSON files that comprise a > vector set. > > > > * Registration.json – Describes the capabilities being tested for a > particular cryptographic algorithm. * Prompt.json – The inputs the > implementation must use. They are broken out into test cases, an > individual test, with many test cases in a test group, a set of test > cases with shared properties. * ExpectedResults.json – The > corresponding outputs. These are linked to the prompt.json test > cases through the test group identifier (tgId) and test case > identifier (tcId). * InternalProjection.json – Contains everything, > inputs and outputs. Again, these are linked through the tgId and > tcId. > > > > We also provide specifications on https://pages.nist.gov/ACVP that > describe these JSON files in more detail. Of interest to this group > will be https://pages.nist.gov/ACVP/draft-livelsberger-acvp-slh- > dsa.html#section-6 and https://pages.nist.gov/ACVP/draft-celi-acvp- > ml-dsa.html#section-6 that go into detail on the construction of the > tests. Note that for ML-DSA the server does not yet perform all the > listed tests for signature generation. This is something we are > working on to push out soon. The test cases in Section 6 of the ML- > DSA specification are valid. They are pulled from the data we will > use on the server to generate vector sets in the future. > > > > Feel free to reach out directly with questions. A lot happens on the > pqc-forum and I’m not the best at monitoring it. > > > > Thanks, > > Chris Celi > > CAVP Program Manager > > > > -- You received this message because you are subscribed to the > Google Groups "pqc-forum" group. To unsubscribe from this group and > stop receiving emails from it, send an email to pqc- > forum+un...@list.nist.gov. To view this discussion visit > https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ > CO6PR09MB759160F596798C315425526BF0192%40CO6PR09MB7591.namprd09.prod.outlook.com > <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ > CO6PR09MB759160F596798C315425526BF0192%40CO6PR09MB7591.namprd09.prod.outlook.com? > utm_medium=email&utm_source=footer>.
COSTA Graham
THALES GROUP LIMITED DISTRIBUTION to email recipients
From an implementer perspective, we read this text as informative rather than being something a module needs to enforce.
In particular:
- there is no ‘shall’ statement in the highlighted text and as such, we decided this wasn’t something the standard was requiring vendors to enforce; and
- in the case of ‘external mu’ – there isn’t a direct guaranteed path for the module performing the signature to enforce this.
We’d very much appreciate a clarification from NIST CTG as to whether this is a requirement and needs to be enforced (where possible) by modules or not.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion visit
https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/4ccde8bb-f968-4680-9386-6c020a320318%40amongbytes.com.
John Mattsson
>we read this text as informative rather than being something a module needs to enforce.
>we read this text as informative rather than being something a module needs to enforce.
I agree with this interpretation. NIST has traditionally allowed combining algorithms of different strengths with the result that the resulting strength is the minimum of the algorithms.
(That said I think this is an example of how HashML-DSA creating a lot of complexity. I would be happy if HashML-DSA is not implemented.)
Cheers,
John
Celi, Christopher T. (Fed)
Correct. The CAVP worked with the standards authors on ensuring the test vectors were valid. This was one of my questions. There is no shall statement around using a hash function with at least lambda security strength. You may use any hash function, but you will lower the overall security strength of your signature based on the hash function chosen.
Thanks,
Chris Celi
Blumenthal, Uri - 0553 - MITLL
I agree with this interpretation. NIST has traditionally allowed combining algorithms of different strengths with the result that the resulting strength is the minimum of the algorithms.
(That said I think this is an example of how HashML-DSA creating a lot of complexity. I would be happy if HashML-DSA is not implemented.)
100% agree. HashML-DSA does not make sense to me either, and should not be implemented/supported.
From: 'COSTA Graham' via pqc-forum <pqc-...@list.nist.gov>
Date: Tuesday, 21 January 2025 at 12:46
To: Kris Kwiatkowski <kr...@amongbytes.com>, pqc-...@list.nist.gov <pqc-...@list.nist.gov>
Subject: RE: [pqc-forum] Re: ML-DSA and SLH-DSA External Interface Test Vectors
THALES GROUP LIMITED DISTRIBUTION to email recipients
From an implementer perspective, we read this text as informative rather than being something a module needs to enforce.
In particular:
1. there is no ‘shall’ statement in the highlighted text and as such, we decided this wasn’t something the standard was requiring vendors to enforce; and
2. in the case of ‘external mu’ – there isn’t a direct guaranteed path for the module performing the signature to enforce this.
Kris Kwiatkowski
Thank you for the clarification.
Indeed, the text suggests rather than mandates which hash
function should be used. Nevertheless, I appreciate the
opportunity to discuss this further, as such an approach may
indeed lower the overall security strength of the signature.
Kind regards,
Kris
Massimo, Jake
Hi Chris, PQC-forum,
Also wanted to thank you for this update! For those interested, our implementation of ML-DSA (https://github.com/aws/aws-lc/blob/main/crypto/ml_dsa/ml_dsa.c) in AWS-LC is now updated to include both pure and ExternalMu modes and passes the updated ACVP test vectors.
We’ve supplemented the unofficial ML-DSA KAT vectors from Kris Kwiatkowski (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/63upUY9hYPI) that we perform with vectors extracted from the official NIST ACVP test vectors to provide keyGen, sigGen, and sigVer, KATs from seeds. Examples of the KATs can be found here https://github.com/aws/aws-lc/tree/main/crypto/ml_dsa/kat.
Only one small nit with the draft specification (https://pages.nist.gov/ACVP/draft-celi-acvp-ml-dsa.html) in that the registration properties table use inconsistent names for “signatureInterfaces” and “signatureInterface” (without plural) – tables 6, 8 both refer to “signatureInterfaces” whereas section 6.1.2, tables 13, 14, 15, 16 all refer to the string as “signatureInterface”.
Cheers,
Jake
From: <pqc-...@list.nist.gov> on behalf of "Markku-Juhani O. Saarinen" <mjos....@gmail.com>
Date: Wednesday, January 15, 2025 at 12:40 PM
To: pqc-forum <pqc-...@list.nist.gov>
Cc: "Celi, Christopher T. (Fed)" <christop...@nist.gov>
Subject: [EXTERNAL] [pqc-forum] Re: ML-DSA and SLH-DSA External Interface Test Vectors
|
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. |
--
You received this message because you are subscribed to the Google Groups "pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
pqc-forum+...@list.nist.gov.
To view this discussion visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/d94bb5fc-26b8-4e82-8bf3-840a193fab5bn%40list.nist.gov.
Stephan Mueller
via pqc-forum:
Hi,
If it is of interest, starting lasth Thurdsay NIST allows the external
interface testing via the CAVP Prod server. Certificates are already posted
such as [1] - search for ML-DSA / SLH-DSA siggen/sigver and check the details.
[1] https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/
details?product=19286
Ciao
Stephan