[ML-DSA] Use all of commitment hash to sample verifiers challenge

[jschneider-bensch]

This addresses #497, by passing in all of the commitment hash instead of just the first 32 bytes.

I've also increased the rejection sample loop bound in signing to the value prescribed by the standard. For the other rejection sampling loops described in the standard we don't put a limit, so this change also addresses #572.

I wonder about our test vectors with these changes: We can update our self-generated set (via the python spec) bit by bit along with our implementation, as we incorporate these changes. For external sources of test vectors, like the Wycheproof ones, we have vectors for the draft version and there seem to be vectors for the final standard in the same PR where we got the draft vectors (C2SP/wycheproof#112). Should we disable these tests and do changes bit by bit, or do all changes in one go, also updating the test vectors to their final version?

Update: I'm going to be addressing the changes in very short order, so I've disabled the old Wycheproof tests and filed an issue to re-enable them (updated to the standard vectors), once all changes are in: #607.

[franziskuskiefer]

Thanks!
I'm not sure I understand the comment about the other loops. As far as I can see we don't limit other loops.. And you want to keep it that way? That's fine with me, but we may reconsider adding them for the proofs (as we'll use the limit there anyway).

[jschneider-bensch]

Yeah, that's what I was trying to say. In the standards it says implementations should not bound rejection sampling loops, but if they do there are definitions for minimal numbers of attempts allowed: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf#appendix.C

Since we do not limit the number of attempts in our rejection sampling, except for the one loop in signing, we don't need to update any further loop bounds.