Proof generated on newly generated Paillier keypair instead of the keypair being returned

[tetratorus]

The key generation phase 3 broadcast is using a newly generated Paillier keypair to create the proof instead of using the Paillier keypair which is later being used in the protocol. https://github.com/ZenGo-X/multi-party-ecdsa/blob/a59b657dc4850a5219e5165424bf85b6b9fb9067/src/protocols/multi_party_ecdsa/gg_2020/party_i.rs#L163

In contrast, referencing the gg18 version, https://github.com/ZenGo-X/multi-party-ecdsa/blob/a59b657dc4850a5219e5165424bf85b6b9fb9067/src/protocols/multi_party_ecdsa/gg_2018/party_i.rs#L190, it uses the generated Paillier keypair in the proof.

[DmytroTym]

Hi Leonard, I'm not sure I understand what's the problem that you see. Is it the fact that we generate N_tilde by calling a method that creates a Pallier keypair here? If so, I agree that it's confusing, but Paillier public key is just a product of two 2048-bit primes which is what we need N_tilde to be, too. But note that Paillier public key and N_tilde are different entities. We need to prove that h_1 and h_2 generate the same group with respect to N_tilde and not Paillier pubkey. That said, I opened GG20 paper and see that in keygen phase 3, they write:

Phase 3 Let Ni = piqi be the RSA modulus associated with Ei. Each player Pi proves in ZK that ... and that h1 h2 generate the same group modulo Ni

Do you interpret this as the authors saying that we need to check discreet logs between h_1 and h_2 modulo Paillier pubkey?

[DmytroTym]

Also, about gg18 code - it does not have any range proofs (which is, as we now know, pretty insecure) and so does not need and does not have h_1 and h_2. So I don't think you can compare them