Potential error in checking committed value was used in Schnorr proof during KeyGen

[becgabri]

The key generation protocol for CGGMP consists of three different phases: a commitment phase, a reveal phase, and a ``prove" phase. In the first phase, parties commit to their key shares and the randomness to be used in the schnorr proof. The values are broadcast in the reveal phase and the commitment is checked for correctness. In the prove phase, parties prove that they knew the exponent for the share they supplied in the first phase (i.e. discrete log of X wrt the group generator G) and they do this using the Schnorr proof and the randomness they committed to earlier (which is equal to A in the CGGMP paper).

https://eprint.iacr.org/2021/060.pdf (Fig 5) It's important to check that the schnorr proof uses the committed randomness from earlier, at least from the perspective of the security proof (it is used in the reduction, according to the text). This check should probably happen in https://github.com/boltlabs-inc/tss-ecdsa/blob/main/src/keygen/participant.rs#L526-L577 but it doesn't appear to be present. Right before the call to verify, there should be a check to ensure that decom.A is equal to proof.commitment

[naure]

This issue was addressed for KeyRefresh in #522 .

After this is merged, KeyGen can be fixed by replacing verify with verify_with_precommit like so:

            proof.verify_with_precommit(
                input,
                &self.retrieve_context(),
                &mut transcript,
                decom.A,
            )?;