Open csosto-pk opened 2 years ago
The document should more clearly identify the version of Dilithium: 3.1. If there are more versions, those would have different identifiers. There has been compatibility-breaking changes after the version submitted as a Finalist to Round 3, which is still on the NIST website (we've had customers try to match our implementation with those v3.0 KATs, requiring explanations). The changes from 3.0 to 3.1 include a security fix (at Level 5), so compatibility with the latest version is important. See Vadim Lyubashevsky's explanation, February 8, 2021: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/BjfjRMIdnhM/m/W7kkVOFDBAAJ Note that there were several other internal changes in from 3.0. to 3.1 apart from the hash lengths.
I am not sure this will be of value in the end. It is probably useful right now for interop reasons, but in the end, there will only be one Dilithium algorithm, the one specified by NIST.
I agree with you Panos. I've mentioned in the EDNOTE on page 1 that this is concerning Dilithium 3.1 2021-02-08, but I am reluctant to go into more details of differing historic versions and I can see this being confusing to the reader once the NIST process itself has complete.
Section 5 states "The randomized version can be invoked by leaving K as EMPTY." Private key formats are determined by application requirements and should not be used as "APIs" to affect functionality as suggested. Side-channel secure implementations will only use this type of plaintext ASN.1 encoding for backup/transport (never actively) and are likely to always perform randomized signing. Some other implementations (perhaps without trustworthy RNGs) may always perform deterministic signing; this does not break the interoperability of signatures. The explanation for the "tr" field in that private key format is not accurate (see above).Created new issue for this.