Add one-time signature scheme from XMSS

[marsella]

Closes #162.

This adds the WOTS+ signature scheme that's used in XMSS. It's very slow! About 50s for each public function (keygen, sign, verify).

This will be unusably slow in the context of XMSS -- e.g. XMSS key generation calls WOTS+ key generation 2^h times, where $h \in [10, 16, 20]$ -- for the largest parameter, this would take 1048576 minutes, or roughly 728 days, without accounting for the additional hashing that happens in XMSS.

Anyway I optimized base_w a bit but I think the main cost is coming from the recursive hashing; if we want this to be faster we will probably need to go look at SHA2 (the required parameter sets) and SHA3 (the optional parameter sets). In general, the goal of these specs is not to be performant -- it's just to look exactly like the written NIST specs -- but this appears to be getting so slow that we won't even be able to check basic properties of XMSS.

Another point of interest: this takes longer than usual to load (~10 - 30s), I suspect because the type constraints have a lot of computation in them.

Aside from performance, I think this is fairly straightforwardly representative of the spec. I'll add some inline questions and notes.

[marsella]

Here's some initial benchmarks I ran. sign has a couple of measurements because it turns out all-zero input circumvents most of the function in a way that is not representative of real data.

> :time genPK zero zero zero
Measuring for 300 seconds
Avg time: 51.98 s    Avg CPU time: 52.03 s    Avg cycles: 1247554038
> 
> :time WOTS_sign zero zero zero zero
Measuring for 300 seconds
Avg time: 2.598 ms    Avg CPU time: 2.600 ms    Avg cycles: 62349
> :time WOTS_sign (zero # ADRS) zero SEED ADRS 
Measuring for 300 seconds
Avg time: 22.73 s    Avg CPU time: 22.73 s    Avg cycles: 545567978
>
> :time WOTS_pkFromSig  zero zero zero zero
Measuring for 300 seconds
Avg time: 51.43 s    Avg CPU time: 51.45 s    Avg cycles: 1234365157

[marsella]

nb: I think I need to add a hashBytes function to all the hashes because this is starting to be a really typical pattern (split (hash (join x))).

[marsella]

todo: I'm still kind of confused about this; the spec doesn't clarify what to do if the padding is shorter than the checksum, so I assume it needs to be at least as long. However in my instantiation it was shorter (only 2 bytes). Maybe I filled in the instantiation incorrectly?

Anyway I took out this type constraint but I need to figure out what's going on here.

[marsella]

todo: this relates to the comment above -- the spec doesn't say anything about the m > 8y case. I need to try to figure out whether it should be here or not.

[marsella]

note: open to suggestions on whether to represent this differently. E.g. it could be a record with named fields. This "looks" the most like the ascii representation of the type in Section 2.5 but I'm not sure that's the obvious best way to represent it.

[marsella]

todo: There's a bit about pseudorandom key generation in the spec; it calls out to a separate doc with a pseudorandom method. Consider adding that function to get a key from a seed or at least describing it in more detail here.

[marsella]

question (naming): In the spec this is WOTS_genPK. Preference on using the prefix (here and in the other functions) vs relying on the namespace to "fill in" the prefix in the calling spots (e.g. call it genPK and invoke it using WOTS::genPK).