Latest updates to ML-DSA are not implemented yet

[kamlesh0hrs]

Describe the bug
Looks like NIST has updated the parameters for Dilithium and Kyber which is still not implemented in the OQS.
Please refer below link from atsec

https://atsec-information-security.blogspot.com/2023/11/pqc-kyber-and-dilithium-state-of-draft.html

If that is true and If NIST has already made the changes for Its ACVP demo server , is there any plan to incorporate these changes in OQS anytime soon ?

[SWilson4]

The NIST draft standard versions are included in the latest release of liboqs. They are referred to as ML-KEM and ML-DSA (the NIST names), rather than Kyber and Dilithium.

OQS additionally continues to support the Round 3 versions of Kyber and Dilithium under their old names.

[smuellerDD]

Please note that one more change is decided upon that is not yet in liboqs: See the patch in [1]. When I revert this patch in leancrypto, both implementations calculate the same signature. However, please note that the NIST reference implementation already contains the change stipulated in [1] as I tested leancrypto against the NIST reference implementation via the ACVP interface [2] using the ACVP parser [3].

[1] smuellerDD/leancrypto@3a51337

[2] https://github.com/usnistgov/ACVP

[3] https://github.com/smuellerDD/acvpparser

[baentsch]

Which OQS sig alg did you use in your test? ML-SIG or the old (IMO deprecated) Dilithium?

[smuellerDD]

I used ML-DSA-87 with the tool kat_sig.CiaoStephan—Cui bono?Am 21.07.2024 um 15:32 schrieb Michael Baentsch ***@***.***>: Which OQS sig alg did you use in your test? ML-SIG or the old (IMO deprecated) Dilithium? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[SWilson4]

Thanks for letting us know about this, @smuellerDD. I don't think any of the liboqs team were aware that NIST had updated the implementation on the ACVP server. (Here is the source code change as an FYI for other readers.) As far as I can tell, the FIPS draft has not yet been updated.

To this point, we've followed the lead of the PQ-Crystals team and pulled in changes when they land in the upstream repo. @bhess do you know what their plans are with regards to this update?

Also tagging @dstebila so he's aware of this issue.

[smuellerDD]

Am Montag, 22. Juli 2024, 14:23:41 MESZ schrieb Spencer Wilson: Hi Spencer,

Thanks for letting us know about this, @smuellerDD. I don't think any of the liboqs team were aware that NIST had updated the implementation on the ACVP server. (Here is [the source code change](https://github.com/usnistgov/ACVP-Server/blob/8b2204159c1b31a3202ff 415cc7a9e1058c35fc5/gen-val/src/crypto/src/NIST.CVP.ACVTS.Libraries.Crypto/D ilithium/Dilithium.cs#L218) as an FYI for other readers.) As far as I can tell, the FIPS draft has not yet been updated. To this point, we've followed the lead of the PQ-Crystals team and pulled in changes when they land in the upstream repo. @bhess do you know what their plans are with regards to this update? Also tagging @dstebila so he's aware of this issue.

Just for the records: I am working closely with the NIST team and thus got the information directly from them. Their update is documented in [1]. This issue also contains the confirmation that my code matches their implementation. [1] usnistgov/ACVP-Server#332 Ciao Stephan

[bhess]

Thanks for the pointer @smuellerDD.

It looks like the change in SampleInBall is related to the changes announced in the post on the pqc-forum:
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/y8ul-ZcVWI4/m/k6WPyIdxAQAJ?utm_medium=email&utm_source=footer

In my view we would update the implementation once the final FIPS versions are published. I'd assume the upstream pq-crystals implementation will be updated at this point.

[smuellerDD]

Am Montag, 22. Juli 2024, 14:38:32 MESZ schrieb Basil Hess: While we are the discussion of consistency with the specification, the mandatory input validation as define in ML-KEM ipd section 6.2 also seems to be missing. At least the modulus check should be added assuming the other check as well as the check required in 6.3 are implicit due to the used variable types. One suggested implementation can be found in [1]. Do you want me to open a new issue for that? [1] https://github.com/smuellerDD/leancrypto/blob/master/kem/src/ kyber_kem_input_validation.h#L61 Ciao Stephan

[UladzimirTrehubenka]

As I understand to conform to latest ML-DSA KAT:
src/sig/ml_dsa/*

void poly_challenge(poly * restrict c, const uint8_t seed[SEEDBYTES]) {
...
  shake256_inc_absorb(&state, seed, SEEDBYTES);

->

void poly_challenge(poly * restrict c, const uint8_t seed[CTILDEBYTES])
...
  shake256_inc_absorb(&state, seed, CTILDEBYTES);

[UladzimirTrehubenka]

The first standards were recently finalized

[bhess]

The first standards were recently finalized

See also #1891 for ML-DSA / ML-KEM and #1894 for SLH-DSA.

[dstebila]

Tracked in #1891.