Add stateful hash-based signatures

[dstebila]

LMS and XMSS as standardized by CFRG may be of use to Verisign and others.

[dstebila]

Stateful hash-based signatures won't fit within our current liboqs API for signature schemes, because the signing algorithm for those treat the secret key as a read-only input, whereas a stateful HBS scheme would need to modify the secret key during the signing operation. So the API would need to be adapted. We'd also have to consider whether to include mechanisms for reading/writing the secret key to/from files, or whether to leave that to the caller. Safe management of this update operation is critical as reuse / loss of state can be catastrophic for security.

Check out related literature and implementations: https://github.com/XMSS/xmss-reference, https://eprint.iacr.org/2020/470.pdf, http://www.amphawa.eu/data/icmu-paper.pdf

Eventually we'll also want to consider what can be done in OQS-OpenSSL. It will be hard to add stateful HBS signing (since the OpenSSL signature API would have to be modified at many places) but might be easier and sufficient for limited applications to first add verification for stateful HBS schemes, since those don't actually require any state to be stored/updated (and thus have the same API for verification).

[baentsch]

In preparation for merge of the stateful-sigs branch here's some observations where I wonder whether this is all as intended:

• This looks like handcrafted code. Is this intentional? No wish to parameterize/generate this? I didn't look at the implementing code, but if the header is like this the implementation probably also needs repetitive manual work if algs need updating (?).
• This would be better with a comment as to where this number comes from (if not generated as per the above). Otherwise, maintenance seems to be a nightmare (if not done by the original authors).
• What is "application relevant data" as an out param?
• This documents a parameter that doesn't exist
• Same here
• This comment is wrong (referencing the wrong variable)
• Parameter 2 of this API seems to be incorrectly documented: Is OQS_SIG_STFL_SECRET_KEYin fact a "byte string"? Hardly, looking at this.
• Same question on the last parameter of this function
• And here
• And here
• And here
• And here -- in addition, the parameter count and the documented parameters don't match. I can imagine what the missing one does, but a documentation would be good.
• still no byte string here
• Documentation of this function is completely out of whack with parameters
• I simply do not understand "context aids the secure writing of data": Where does this context come from? What does it contain? Who allocates/de-allocates this? If documented elsewhere please provide pointer.
• Parameters to this function completely undocumented
• Same here
• This exposes XMSS APIs to the public API -- but not a single function in there is documented. Why? Are they simply implementing the API above? If so, do they really need to be exposed via the public API? Makes is broader than necessary, no? Also coming back to the initial code generation question: Might (maintenance) benefit from a code generator?
• Same here

Lastly, is there some overall documentation explaining how this is intended to be used? Some sample code at least along the lines of this. Apologies if I overlooked this. I did find the test but it seems overly convoluted for someone just interested in (learning how to) use a stateful sig, no?

[SWilson4]

Closing as completed by #1650.