Question about any differences from PQC standard final version

[sungmin-net]

Dear CRYSTALS,

First of all thank you for this sharing. Recently, I was told that final version of PQC standards published. Am I OK to use here's source code continuously after the final version publication?

• ML-DSA: https://csrc.nist.gov/pubs/fips/204/final (SNIP) D.3 Changes From FIPS 204 Initial Public Draft In the final version of the ML-DSA standard, the omitted malformed input check was restored to the hint unpacking algorithm (Algorithm 21). Additionally, in the final version of ML-DSA, all of the bits of 𝑐 ̃are used in the generation of 𝑐 (Algorithm 29), and ExpandMask (Algorithm 34) is modified to take output bits from the beginning of the output of H. Based on comments that were submitted on the draft version, more details were provided for the pre-hash version Hash ML-DSA in Section 5.4. These modifications include domain separation for the cases in which the message is signed directly and cases in which a digest of the message is signed. The changes were made by explicitly defining external functions for both versions of the signing and verification functions that call an internal function corresponding to the signing or verification functions from the draft FIPS. Domain separation is included in the input to the internal function (see Algorithms 2, 3, 4, 5, 7, and 8). To simplify APIs and for testing purposes, this document also introduced a similar external/internal split for key generation (see Algorithms 1 and 6), but this is a purely editorial change, as the external key generation algorithm is functionally equivalent to the key-generation algorithm from the draft FIPS. Finally, to offer misuse resistance against the possibility that keys for different parameter sets might be expanded from the same seed [35], domain separation was added to line 1 of Algorithm 6. (SNIP)

[bhenning10]

Expanding on this question a bit, I'm also curious if pq-crystals is planning to implement both new entry points (ML-DSA.Sign and HashML-DSA.Sign) or if the plan is to really implement what the final spec is calling ML_DSA.Sign_internal. I have also heard some questions about the IntegerToBytes step in HashML-DSA.Sign. The implementation of IntegerToBytes results in a byte swap of the OID to little endian, which seems odd as ASN.1 is typically stored big endian. Any thoughts on that?

[bhenning10]

It looks like this was merged - https://github.com/pq-crystals/dilithium/commit/cf998be4ade0014565305d3635a7b8317f2d4bd0

[gregorseiler]

The implementation has been updated to the final standard. It only includes the pure API for now and also not the internal function. I'll add support for the internal function (for KATs) and might add support for prehashing with shake128