chore: Reshare secret keys 2 sets + trait revamp

[titouantanguy]

Description of changes

Generalize the reshare of the private keyset to work with both same set and two sets reshare (using trait).

Add a trait system to try and make the use of reshare dumb proof as the functions are used by parties in different sets which are expected to provide different inputs.

Add the usual protocol trait system to reshare to be able to compose with various implementations of broadcast and robust open (will be useful for testing malicious strategies).

Issue ticket number and link

PR Checklist

I attest that all checked items are satisfied. Any deviation is clearly justified above.

• Title follows conventional commits (e.g. chore: ...).
• Tests added for every new pub item and test coverage has not decreased.
• Public APIs and non-obvious logic documented; unfinished work marked as TODO(#issue).
• unwrap/expect/panic only in tests or for invariant bugs (documented if present).
• No dependency version changes OR (if changed) only minimal required fixes.
• No architectural protocol changes OR linked spec PR/issue provided.
• No breaking deployment config changes OR devops label + infra notified + infra-team reviewer assigned.
• No breaking gRPC / serialized data changes OR commit marked with ! and affected teams notified.
• No modifications to existing versionized structs OR backward compatibility tests updated.
• No critical business logic / crypto changes OR ≥2 reviewers assigned.
• No new sensitive data fields added OR Zeroize + ZeroizeOnDrop implemented.
• No new public storage data OR data is verifiable (signature / digest).
• No unsafe; if unavoidable: minimal, justified, documented, and test/fuzz covered.
• Strongly typed boundaries: typed inputs validated at the edge; no untyped values or errors cross modules.
• Self-review completed.

Dependency Update Questionnaire (only if deps changed or added)

Answer in the Cargo.toml next to the dependency (or here if updating):

1. Ownership changes or suspicious concentration?
2. Low popularity?
3. Unusual version jump?
4. Lacking documentation?
5. Missing CI?
6. No security / disclosure policy?
7. Significant size increase?

More details and explanations for the checklist and dependency updates can be found in CONTRIBUTING.md

[github-actions]

Consolidated Tests Results 2025-11-27 - 16:40:58

Test Results

16 passed

Details

16 tests
not captured
junit-to-ctrf
main test-reporter #1522
chore: Reshare secret keys 2 sets + trait revamp #292

test-reporter: Run #1522

Tests 📝	Passed ✅	Failed ❌	Skipped ⏭️	Pending ⏳	Other ❓	Flaky 🍂	Duration ⏱️
16	16	0	0	0	0	0	not captured

🎉 All tests passed!

Tests

View All Tests

Test Name	Status	Flaky	Duration
test_threshold_concurrent_crs	✅		14m 27s
test_threshold_concurrent_preproc_keygen	✅		14m 30s
test_threshold_custodian_backup	✅		6m 52s
test_threshold_insecure	✅		16m 38s
test_threshold_mpc_context_init	✅		13m 12s
test_threshold_mpc_context_switch	✅		6m 45s
test_threshold_mpc_context_switch_6	✅		13m 4s
test_threshold_restore_from_backup	✅		6m 44s
test_threshold_concurrent_crs	✅		14m 27s
test_threshold_concurrent_preproc_keygen	✅		14m 30s
test_threshold_custodian_backup	✅		6m 52s
test_threshold_insecure	✅		16m 38s
test_threshold_mpc_context_init	✅		13m 12s
test_threshold_mpc_context_switch	✅		6m 45s
test_threshold_mpc_context_switch_6	✅		13m 4s
test_threshold_restore_from_backup	✅		6m 44s

_{🍂 No flaky tests in this run.}

Github Test Reporter by CTRF 💚

🔄 This comment has been updated

[kc1212]

Comments are mostly around visibility, otherwise LGTM!

[titouantanguy]

BTW, was wondering should we return a R::MaybeExpectedOutput<T> in Reshare as for the inputs ? Any opinion ?

[kc1212]

BTW, was wondering should we return a R::MaybeExpectedOutput<T> in Reshare as for the inputs ? Any opinion ?

No strong opinion here, but since we're using these MaybeExpected associat types for inputs, we might as well extend it to outputs