[SPEC] Key Refresh (fs-dkr) State Machine (in progress)

[akileshtangella]

Very high level overview of fs-dkr

• New parties joining broadcast a JoinMessage.
• Each already existing party broadcasts a RefreshMessage to every other party
• Every party validates and constructs new secret key share from the RefreshMessage's it receives.

Main takeaway from the above section:

• Existing parties and newly joining parties have different behaviors, so the state machine somehow has to account for this.

State Machine for GG '20

What is a state machine?

• A system that can be in any one of a finite number of states $S = {S_1, S_2,...}$ at any given time.
• Has a deterministic transition function $T: (S, M) \rightarrow S$, where $M$ is the message space $M$ of inputs to the state machine.

Contextualizing w.r.t. GG '20. The KeyGen struct makes up the state space, message space, and transition function for each party. Let's be more specific:

• The state space is the round attribute.
• The message space is msgs1, msgs2,.... Note each of these is a collection of messages.
• The transition function is the proceed function.

Basically things work as follows. The handle_incoming function on the StateMachine trait adds a message to a message store. Once the store is filled (a.k.a. the messages have been received from all parties), the state machine is ready to transition state via the proceed function, since it has access to the full message.

State Machine for fs-dkr

Round 0

The initial state will be an Option<LocalKey<Secp256k1>>. If this Option is None then it corresponds to a newly joining party and if it corresponds to an already existing party.

pub struct Round0 {
    local_key: Option<LocalKey<Secp256k1>>
}

Round 0 -> Round 1

The proceed transition from round 0 to round 1 does not entail receiving any messages. Rather the state transition works as follows:

• Generate and broadcast a Option<JoinMessage> (see here).
• This option will be None if local_key is Some and Some if local_key is None.

The round 1 struct looks like:

pub struct Round1 {
    local_key: LocalKey<Secp256k1>,
...
}

Notice here local_key is no longer an Option since every party has generated their local keys.

Round 1 -> Round 2

The transition from round 1 to round 2 entails receiving BroadcastMsgs<Option<JoinMessage>> as the messages. The proceed transition function receives these messages and:

• Updates its local_key. Specifically, the JoinMessage's of the new parties contain Paillier keys so the paillier_key_vec attribute of local_key needs to be updated (for each existing party).
• Each existing party broadcasts a RefreshMessage see here.

The round 2 state looks like:

pub struct Round2 {
    local_key: LocalKey<Secp256k1>,
...
}

...with the updated local_keys.

Round 2 -> Final Output

Each party receives BroadcastMsgs<Option<RefreshMessage>> does the relevant checks and updates its local_key accordingly. The final state is a new LocalKey.

Todos for implementation

• Implement KeyRefresh struct:
• Implement StateMachine trait for KeyRefresh struct
• Implement Round0, Round1, Round2 structs.