Intermediate Values for ML-KEM and ML-DSA

[Moody, Dustin (Fed)]

All,

The NIST CMVP/CAVP has generated a set of test vectors for all operations of ML-KEM and ML-DSA for the parameter sets specified in draft FIPS 203 and 204.   These can be found at:

https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/example-files

We want to remind that these are for the specifications in the draft FIPS, which are not yet final.  Still, we hope they will be useful for those who want to test out implementations.   They are also working on similar test vectors for SLH-DSA, which we will publish when they are available.   

Dustin Moody

NIST PQC

Note on the intermediate values for ML-KEM:
These test results were from an implementation of the 3 ML-KEMs in draft FIPS 203 with two specific changes:

1. The order of the input i and j to the XOF at step 6 in Algorithm 12 K-PKE.KeyGen() is switched.
2. The order of the input i and j to the XOF at step 6 in Algorithm 13 K-PKE.Encrypt() is switched.

In addition to the above, our implementation of Algorithm 13 uses a matrix variable "bHat" which is equal to the transpose of the matrix "aHat", i.e., bHat[j,i]=aHat[i,j].  This is done for convenience, and does not affect functionality.  

Note on the intermediate values for ML-DSA:
We recognize that Table 2 of the draft FIPS 204 gives incorrect values for the sizes of the signature and private key. In addition, we note that the incorrect signature length is also reflected in the output description in Algorithm 2 and the input description in Algorithm 3 (both in draft FIPS 204). The lengths of signatures and private keys in this Intermediate Values document are not consistent with these, but rather with what would be expected from following the steps of the pseudocode in draft FIPS 204.

[Filippo Valsorda]

Hello Dustin,

Thank you for producing these vectors, they are very useful and I was indeed in the process of producing similar ones myself.

I noticed that in "Decapsulation -- ML-KEM-768.txt", z and mPrime are the same. That's probably unintentional and due to reusing the same value for two random inputs (z in KeyGen and m in Encaps). It can be confusing to an implementer, though, who might wonder if that's expected or acceptable.

While at it, it would actually be useful if all vectors for the same parameter set (e.g. all ML-KEM-768 vectors) used the same keys and messages. That would make it possible not to switch from one set to the other as development progresses, and writing a single test to test all functions.

Cheers,

Filippo

--

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 on the web visit https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB86699A95198DEE116CE2EF6AE5A0A%40SA1PR09MB8669.namprd09.prod.outlook.com.

[Filippo Valsorda]

2023-11-01 15:57 GMT+01:00 Filippo Valsorda <fil...@ml.filippo.io>:

Hello Dustin,

Thank you for producing these vectors, they are very useful and I was indeed in the process of producing similar ones myself.

I published my intermediate values. People might still find them useful as they are formatted differently and cover KeyGen+Encaps+Decaps as a single run.

http://c2sp.org/CCTV/ML-KEM

Feedback and contributions are very welcome.

[Paul Duncan]

Hi Dustin,

Thank you for the preliminary test vectors.

I have a couple of questions:

Question #1: For ML-KEM, the "Decapsulation -- ML-KEM-*.txt" KATs only
include successful decapsulation test vectors.

Does NIST intend to publish failed decapsulation test vectors too? If
so, is that something that can be added to these preliminary KATs or
will it need to wait until after ML-KEM is finalized?

Question #2: For ML-DSA is it possible to add failed signature
verification test vectors to the "Signature Verification --
ML-DSA-*.txt" KATs?

Question #3: Does NIST plan to incorporate Peter Schwab's recommendation
to reduce coefficients modulo Q during PK deserialization (option #2 in
this message: https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/ZRQvPT7kQ51NIRyJ%40disp3269)
into the final ML-KEM specification?

If the answer to question #3 is "yes", then it would be helpful to
include a test vector with one or more coefficients >= Q in the
ML-KEM KATs in order to verify that deserialization is working as
expected.

If the answer to question #3 is "no", then it would be helpful to
include a test vector with one or more coefficients >= Q in the
ML-KEM KATs in order to test for the expected failure condition.

Thanks,

* 'Moody, Dustin (Fed)' via pqc-forum (pqc-...@list.nist.gov) wrote:
> All,
> The NIST CMVP/CAVP has generated a set of test vectors for all operations
> of ML-KEM and ML-DSA for the parameter sets specified in draft FIPS 203
> and 204. These can be found at:
> https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/example-files
> We want to remind that these are for the specifications in the draft FIPS,
> which are not yet final. Still, we hope they will be useful for those who
> want to test out implementations. They are also working on similar test
> vectors for SLH-DSA, which we will publish when they are available.
> Dustin Moody
> NIST PQC
>
> Note on the intermediate values for ML-KEM:
> These test results were from an implementation of the 3 ML-KEMs in draft
> FIPS 203 with two specific changes:
>

> 1. The order of the input i and j to the XOF at step 6 in Algorithm 12
> K-PKE.KeyGen() is switched.
> 2. The order of the input i and j to the XOF at step 6 in Algorithm 13

> K-PKE.Encrypt() is switched.
>
> In addition to the above, our implementation of Algorithm 13 uses a matrix
> variable "bHat" which is equal to the transpose of the matrix "aHat",
> i.e., bHat[j,i]=aHat[i,j]. This is done for convenience, and does not
> affect functionality.
>
> Note on the intermediate values for ML-DSA:
> We recognize that Table 2 of the draft FIPS 204 gives incorrect values for
> the sizes of the signature and private key. In addition, we note that the
> incorrect signature length is also reflected in the output description in
> Algorithm 2 and the input description in Algorithm 3 (both in draft FIPS
> 204). The lengths of signatures and private keys in this Intermediate
> Values document are not consistent with these, but rather with what would
> be expected from following the steps of the pseudocode in draft FIPS 204.
>

> --
> 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 on the web visit
> https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/SA1PR09MB86699A95198DEE116CE2EF6AE5A0A%40SA1PR09MB8669.namprd09.prod.outlook.com.

--
Paul Duncan <pa...@pablotron.org>
https://pablotron.org/

[Moody, Dustin (Fed)]

Thanks for the questions and suggestions.  

Yes, the random seeds provided are the same.  This is just for convenience and not any practical purpose.  The values are arbitrary.  

The CAVP only included the “positive” cases for SigVer and Decapsulation. Obviously, these example test cases aren’t going to be the only thing the CAVP produces. They’re working on the test vector generation for our server which will be much more expansive but not provide intermediate values. These example cases should just be considered examples to help an implementation along, not a full proof that your implementation is correct.

Dustin

 

---

From: Paul Duncan <pqc-...@pablotron.org>
Sent: Wednesday, November 1, 2023 2:10 PM
To: Moody, Dustin (Fed) <dustin...@nist.gov>
Cc: pqc-forum <pqc-...@list.nist.gov>
Subject: Re: [pqc-forum] Intermediate Values for ML-KEM and ML-DSA

 

https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpablotron.org%2F&data=05%7C01%7Cdustin.moody%40nist.gov%7Cadea9176da8b436b103d08dbdb05e1ed%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C638344591424233055%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000%7C%7C%7C&sdata=VJKl6C9jkgiyWzf3S4u3wsIRoloplnlfFsnyRX2aV1Q%3D&reserved=0

[Rod Chapman]

I can confirm that my reference implementation passes these test vectors, with the "(i,j)" switched to "(j,i)" as specified by Dustin.

All the best,

 Rod Chapman, AWS Cryptography

[carine lefort]

Hi,

I check also the same ML-DSA internal values except for C1Tilde.  Below my result:
ml-dsa44: C1Tilde is empty
ml-dsa65: C1Tilde is equal to last 16 bytes of CTilde
ml-dsa87: C1Tilde is equal to last 32 bytes of CTilde

Is it correct ? Does someone find also these results ?

Thank you,
Carine

[carine lefort]

In my previous email i talk about C2Tilde and not C1Tilde. (Sorry for the typo) Indeed  C1Tilde is always equal to the first 32bytes of  CTilde

so it should be different from 0.