hbs-guidance / draft-hbs-state

Repository of the WIP draft-wiggers-hbs-state - State and backup management for hash-based signatures
https://hbs-guidance.github.io/draft-hbs-state/
Other
0 stars 0 forks source link

Consider section on acceptable usage scenarios? #2

Open cipherboy opened 5 months ago

cipherboy commented 5 months ago

The introduction currently contains broad language around the desirable properties of these category of algorithms:

Their theoretic security is well understood and depends only on the security of the underlying hash function. As such, they can serve as an important building block for quantum-resistant information and communication technology.

I think it'd benefit the broader community (especially, protocol authors looking at adding PQC into their protocols) if some of this latter phrase ("important building block") could be expanded upon, perhaps enumerating some scenarios in which these trade offs are acceptable.

E.g., perhaps in the scenario where potential theoretical weakness in the design of SLH-DSA or ML-DSA are an unacceptable risk to an organization (but still desires PQC security), S-HBS schemes could be considered?

thomwiggers commented 5 months ago

This is something that we should have a discussion about. I think that it might make sense that we recommend some evaluation criteria even, i.e., S-HBS might be appropriate IF you can't use SLH-DSA, ML-DSA, can predict the number of signatures before hand, ...

E.g., perhaps in the scenario where potential theoretical weakness in the design of SLH-DSA

Just quickly noting that SPHINCS+ is basically an improved XMSS (in more ways than state) (in fact, XMSS even included in the SPHINCS+ specification!), so any attack that applies to SLH-DSA will likely apply to XMSS.

cipherboy commented 5 months ago

Just quickly noting that SPHINCS+ is basically an improved XMSS (in more ways than state) (in fact, XMSS even included in the SPHINCS+ specification!), so any attack that applies to SLH-DSA will likely apply to XMSS.

Ahhh, yes, this is true. I think that then strengthens the question, in what scenarios would you prefer this set of algorithms? :-)

E.g., in what scenario would you be able to use S-HBS, if you can't use SLH-DSA? The parties had the former available but not the latter due to (artificially) constrained supply of algorithms?

Ephemeral signing keys (like with sigstore) would perhaps be one valid use case under that scenario (artificially restricted algorithms)... with the caveat that ML-DSA would likely still be more performant and overall better, assuming resources to support both were present.