Key Ceremony information exchange and messaging rounds.

[JohnLCaron]

With Guardians becoming non-local objects, I am investigating the minimal set of information needed in the rounds of information exchange between Guardians during the key ceremony. I believe this is independent of whether one has a point-to-point exchange or a centralized mediator facilitating the exchange. Im also trying to clarify how many rounds of messaging are needed, and what is needed in each round.

This is my current understanding, in the hopes it will be useful to others, and to get feedback on any misunderstandings:

Round 1. Each guardian shares their public keys with all the other guardians. Each guardian validates the other guardian's commitments against their proof.

  class PublicKeySet {
    String ownerId(); // guardian object_id
    int guardianXCoordinate(); // guardian x coordinate (aka sequence_order)
    Rsa.PublicKey auxiliaryPublicKey();  // Assume RSA?
    List<SchnorrProof> coefficientProofs();  // The election polynomial coefficients commitments and proofs
 } 

Note: Having a pluggable auxilary encryption function adds complexity, can we leave it out for now?
Note: coefficientProofs contain the coefficient comittments, and the election public key and proof

Question: "An election verifier must confirm (A) and (B) for each guardian $T_i$ and for each $j in Z_k." Should that also be done now by each receiving guardian? "After verifying (A) and (B) for all other trustees, each guardian then..." So Im assuming yes.

Round 2. Each guardian shares partial key backups with each of the other guardians, each guardian verifies their own backups.

  class ElectionPartialKeyBackup {
    String generatingGuardianId(); 		// Id of the guardian that generated this backup.
    String designatedGuardianId(); 		// Id of the guardian to receive this backup
    int designatedGuardianXCoordinate(); // The x coordinate (aka sequence order) of the designated guardian

    Auxiliary.ByteString encryptedCoordinate(); // The encrypted coordinate of generatingGuardianId polynomial's value at designatedGuardianXCoordinate.
  } 

Note: coefficient comittments were already sent in the PublicKeySet.
Note: The response to sending the partial key backup message can be a validation failure, so an extra round is not needed.

Round 3. For any partial backup verification failures, each challenged guardian broadcasts its response to the challenge.
The mediator verifies the response. In point to point, each guardian would verify.

  class ElectionPartialKeyChallengeResponse {
    String generatingGuardianId();
    String designatedGuardianId();
    int designatedGuardianXCoordinate();
    
    Group.ElementModQ coordinate(); // The unencrypted coordinate of generatingGuardianId polynomial's value at designatedGuardianXCoordinate.
  }

Note: coefficient comittments were already sent in the PublicKeySet. Besides following the rule of minimizing copies of state, it may
also remove an attack point by not letting the challenged guardian muck around with its commitments?

Round 4. All guardians compute and send their joint election public key. If they agree, then the key ceremony is a success.

Note: Not sure about having the guardians compute the extended base hash, which means they have to have access to the election manifest.