Add NIST Special Publication 800-208 parameter sets

This commit adds support for the parameter sets in the draft version of NIST SP 800-208.

Improved key generation

In the public comments to draft version of NIST Special Publication 800-208, ETSI TC CYBER WG QSC identified a multi-target attack against the method of pseudorandom key generation used in this referrence implementation. ETSI TC CYBER WG QSC suggested using the pseudorandom key generation method from SPHINCS+, however, there is still a multi-user attack against that key generation method.

This commit revises the pseudorandom key generation method by using the method from SPINCS+, but adding SEED as an input in order to protect against multi-user attacks. Since prf() only accepts 32-byte inputs, the new key generation method uses a new PRF. The resulting key generation method is sk[i] = prf_keygen(sk_seed, pub_seed || adrs).

Separate definition of padding length

The reference implemention of XMSS currently assumes that n bytes of padding is used for the prefix in the functions prf, hash_message, thash_h, and thash_f. While this is the case for all of the parameter sets in RFC 8391, the draft version of NIST Special Publication 800-208 specifies paramter sets in which the amount of padding is different than n.

This commit allows for the padding length for a parameter set to be specified separately from n.

The RFC suggests root||pubseed (in algorithm 10); note that
this choice does not influence interoperability.

Thanks go to Rafael Misoczki for bringing this up.

This also reduces some duplication between XMSS and XMSSMT

Read OIDs in big-endian byte order in UI

Force the OIDs read from input files to be interpreted as big-endian integers.
Leaving them as little-endian results in invalid values in params, eventually
leading to a crash.

It's not used outside xmss_commons

This behavior was completely unpredictable from the function name,
in particular when comparing it to other set_*_addr functions.

It wrongfully assumed that 2n + 32 = 3n

Since there's a tweak being introduced, this should be reflected
in the name of the functions.

This is relevant because of the enormous difference in signing
speed between the regular and BDS-traversal-based xmss core.

This ensures that xmss_core and xmss_core_fast offer the same API.
Note that xmss_core_fast still needs a major refactor, and this
wrapper is not exactly very clean. There is a considerable chance
this refactor will change the format of the state in the secret key.

Previous code allocated an array on the stack of mlen bytes, but
it should be possible to also sign heap-space messages. By relying
on the fact that sm and m fit the message + signature, we move
the message so that 4*n bytes of prefix can be added.

This allows different backends to store additional state information
in the secret key while the rest of the codebase remains agnostic.

In particular, this prepares for a common xmss_core.h API for both
the standard and the BDS-traversal-based implementations.

This removes a lot of code duplication.

This produced repeated indices when reaching 2^32 signatures.
This was introduced in 9b35b00d98
with the re-introduction of runtime parameters. Compile-time parameters
did not contain this error.

As a result, performs various refactors that also impact the verification
function, since cleaner signing functions exposed more overlap.