Fix transient issues with Schnorr signature primitive

[zanebeckwith]

The recent changes to the Schnorr signature primitive (underlying the actual DAA signature) that were made to work with recent TPMs exposed some issues with the Schnorr signatures:

• Our implementation was missing a modular-reduction of one of the hash outputs during signature generation, which intermittently caused valid signatures to fail verification (particularly for the 254-bit curves)
• The TPM spec appears to specify that the nonce generated during TPM_Sign can be fed into the final hash as a variable-length encoding. Our implementation, however, was assuming that the nonce is always 32bytes (cf. this discussion)

This is only of concern in the somewhat-rare (~1/256 probability) event that the randomly-generated nonce value doesn't have 32 significant bytes. However, in that event, the TPM trims the leading zeroes from the serialization of the nonce before feeding it into the hash function.

Really, variable-length input to a hash for a signature scheme like this is a bad idea, and considering that the signature specification in the literature treats the nonce as a finite-field number (which, in crypto specifications, are generally serialized to fixed length), the intention with DAA is that this should be a fixed-length serialization.

So, to avoid this issue, this series introduces a retry into the call to TPM_Sign: if that call returns a nonce that's not full-length, it's called again.

[zanebeckwith]

The 1000 repetitions are actually for the software-only version, so that test wouldn't even catch the issue with TPM_Sign.

Honestly, I picked those numbers based on what seemed to not take too long on my own machine. More than 20 repetitions against the TPM simulator just takes too long, even though it has a low probability of catching a 1/256 issue.

I debated whether such tests are even appropriate for default testing like that. To really exercise the code, we want a lot of repetitions with good randomization, i.e. fuzzing. But, to encourage developers to always run tests we want the tests to complete quickly. So it's basically a compromise between those two extrema.

[zanebeckwith]

To allow the Memcheck travis builds to skip these repetitive Schnorr tests, I just pushed a new commit that splits those new tests into their own executables (with CLI-settable repetitions), with -fuzz names. That way, the Memcheck builds can just run ctest -E fuzz to not run those tests.

[coveralls]

Coverage decreased (-0.1%) to 92.988% when pulling f18948c81a5fe4dd00e764c19940f30664486acd on zanebeckwith:schnorr-verify into ab3773df62c2fcffa26c859d571a926931df29aa on xaptum:master.