Add ML-DSA test vectors that exercise the use_hint function with (1, 0) as input

[gendx]

Reproduction case for the bug in tink-crypto/tink-go#48.

These hand-crafted tests use:

• a valid but non-honestly generated public key with t1 set to all zeros,
• a non-honestly generated signature with z set to all zeros.

These conditions ensure that the verifier obtains a w_approx set to all zeros.

Then all hints in the signature are set to false except the first one, which ensures that a call to use_hint(1, 0) is made.

• In the valid signature, w1 is computed correctly by using this hint, and a consistent c_tilde is then derived and put in the signature.
• In the invalid signature, w1 is set to all zeros instead (which is what happens when the using the buggy implementation of use_hint that is fixed in mldsa: fix UseHint edge case for r0=0 per FIPS 204 Algorithm 40 tink-crypto/tink-go#48), and an inconsistent c_tilde is generated. Compliant implementations therefore reject this signature, whereas buggy ones accept it.

(In other words, the difference between the valid and invalid signatures is the value of c_tilde.)

[FiloSottile]

Ah! Thank you for generating and contributing this vector!

I had been trying to get coverage for h=1, w_approx={-1, 0, 1} and had found no good way. This covers 0, any way to cover 1 and -1?

Also, I had instead resorted to exhaustively testing all use_hint inputs. Could you check if https://github.com/C2SP/CCTV/tree/main/ML-DSA/accumulated#field-operation-tests would have caught this bug?

[gendx]

This covers 0, any way to cover 1 and -1?

I haven't looked into it. Zero was easy because all-zero values in z and t1 absorb the rest of the computation and break the circular dependency between the commitment c_tilde and w_approx, and (more of a convenience thing) zero is transparent upon NTT.