FIPS 205 - API for Stateless hash-based signatures (SLH-DSA)

[athoelke]

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

• All twelve parameter sets are supported
• Four algorithm variants for Hedged/Deterministic and Pure/Pre-hash options
• Context values are not supported. These need an additional API to provide the context - as per existing sign-with-optional-context algorithms.
• Key formats are defined.

Fixes #97

[athoelke]

Currently the key types use an SLH infix. This keeps the key names smaller, and would permit us to use the SLH category to define SLH key families that are used with other (non-DSA) algorithms.

In contrast the algorithms are all SLH_DSA.

• I have used a DETERMINISTIC prefix (as per ECDSA) for the non-hedged variant, but left the hedged (randomized) version undecorated.
• I have used a HASH prefix for HashSLH-DSA, in contrast with the PH suffix in EDDSA, but that reflects the FIPS 205 naming of the pre-hash variants of the algorithm.

[athoelke]

I have added a consistent set of helper macros relating to key types and algorithm interrogation. Please give feedback if there are any missing, or the provision is overkill.

[athoelke]

I think I have made all the relevant updates to the spec-defined helper macros in Appendix C, but might have missed one or two.

[MarcusJGStreets]

Both FIPS 204 and 205 have an admonition that users SHOULD use the hedged version.
They are permitted to use the deterministic version if there is no good source of randomness and side channels are not an issue.

I am not aware of any real word situation where side channels are not an issue, except perhaps the inside of a tank.

So I would not include the Deterministic version in the API.

Now, Giles is going to say that he needs it for testing.
And he will have a point.
So, I would favour a compile time variable that can be set to force deterministic mode - and that could be shared between SHS-DSA and ML-DSA.

This could be an ifdef so it is not in runtime code.
I am not decided whether we keep that as an internal only, or document it with caveats that it is for testing only.

Of course, if an implementation does not have a source of randomness, then it has to use the deterministic version.

[gilles-peskine-arm]

Now, Giles is going to say that he needs it for testing.

Actually, no, we don't need it for testing. It's nice, but we can do without. We can test things like asymmetric encryption which absolutely cannot be deterministic.

However, I think we should have it in the API.

There are environments where side channels are genuinely not an issue. For example, a certificate authority creating signatures on a discrete piece of hardware and exporting the signatures in batches does not have to worry about side channels. Furthermore, the deterministic version can be robust against timing side channels if it's implemented in constant time. If the implementation isn't perfectly constant-time, depending on the exact attack, either the hedged version or the deterministic version might be easier to attack (some attacks rely on performing the exact same computation multiple time, while others rely on signing the same message with multiple nonces).

There are use cases where the determinism of the signature is a desirable feature. For example, if you have redundant systems that must give identical outputs, it's easier to arrange with a deterministic algorithm than if you have to ensure that they use synchronized RNGs.

[MarcusJGStreets]

The use cases for deterministic signatures are edge cases.
What worries me is that for ECDSA deterministic signatures are probably the correct solution in most cases.
So, a naive user presented with the option, might choose deterministic PQ signatures, from half remembered information.

And I want to avoid that.

[athoelke]

The exact wording in FIPS 205 (§9.2 p36) is as follows:

The hedged variant is the default and should be used on platforms where side-channel attacks are a concern. When using the hedged version, 𝑎𝑑𝑑𝑟𝑛𝑑 shall be an 𝑛-byte random value. While 𝑎𝑑𝑑𝑟𝑛𝑑 should ideally be generated by an approved random bit generator, other methods for generating fresh random values may be used. For the deterministic variant, 𝑎𝑑𝑑𝑟𝑛𝑑 is not provided as an input, and 𝑜𝑝𝑡_𝑟𝑎𝑛𝑑 is set to PK.seed, which results in signing being deterministic (i.e., signing the same message twice will result in the same signature). The deterministic variant is available for platforms where a random bit generator is not available.

Along with the algorithm description, where using PK.seed is an alternate presented almost as a comment, this suggests that this is a recommendation for implementations: "use the hedged version if you have anything remotely suitable for providing the random input".

However, the specification elsewhere (§9.1 p34) states:

SLH-DSA signing has two variants — “hedged” and deterministic (see Section 9.2) — whose keys should only be used for the generation and verification of hedged and deterministic SLH-DSA digital signatures, respectively.

Unless we define these as separate algorithms, it is not possible to constrain a key to one or the other variant, and the application has no way to control how the signature is generated - as this is just an implementation decision.

If we keep both forms, we should add some notes or warnings to reflect the NIST guidance on recommending the hedged variant. If we just keep one, we need to make it clear that it is implementation defined whether the signature generation is hedged or deterministic.

[MarcusJGStreets]

FIPS 204 says
This document also permits a fully deterministic variant of the signing procedure in case the signer has
no access to a fresh source of randomness at signing time. However, the lack of randomness in the
deterministic variant makes the risk of side-channel attacks (particularly fault attacks) more difficult to
mitigate. Therefore, this variant should not be used on platforms where side-channel attacks are a concern
and where they cannot be otherwise mitigated.
Only implementing the hedged variant (i.e., without the deterministic variant) is sufficient to guarantee
interoperability. The same verification algorithm will work to verify signatures produced by either variant,
so implementing the deterministic variant in addition to the hedged variant does not enhance interoperability.

And with regard to generating the random value

For this purpose, even a weak RBG may be preferable to the fully deterministic
variants of Algorithms 2 and 4.

But it does not have the admonition that keys should only be used for one or the other variant.

I feel that we ought to try to keep the two interfaces parallel if possible.
But, I am not sure if that is the correct approach.

If you want something reproducible, then using SHA256(time) would probably be sufficient to hedge the signature.

[athoelke]

FIPS 204 says

It is entirely possible that the security implications of the deterministic variant are different for ML-DSA vs SLH-DSA.

It is also possible that the original text from which the paragraphs in FIPS 204 and FIPS 205 come from entirely different design and implementation teams, and the differences reflect a difference in perspective, rather than a difference in technical matters.

In the first instance, I do believe we should not apply recommendations from the ML-DSA FIPS 204 specification to the SLH-DSA algorithm definition in the API.

[athoelke]

If you want something reproducible, then using SHA256(time) would probably be sufficient to hedge the signature.

Not convinced that an implementation that does this would be certifiable?

[athoelke]

[In relation to the ML-DSA text...]

A source for the recommendations in FIPS204 is the CRYSYALS-Dilithium round two submission paper §3.2, which says:

One may want to consider randomized signatures in situations where the side channel
attacks of [SBB+18, PSS+18] exploiting determinism are applicable. Another situation
where one may want to avoid determinism is when the signer does not wish to reveal the
message that is being signed. While there is no timing leakage of the secret key, there is
timing leakage of the message if the scheme is deterministic. Since the randomness of the
scheme is derived from the message, the number of aborts for a particular message will
always be the same.

Initially Dilithium was just deterministic, but added randomization to be able to mitigate a vulnerability to side-channel leakage of the message (not key). The authors assumed that randomization may assist a Quantum attack, and therefore preferred the deterministic approach (in §1.2):

While it’s not clear as to whether there is an improved
quantum attack for randomized signatures, we suggest the deterministic version as the
default option except in scenarios where an adversary can mount side-channel attacks that
exploit determinism [SBB+18, PSS+18].

The cited texts are Breaking ed25519 in wolfssl and Attacking deterministic signature schemes using fault attacks.

NIST have adjusted the scheme to use two sources of randomness, the random seed in the signing key, and some fresh randomness when signing, and falling back to just the first source when using the deterministic variant.

NIST have removed any mention of concerns relating to Quantum attacks being assisted by randomness. The sense of the recommendation from FIPS204 is to prefer the hedged variant.

[athoelke]

I've updated this following resolution of some open issues, and aligning the API with the latest ML-DSA PR #218.

• Replaced SLH with SLH-DSA in text and API elements for key types.
• Defined a key derivation procedure.
• Made the pure/pre-hash algorithm separation clearer, with the helper macros.
• Clarified the reasoning, policies, and provided recommendations regarding hedged vs deterministic variants of the algorithm.

[athoelke]

These APIs will first appear in the PQC extension - see #223