Implement Key Share Refresh protocol

[sridhar-panigrahi]

Summary

This PR implements the Key Share Refresh protocol for CGGMP24, addressing #162.

The implementation adds a protocol that allows parties to update their ECDSA secret shares without changing the underlying shared secret key, providing proactive security against mobile adversaries.

What's included

• Non-threshold key refresh (Figure 7 of the CGGMP24 paper): Each party generates per-party random share updates with row sums constrained to zero, distributes them via p2p channels with broadcast Feldman-like verification, and proves knowledge via Schnorr proofs.

• Threshold key refresh (Appendix F.1.1): Each party generates a random degree-(t-1) polynomial with a zero constant term, shares evaluations via Feldman VSS, and updates shares accordingly. The zero constant term ensures the shared secret key is preserved.

Both variants focus exclusively on updating the ECDSA share — all Paillier/auxiliary data steps are omitted as specified in the issue.

Design decisions

• Placed in the cggmp24-keygen crate following the issue requirements
• Follows the existing builder pattern (KeyRefreshBuilder / ThresholdKeyRefreshBuilder) mirroring KeygenBuilder
• Uses the same round-based protocol structure, commit-then-reveal pattern, reliability checks, and error handling as the existing keygen protocols
• Re-exported through cggmp24 crate as share_refresh (to avoid name collision with the existing key_refresh module for aux info)

Files changed

• cggmp24-keygen/src/key_refresh_non_threshold.rs — Non-threshold key refresh protocol
• cggmp24-keygen/src/key_refresh_threshold.rs — Threshold key refresh protocol
• cggmp24-keygen/src/lib.rs — Builder types, error types, public API, and entry point function
• cggmp24/src/lib.rs — Re-exports and updated doc comments
• tests/tests/it/share_refresh.rs — Integration tests (24 tests across all 4 curves)

Test plan

• Non-threshold share refresh tests pass for all curves (secp256k1, secp256r1, secp384r1, stark) with n=3, n=5, and n=5 with reliable broadcast
• Threshold share refresh tests pass for all curves with t=2/n=3, t=3/n=5, and t=3/n=5 with reliable broadcast
• Tests verify: public key preservation, secret share consistency, shares actually change, and reconstructed secret key matches
• All existing keygen/signing/key_refresh tests still pass

[sridhar-panigrahi]

Hi @survived and @maurges! 👋

I've taken a shot at implementing the Key Share Refresh protocol from #162 — would really appreciate your thoughts on it when you get a chance.

In short, both the non-threshold variant (Figure 7) and the threshold variant (Appendix F.1.1) are covered. I stuck to updating only the ECDSA shares as the issue described, and kept everything inside cggmp24-keygen with a builder API that mirrors how keygen already works. Tests are passing across all four curves.

I tried to stay close to the conventions in the existing codebase, but I'm sure there are things I could improve — so please don't hesitate to point out anything that looks off or could be done differently. More than happy to rework whatever's needed!

Thanks for maintaining such a well-structured project, it made the implementation a lot more straightforward.