Implementation Choices for Dilithium Variants in Botan

[elGoonie]

Hello Botan community,

I've been looking into the quantum-safe cryptography mechanisms implemented in Botan, specifically the Dilithium digital signature algorithm. My interest was piqued by the choice of Dilithium variants implemented in the project.

As noted above, the project chose to implement the 4x4, 6x5, and 8x7 variants as standardized in the now-expired IETF draft, draft-uni-qsckeys-dilithium-00 (IETF Draft). This choice intrigued me, especially considering that the CRYSTALS team, the original creators of Dilithium, proposed the Dilithium2, 3, and 5 variants, which are also the basis for the upcoming FIPS 204 standard (FIPS 204).

Could someone shed some light on the reasoning behind selecting the 4x4, 6x5, and 8x7 variants for implementation over the Dilithium2, 3, and 5 variants proposed by the CRYSTALS team? Is this decision based on specific performance, security, or compatibility considerations?

I'm interested in understanding the thought process and criteria that guide such implementation decisions within the Botan project, especially in the context of aligning with future standards and ensuring the robustness of quantum-safe cryptography solutions.

Thank you very much for your time and insights.

Best regards

[reneme]

To the best of my understanding, the names Dilitihium2, Dilithium3, Dilithium5 and 4x4, 6x5, 8x7 are basically synonymous respectively. The numbers refer to the targeted NIST security level and the AxB notation reflects the size of the underlying matrix. Or am I missing your point?

However, there are different revisions of the specification, for each NIST round, among others. Currently, we implement what is referred to as "Version 3.1" in FIPS 204 ipd Section 1.3.1, this is also the algorithm implemented by the authors' reference implementation's master branch making it compatible to the implementation in liboqs, for instance.

We are currently working on the integration of ML-DSA-ipd, and, based on that, provide an implementation for the final standard as soon as it comes out.

Regarding choice of implemented algorithm, let me refer to the project goals, most notably:

Implement schemes important in practice. It should be practical to implement any real-world crypto protocol using just what the library provides.

[elGoonie]

Hi, thanks for your answer. You are completely right, the notation kxl is based on the two parameters, wich define the size of the matrix A.
But besides that, i dont find any official documents where Dilithium 2,3 and 5 are refered like this.
So the naming of this standards is bit confusing.
Since the FIPS 204 standard will be integrated in the future, it won't be a big problem.
Otherwise i would suggest to rename the parametersets to Dilthium2, Dilthium3 and Dilthium5.