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 threshold multi-signatures #11

Open
burdges opened this issue Feb 12, 2019 · 14 comments
Open

Add threshold multi-signatures #11

burdges opened this issue Feb 12, 2019 · 14 comments

Comments

@burdges
Copy link
Collaborator

burdges commented Feb 12, 2019

We should write threshold schnorr signatures using session types analogous to the multi-signature ones in multi.rs. We should first go over the threshold schnorr signing literature just to check if anything needs tweaking.

We'll likely need Pederson's DKG as a subprotocol for both shared key generation and for creating R. See https://pdfs.semanticscholar.org/642b/d1bbc86c7750cef9fa770e9e4ba86bd49eb9.pdf

@burdges
Copy link
Collaborator Author

burdges commented Dec 17, 2019

We should do accountable subgroup multi-signatures along side this, which basically exist here already, but maybe the delinearization style impacts this as mentioned in #44 (comment) (full group vs current group). I suspect this requires importing some of the signer table like construction from the bls crate, although not so much since we know all signers before finalizing.

There is an insecure accountable subgroup multi-signature scheme described at https://github.com/KZen-networks/multi-party-schnorr/blob/master/papers/accountable_subgroups_multisignatures.pdf and https://pdfs.semanticscholar.org/6bf4/f9450e7a8e31c106a8670b961de4735589cf.pdf but adopting the fix is easy.

@real-or-random
Copy link

Usually I would not post links to random GitHub issues without being asked, but my talk here is highly relevant to this. Schnorr-based threshold sigs shows how the standard schemes in the literature based on Feldman's VSS and Pedersen's VSS make assumptions that are weird in practice and thus may not be secure:
https://www.youtube.com/watch?v=Wy5jpgmmqAg&list=PLaXwSyee0z4zWO0JLgcwhnjKqNBNJhBXY&index=53
The talk touches upon the real issues only superficially because my time was limited. Feel free to get in touch.

@burdges
Copy link
Collaborator Author

burdges commented Jan 12, 2020

I'll close #44 since it duplicates this issue. We discussed delinearization mechanisms and accountable threshold interfaces there, and noted that blocking issues are resolving #6 and doing PVSS for DGKs and using passwords for some of the shares.

@burdges
Copy link
Collaborator Author

burdges commented Jan 14, 2020

I've included comments about the DKG literature at w3f/bls#6 (comment)

@burdges
Copy link
Collaborator Author

burdges commented Nov 4, 2020

Isis implemented a reasonable DKG in https://github.com/isislovecruft/frost-dalek/tree/master/src but I hear other nifty new DKGs should appear soonish.

@real-or-random
Copy link

I hear other nifty new DKGs should appear soonish.

That sounds very interesting. Can you say more? ;)

@burdges
Copy link
Collaborator Author

burdges commented Nov 12, 2020

I knew only vaguely about one upcoming one, but it uses pairings and I've no yet asked the authors if they thought about pairing-free variants, or more likely about the properties in the DKG literature that preceded theirs.

We avoid uses DKGs in Polkadot so I never dug too much into them, but some support slightly nicer setups and/or safer redealing key shares. I figured redealing key shares might be useful here.. assuming someone else tells me what's optimal. ;)

@alxs
Copy link

alxs commented Feb 1, 2022

@burdges we have a grantee that wants to wait until this has been implemented to work on a milestone (@kevingzhang). Is it in the roadmap, or should he rather try to find another way?

@burdges
Copy link
Collaborator Author

burdges commented Feb 1, 2022

We could speed this up I think. I think @Lederstrumpf got interested. Send the grantee our matrix info so they can bug us.

@kevingzhang
Copy link

Awesome, finally someone started paying attention to this issue!

@kevingzhang
Copy link

Awesome, looking forward to updates. thanks

@alxs
Copy link

alxs commented Feb 16, 2022

@kevingzhang this is unlucky - @Lederstrumpf is leaving us and once again it's unlikely this gets done in the next few months.

@kayabaNerve
Copy link

I did code support for Schnorrkel around my own FROST library in hopes it may be useful: serai-dex/serai@develop...schnorrkel

While I assume schnorrkel will eventually have its own in-house own implementation of FROST, the above is usable today and the underlying library is currently undergoing auditing, so it shouldn't be insecure/problematic (at least, definitely not a month from now).

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

No branches or pull requests

5 participants