Epic: Demo for Signature generation - Participant CLI

[mpguerra]

Motivation

We want to simulate a simple execution of FROST to show potential FROST implementers how to use the FROST library.

Scope

Build a simple CLI to simulate signing participant actions in a 2-round FROST signature generation protocol.

Round 1

• Create skeleton CLI with config for Participant CLI demo frost-zcash-demo#12
• Add participant identifier to Participant CLI demo frost-zcash-demo#16
• Add participant public key to Participant CLI demo frost-zcash-demo#17
• Add group public key to Participant CLI demo frost-zcash-demo#18
• Add secret key share to Participant CLI demo frost-zcash-demo#19
• Add vss_commitments to Participant demo frost-zcash-demo#32
• Round 1: Generate nonces and commitments in Participant CLI demo frost-zcash-demo#20
• Round 1: Serialize round 1 output in Participant CLI demo frost-zcash-demo#21

Round 2

This will be done after the Coordinator CLI demo (should we split this into it's own epic?)

• Add message to Participant CLI demo frost-zcash-demo#26
• Add list of signing commitments to Participant CLI demo frost-zcash-demo#25
• Round 2: Generate signature share in Participant CLI demo frost-zcash-demo#24
• Round 2: Serialize round 2 output in Participant CLI demo frost-zcash-demo#23
• CLI will exit (and delete any stored values if not output to CLI) in Participant CLI demo frost-zcash-demo#11

Specification

Set up

On startup, CLI should prompt for:

• participant identifier, i
• participant public key, PK_i, as well as the public keys for each of the other participants, PKn, which were generated during the Key Generation Demo (Epic: Demo for Trusted Dealer key share generation #238)
• the group public key, PK generated during the Key Generation Demo (Epic: Demo for Trusted Dealer key share generation #238)
• the secret key share, sk_i, generated during the Key Generation Demo (Epic: Demo for Trusted Dealer key share generation #238)

Round 1

During Round 1, each instance of the participant CLI will generate:

• a pair of nonces, (hiding_nonce, binding_nonce), and
• a pair of commitments, (hiding_nonce_commitment, binding_nonce_commitment)
  by running commit on its secret key share s_i.

The pair of nonces and commitments should be stored by each Participant CLI instance, with the commitments output to the terminal so they can be aggregated by the person running the demo, acting as a coordinator, during Round 1 of the FROST signing protocol.

For the purposes of this demo we may also want to output the nonces to the terminal and should note that these should remain secret.

Round 2

During Round 2, the participant CLI will prompt for:

• the message to be signed, msg, and
• the list of signing commitments, commitment_list, which would have been generated by all other running instances of the participant CLIs during round 1.

The CLI will then validate the inputs, by running DeserializeElement on commitment_list and by checking that its own identifier, i, and commitments, hiding_nonce_commitment_i and binding_nonce_commitment_i, are in the commitment_list which was input.

Next the Participant CLI will generate its signature share, by running sign with:

• its identifier, i,
• its secret key share, sk_i, generated during the Key Generation Demo (Epic: Demo for Trusted Dealer key share generation #238)
• the group public key, PK,
• its nonce pair,nonce_i, generated and stored in Round 1
• the message to be signed, msg, and
• the list of commitments, commitment_list, aggregated by the coordinator running the demo,
  to output a signature share, sig_share_i to the terminal.

The CLI will then exit, deleting any stored values (nonce_i and commitment_i.)

[mpguerra]

Hey team! Please add your planning poker estimate with Zenhub @conradoplg @dconnolly @natalieesk