Module paillier_mta 

Paillier-based Multiplicative-to-Additive (MtA) share conversion.

Two surfaces:

• The proved functions (full_mta_proved and friends): the GG18/GG20 §3 + Appendix A protocol, which spec 70-cmp20 requires — every ciphertext carries a zero-knowledge proof, the responder refuses unproven input, the initiator refuses unbound responses, and the mask is the paper’s small β′ ∈ [0, q⁵) so honest shares never wrap: α − β′ = k_i·x_j exactly.

Key direction: the exchange runs under the INITIATOR’s Paillier key — party i encrypts k_i under its own public key, party j responds using only public material, and only party i can decrypt the response. The share contract demands it: α − β′ = k_i·x_j exactly, so whichever party ever holds BOTH α and β′ recovers the peer’s secret outright. Keeping the final decryption with the initiator (who never learns β′) is what makes the three split functions safe to run across processes — the responder never sees a private key.

Trust direction for the commitment keys: each party generates its own (Ñ, h₁, h₂) and the OTHER party proves against it — see mta_proofs for why a party must never prove to its own key.

Structs

ProvedMessage1

Proved round-1 message: ciphertext plus its range proof.

ProvedMessage2

Proved round-2 message: bound ciphertext plus its respondent proof.

Enums

MtaProofError

Errors on the proved MtA path.

Functions

full_mta_proved

Run the full proved MtA protocol between party i and party j, in-process (one coordinator holding i’s keypair).

party_i_finish_proved

Party i finishes the proved MtA: verify the respondent proof, then decrypt with i’s OWN private key.

party_i_init_proved

Party i initiates the proved MtA: encrypt k_i under i’s OWN public key and prove it is in range.

party_j_respond_proved

Party j responds in the proved MtA: verify the range proof, then multiply by x_j and mask with β′.