FIPS 204 - API for Module Lattice-based signatures (ML-DSA) #218
Conversation
athoelke
added
enhancement
athoelke
requested review from
gilles-peskine-arm,
ndevillard and
MarcusJGStreets
athoelke
changed the title
doc/crypto/api/ops/signature.rst
Outdated
| :definition: ((psa_algorithm_t) 0x06004400) | ||
|
|
||
| .. summary:: | ||
| Stateless hash-based digital signature algorithm without pre-hashing (ML-DSA), using hedging. |
There was a problem hiding this comment.
copy paste error.
s/ Stateless hash-based/ Module Lattice/g
Including in title.
…nt when checking policy
* PSA_ALG_IS_ML_DSA() checks for ML-DSA, and returns 0 for HashML-DSA. Replaces the use of PSA_ALG_IS_PURE_ML_DSA() * Removed PSA_ALG_IS_DETERMINISTIC_ML_DSA() and PSA_ALG_IS_RANDOMIZED_ML_DSA() * Added PSA_ALG_IS_DETERMINISTIC_HASH_ML_DSA() and PSA_ALG_IS_HEDGED_HASH_ML_DSA() * Use "hedged" instead of "randomized" in ML-DSA algorithm identifiers and descriptions
doc/crypto/api/ops/signature.rst
Outdated
|
|
||
| However, the |API| gives distinct algorithm identifiers for the hedged and deterministic variants of both ML-DSA and HashML-DSA, for the following reasons: | ||
|
|
||
| * `[FIPS204]` recommends that ML-DSA signing keys are only used to compute either deterministic, or hedged, signatures, but not both. |
There was a problem hiding this comment.
FIPS 205 includes this for SHS-DSA
FIPS 204 does not.
It simply says "this variant should not be used on platforms where side-channel attacks are a concern"
The History notes that Dilithium was originally only deterministic.
The hedged version was added as a defence against side-channel attacks.
There was a problem hiding this comment.
Technically, the full quote is:
Therefore, this variant should not be used on platforms where side-channel attacks are a concern and where they cannot be otherwise mitigated.
There is an extra clause that modifies the applicability of the recommendation to contexts where this threat is relevant (confidentiality of messages is an application issue), and not otherwise mitigated (a platform/system issue).
There was a problem hiding this comment.
It seems that the basic guidance for applications is "prefer to use hedged, because this is the default in the standard", but "if the implementation does not support it, AND you can accept the residual risk to message confidentiality, then use deterministic instead".
The guidance for implementations is "Always provide hedged, unless you have absolutely no viable source of randomness", and "provide deterministic if hedged cannot be provided, or as an extra optional variant alongside hedged".
There was a problem hiding this comment.
If we only specify a single variant in the API. The either:
- No implementation is allowed to provide deterministic signing. Without suitable randomness, ML-DSA.Sign() must fail. ML-DSA.Verify() can still work.
- An implementation can choose to provide deterministic signing when hedged is not possible, this is invisible to the application. If the application has message confidentiality concerns, it cannot tell if there is an unmitigated risk.
Is either of these an acceptable approach for the API?
There was a problem hiding this comment.
It does say "even a weak RBG may be preferable to the fully deterministic variants"
How many implementations would not even have a weak RNG?
In that case, how much other crypto can they do?
athoelke
changed the title
| * `PSA_ALG_HASH_ML_DSA` | ||
| * `PSA_ALG_DETERMINISTIC_ML_DSA` | ||
| * `PSA_ALG_DETERMINISTIC_HASH_ML_DSA` | ||
|
|
There was a problem hiding this comment.
I would like to add a note on hedged versus deterministic here. Perhaps:
.. admonition:: Note
FIPS 204 defines the "hedged" and deterministic versions. The hedged version provides message secrecy and some protection against side-channels. FIPS 204 recommends that users should use the hedged version if either of these issues are a concern. The deterministic variant should only be used if the implementation does not include any source of randomness.
.. admonition:: Implementation note
FIPS 204 recommends that implementations use an approved random number generator to provide the random value in the hedged version. However, it notes that use of the hedged variant with a weak RNG is generally preferable to the deterministic variant.
There was a problem hiding this comment.
I'm not sure that putting it here, with the key types is the right place - these should be with the algorithms. Perhaps this text would work well in the ML-DSA algorithm overview where it discusses Hedged and Deterministic variants?
I would leave the warning (from the last commit) in the description of PSA_ALG_DETERMINISTIC_ML_DSA.
* Reworked the layout of the ML-DSA introduction, using rubric subtitles to improve the structure * Added specific notes for applications and for implementations regarding the use of deterministic variants
|
I've reworked the algorithm intro, including the suggested notes for application and implementation devs. |
|
Having looked art the last commit, I think that is reasonable. |
|
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. |
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.
Fixes #96