Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

add verifiable key resharing module #570

Closed
wants to merge 2 commits into from

Conversation

conduition
Copy link
Contributor

@conduition conduition commented Nov 6, 2023

This PR implements Wang's Verifiable Secret Redistribution (VSR) Scheme to allow resharing of FROST shares, with protection against active adversaries. See #519 for research and justification. Also see #245 for related work.

This enables threshold modification, signer identifier changes, share revocation, and other cool downstream use-cases.

This PR is not complete; i wanted to check in and get feedback before proceeding further.

Remaining work:

  • More thorough integration tests
  • Implement the resharing module in all frost-* ciphersuite crates.
  • Improve documentation.
  • Add docs to the book.
  • Other things I'm missing?

@chelseakomlo
Copy link
Collaborator

Hi @conduition, thanks very much for the PR! As a first step, it would be helpful to write a high-level design document to give intuition for the change and how it fits into the user experience/existing code. Can you please attach that to this PR and I'll take a look?

I looked over your notes in #519 and it lists some drawbacks of the Wang scheme, one which is the lack of public verifiability. Does this PR mitigate these drawbacks in any way? If not, I don't think we can merge this, we need verifiability to ensure players don't perform denial of service attacks (by sending shares that don't reconstruct to a valid secret).

Also, this link (cited in the code) doesn't open for me- https://www.semanticscholar.org/paper/Verifiable-Secret-Redistribution\
-for-Threshold-Wong-Wang/48d248779002b0015bdb99841a43395b526d5f8e

@conduition
Copy link
Contributor Author

Thanks for the quick attention @chelseakomlo =)


As a first step, it would be helpful to write a high-level design document to give intuition for the change and how it fits into the user experience/existing code.

I certainly can. I'll follow the example of the dkg.md document.


I looked over your notes in #519 and it lists some drawbacks of the Wang scheme, one which is the lack of public verifiability.

What the author means by 'public verifiability' is a property where external verifiers (who are not part of the signing group) can verify that all new shares are distributed accurately and consistently. This paper gives a short and sweet definition of a PVSS in the abstract:

A publicly verifiable secret sharing (PVSS) scheme, named by Stadler in [Sta96], is a special VSS scheme in which anyone, not only the shareholders, can verify that the secret shares are correctly distributed.

For example, customers of a cryptocurrency exchange may wish to verify that shares of the company's cold-storage signing key are distributed to the appropriate executives.

FROST does not explicitly support public verifiability (as far as i know) - although it would be trivial to extend it include such features. FROST assumes that only the signers care about whether the signing shares are correctly distributed, while external verifiers outside the FROST signing group are assumed to only care about signature validity against the group's joint pubkey.

Wang's VSR scheme is indeed verifiable in the sense that peers who receive new shares from the VSR protocol - including those who are not already part of the signing group - can verify their new shares will be correct, and accurately assign blame to misbehaving resharer(s). This all assumes the resharing polynomial commitment is sent over a broadcast channel. If commitments are not consistent, then blame is harder to assign accurately.

The group is thus protected against denial-of-service attacks by any $t - 1$ or fewer signers of the old group (before resharing). The group can be DoS'd if $n' - t' + 1$ members of the new group misbehave, but that's exactly the same as normal FROST without resharing, so nothing new there.


Also, this link (cited in the code) doesn't open for me- https://www.semanticscholar.org/paper/Verifiable-Secret-Redistribution\-for-Threshold-Wong-Wang/48d248779002b0015bdb99841a43395b526d5f8e

That link should render in docs.rs as https://www.semanticscholar.org/paper/Verifiable-Secret-Redistribution-for-Threshold-Wong-Wang/48d248779002b0015bdb99841a43395b526d5f8e - i think you may have copied the backslash needed to escape the line-break.

I hope this helps, i'll get started on the design document once I have some time

@conduition
Copy link
Contributor Author

Added a first draft of a document dedicated to resharing. This doesn't go into detailed code examples as I suspect we may want to modify the API for simplicity/clarity, or to rhyme with the DKG API.

@mpguerra mpguerra linked an issue Nov 21, 2023 that may be closed by this pull request
@conduition conduition marked this pull request as ready for review January 31, 2024 23:02
@conduition
Copy link
Contributor Author

Would like some indication I'm going in the right direction here before I press any more effort onto this.

@chelseakomlo
Copy link
Collaborator

chelseakomlo commented Feb 3, 2024

Hi @conduition - sorry for the slow reply, it took us some time to review these and discuss as a team.

While this approach indeed looks promising, the current blocker is that while the resharing algorithm seems to be well-understood for a single-dealer and has a security proof, extending this functionality into a multi-party setting is not necessarily straightforward. As @conradoplg mentioned, we will need to consider malicious parties, which will result in a multi-round DKG protocol, but with additional properties. While I suspect this re-sharing algorithm would slot into existing DKG frameworks [1], someone will need to write this protocol in precise detail and give at minimum a proof sketch that the resulting protocol is indeed a secure DKG, but with the additional claimed properties of adding/removing players and changing the threshold.

I do think this work is indeed possible, but unfortunately our team currently doesn't have the bandwidth to lead this work at the moment, or to collaborate/provide reviews in a sufficient level of detail. But please feel free to continue development as an external project, it seems useful and something that would be valuable in the future.

Thanks- again, this work looks very promising, sorry we can't focus on it more! And feel free to point to writeups/proofs that might exist already in the literature, if you end up finding something in the future.

[1] https://eprint.iacr.org/2023/292

@conduition
Copy link
Contributor Author

That's OK @chelseakomlo, I understand. Thanks for the transparency and honesty 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Allow signers to change group threshold by updating shares
2 participants