Add support for stateful hash-based signatures to the PQC Extension

[athoelke]

Add support for the stateful hash-based signature schemes LMS, HSS, XMSS, and XMSS^MT to the PQC Extension.

This support is limited to public keys and signature verification - key generation and secure management of the stateful private key is not within the current scope of this proposal.

As the key types and signatures use XDR structures which encode the algorithm parameterisation, and public keys must be imported - there is no need to parameterise the key types or the algorithm identifiers in the Crypto API. A single key type and algorithm identifier is allocated for each of the three schemes.

An updated rendering of the extension document is attached: AES0119-PSA_Certified_Crypto_API-1.3_PQC_Extension-bet.0-draft3.pdf

Open Issues

• I have proposed having the key_bits in the key attributes match the output size of the hash function that parameterises the signature scheme. This seems more intuitive to use than the actual key sizes.

Fixes #232

[oberon-sk]

For X.509 it makes sense to use HSS only because LMS signatures and keys can easily be expressed in the HSS syntax. For a crypto library, however, the unification is not so easy. If the protocol used mandates the usage of LMS keys and signatures, both must be converted to HSS before they can be passed to the proposed functions. Conversion from LMS to HSS is easy but can require to copy the full data (up to about 10k) to a temporary buffer to be able to append the 0 and 1 fields. This would be a waste of RAM space.

We would prefer to use separate algorithms and key types for LMS and HSS (similar to XMSS and XMSS^HT):
PSA_ALG_HSS, PSA_ALG_LMS, PSA_KEY_TYPE_LMS_PUBLIC_KEY, PSA_KEY_TYPE_HSS_PUBLIC_KEY.
This would allow efficient usage of LMS inputs when needed.

Internally, we also discussed the alternative of using PSA_ALG_HSS_LMS and PSA_KEY_TYPE_HSS_LMS_PUBLIC_KEY for both LMS and HSS and allowing both kind of inputs, because LMS and HSS keys can be sorted out by their size (48 or 56 for LMS, 52 or 60 for HSS). But we do not like this approach.

If the proposed HSS only approach is preferred for whatever reasons, it would be better to remove the "LMS" parts from the names to make clear that LMS inputs must be converted to HSS before being supplied to the functions.

[athoelke]

Thank you for the feedback.

I had not thought about scenarios where an application might be using LMS independently of X.509, or related protocols. It would indeed be awkward to use the proposed API in that situation.

I will add identifiers for LMS public keys and the LMS signature algorithm. I think the suggestion to rename the HSS/LMS identifiers to be just HSS makes sense as well.

[athoelke]

I've updated the PR, including a separate key type and algorithm identifier for LMS, when not used in HSS. This supports use cases which are not using X.509 infrastructure or key formats, and dynamic conversion to HSS is impractical.

I have also implemented a suggestion for the use of key_bits in these key types. For all of these keys, the formatted key size is a simple calculation based on the size of the hash used. My initial suggestion is that key_bits should equal the hash output size (e.g. 192 or 256 for the NIST-approved parameter sets in SP800-208). Alternatively, we could use the actual encoded key size in bits. In practice, this value can be left as zero when importing a key, as key_bits will be deduced from the imported key data.

Unless there is a solid request for it, I will keep separate identifiers for the four algorithms.

[athoelke]

Updated draft(3) PDF attached to PR description.