Implement Key Refresh protocol

[survived]

We'd like to add a key share refresh protocol to our CGGMP24 implementation. This is a crucial security feature that enhances the long-term protection of the secret key.

Motivation

A key refresh protocol allows participating parties to compute new secret shares ($x_i'$​) from their existing shares ($x_i$​) without changing the underlying secret key ($x$). This process is a cornerstone of maintaining the long-term security and integrity of a distributed key.

The primary benefit is proactive security against a mobile adversary. For instance, imagine a 2-out-of-3 threshold scheme. An adversary might compromise one party and steal its key share. If a key refresh occurs before they can compromise a second party, the two stolen shares will be from different "generations." An adversary holding one share from before the refresh and one from after would find them useless together, preventing any attempt to reconstruct the secret key.

Key refresh is also a vital tool for reactive security. If a party is suspected of having its share compromised, the other honest parties can initiate a key refresh. This procedure effectively invalidates the entire set of old shares across all participants, rendering the single potentially stolen share useless for any future operations.

What To Be Implemented

Our library already provides an aux_info_gen protocol, which handles the generation and refreshing of auxiliary information (like Paillier keys). This is not about re-implementing or including that logic. We want to have two distinct protocols: the existing one for auxiliary data and a new one for the core share.

This feature requires implementing key refresh for both non-threshold and threshold schemes.

1. Non-Threshold (n-out-of-n): The implementation for this variant should follow the protocol described in Figure 7 of the CGGMP24 paper.

2. Threshold (t-out-of-n): The implementation for the threshold variant should be based on the extension described in Appendix F.1.1 of the paper.

For both versions, the implementation must focus only on updating the secret ECDSA share, $x_i$, and omit all steps related to auxiliary data (like Paillier keys re-generation).

This new protocol implementations should be developed as part of the cggmp24-keygen crate. By placing them here, all other protocols in our ecosystem that depend on this crate will be able to benefit from this feature.

Out of scope

Note that CGGMP24 Key Refresh protocol does not offer ability to change set of participants (although many other protocols do). We want to follow CGGMP24 paper as closely as possible, so adding this feature is out of scope.

Want to contribute? Reach out!

Please reach out to us if you want to contribute this feature, either here, or in Discord #lockness-contribute channel.