FIPS 204 - API for Module Lattice-based signatures (ML-DSA)

[athoelke]

Based on the discussion and proposal in #96 and #210, here is a definition of key types and algorithms for ML-DSA.

I have extracted the ML-DSA definitions out of the #210 PR, in which they are entangled with ML-KEM and ECIES API definitions, in order to fill out the remaining API for ML-DSA, using a similar structure to the SLH-DSA definitions in #216.

• The three parameter sets are supported
• Four algorithm variants for Hedged/Deterministic and Pure/Pre-hash options. The provision of explicit deterministic variants is an active discussion topic, see #210 and #216.
• Context values are not supported. These need an additional API to provide the context - as per existing sign-with-optional-context algorithms.

Fixes #96

[athoelke]

I've reworked the algorithm intro, including the suggested notes for application and implementation devs.

[MarcusJGStreets]

Having looked art the last commit, I think that is reasonable. I will do a final check, mainly for grammar etc.

[athoelke]

The work of the IETF LAMPS WG to define how ML-DSA appears in PKIX infrastructure is in progress. The flexibility in FIPS204 for storing/exchanging private keys as a seed or a key-pair has resulted in a likely change of direction from the July draft towards using the 32-byte seed.

See https://datatracker.ietf.org/doc/draft-ietf-lamps-dilithium-certificates/ for the latest status of this paper, and links to the drafts and the mailing list discussions.

We would prefer to NOT finalize the Crypto API definitions for key formats until this working group has published a final specification for key exchange formats.

This could result in publishing a PQC extension for the Crypto API, instead of integrating directly to the main specification. The extension will remain in Beta until the LAMPS WG work is complete, and perhaps also until we have confirmed the API through an implementation.

[athoelke]

These changes will appear first in the PQC Extension - see #223