Threshold Signature Implementation #2250

Fiono11 · 2024-03-14T12:36:14Z

Project Abstract

This document outlines the proposal for implementing Olaf, a protocol that combines FROST, a threshold signature scheme based on the Schnorr signature, with SimplPedPoP, a Distributed Key Generation (DKG) scheme. It provides a more scalable, cheaper, more user-friendly and privacy-preserving alternative to current multisig solutions. This protocol is particularly designed for scenarios with a large number of signers, ensuring both efficiency and signer anonymity.

Grant level

Level 1: Up to $10,000, 2 approvals
Level 2: Up to $30,000, 3 approvals
Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

The application template has been copied and aptly renamed (project_name.md).
I have read the application guidelines.
Payment details have been provided (Polkadot AssetHub (DOT, USDC & USDT) address in the application and bank details via email, if applicable).
I am aware that, in order to receive a grant, I (and the entity I represent) have to successfully complete a KYC/KYB check.
The software delivered for this grant will be released under an open-source license specified in the application.
The initial PR contains only one commit (squash and force-push if needed).
The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

Fiono11 · 2024-03-14T15:49:34Z

This application is a modified version of #2225, based on feedback received from @burdges.

Update ThresholdSignature.md

burdges · 2024-03-17T16:34:39Z

applications/ThresholdSignature.md

+
+### General Overview
+
+This document outlines the proposal for implementing [Olaf](https://eprint.iacr.org/2023/899), the first FROST based protocol proven secure without relying on the [Algebraic Group Model](https://eprint.iacr.org/2017/620.pdf) (AGM) or an idealized key generation protocol. It is composed of:


Olaf sounds reasonable. Any comment @elizabeth-crites ?

burdges · 2024-03-17T16:47:46Z

applications/ThresholdSignature.md

+
+This document outlines the proposal for implementing [Olaf](https://eprint.iacr.org/2023/899), the first FROST based protocol proven secure without relying on the [Algebraic Group Model](https://eprint.iacr.org/2017/620.pdf) (AGM) or an idealized key generation protocol. It is composed of:
+- [FROST3](https://eprint.iacr.org/2022/550), the most efficient known variant of [FROST](https://eprint.iacr.org/2020/852), which is a threshold signature protocol based on the [Schnorr signature scheme](https://link.springer.com/article/10.1007/BF00196725) (for simplicity, we refer to FROST3 as FROST in this document, since the core functionality is the same).
+- [SimplPedPoP](https://eprint.iacr.org/2023/899), a Distributed Key Generation (DKG) protocol used to generate the group key to sign in FROST. It is a simplification of [PedPoP](https://eprint.iacr.org/2020/852), the DKG used in the original FROST paper, which is the [Pedersen's DKG](https://link.springer.com/content/pdf/10.1007/3-540-46766-1_9.pdf) with Proofs of Possession (PoP) of the generated secret. All of them have as the fundamental building block the [Shamir's secret sharing scheme](https://web.mit.edu/6.857/OldStuff/Fall03/ref/Shamir-HowToShareASecret.pdf).


SimplePedPop sounds fine. I never looked at PedPoP really, only the original Pedersen DKG. Again any comment @elizabeth-crites?

We'd simply output a hash for the equality check algorithm, so then the user must handle the final abort if that fails?

Ahh SimplePedPoP does not encapsulate encrypting the key shares. Does PedPoP do so?

I'll think about if there is a way to abstract this, but maybe SimplePedPoP works well for single user use cases.

PedPoP does not encapsulate encrypting key shares either. That is why they are implementing EncPedPop here, which is a wrapper around SimplPedPop. And they recommend it even for applications that support secure channels, due to its low overhead. Should we do the same?

It adds an extra round because you must know to whom you encrypt. As EncPedPop is a wrapper around SimplePedPoP then I'd say do SimplePedPoP first, and we can think about the wrapper later. It'll maybe require cleaning up the aead module, so no reason to block anything: https://github.com/w3f/schnorrkel/blob/master/src/aead.rs

burdges · 2024-03-17T16:53:10Z

applications/ThresholdSignature.md

+    /// Generates the signing nonces and commitments to be used in the signing operation.
+    ///
+    /// Implements [`commit`] from the spec: https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-15.html#name-round-one-commitment
+    pub fn commit(secret: &SigningShare) -> (SigningNonces, SigningCommitments);


This could take a &impl Transcript too, which'll add entropy. It's only immutable though, so no transcript modifications, and ignoring it is harmless.

burdges · 2024-03-17T16:58:18Z

applications/ThresholdSignature.md

+    /// Receives the message to be signed and a set of signing commitments and a set of randomizing commitments to be used in that signing operation, including that for this participant.
+    ///
+    /// Implements [`sign`] from the spec: https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-15.html#name-round-two-signature-share-g
+    pub fn sign(signing_package: &SigningPackage, signer_nonces: &SigningNonces, key_package: &KeyPackage) -> Result<SignatureShare, Error>;


This'll take signer_nonces: SigningNonces, not the borrow.

SigningNonces should be opaque, not be Clone, and not support any form of serialization, but they could be #[repr(transparent)] so that unsafe code can access the contents.

This makes SigningNonces a "linear type" or "session type", in that it cannot be used twice.

burdges · 2024-03-17T17:02:39Z

applications/ThresholdSignature.md

+    pub fn generate_simplpedpop(identifier: Identifier, max_signers: u16, min_signers: u16) -> Result<(SecretPackage, Package), Error>;
+
+    /// Verifies the messages received from all participants and returns the data for the equality check and DKG output.
+    pub fn verify_simplpedpop(secret_package: &SecretPackage, packages: &BTreeMap<Identifier, Package) -> Result<(KeyPackage, PublicKeyPackage), Error>;


I suppose SecretPackage could be a session type too, but maybe not so important.

burdges · 2024-03-17T17:10:41Z

applications/ThresholdSignature.md

+```rust
+pub mod simplpedpop {
+    /// Generates the SimplPedPop messages to be sent to the coordinator or directly to the other participants.
+    pub fn generate_simplpedpop(identifier: Identifier, max_signers: u16, min_signers: u16) -> Result<(SecretPackage, Package), Error>;


It's fine.

I'm kinda tempted to have signers field indices be arbitrary: Imagine 5 senior key holders run the DKG with a threshold of 4, but create an additional 2 or 3 shares which they delegate to junior key holders. If done simply then junior key holders would know how many senior key holders exist, but this could be hidden from them in various ways. This permits creating a threshold key where juniors do not knows how many key holders exist, which maybe useful for operational security. This is probably way overkill.

Yes, probably. Maybe leave it for a future iteration, if there is demand for it?

Yeah I realized after that this brings in considerable complexity. In principlem, there are benefits to using random indices, again for opsec, but this again requires an extra rounds. Let's omit for now.

burdges · 2024-03-17T17:12:41Z

All looks good to me. We'll have @elizabeth-crites make some comment too.

semuelle · 2024-03-20T15:00:38Z

In the meantime, could you (@Fiono11) fill out the KYC form (assuming you are applying as an individual, otherwise please use this form)?

Fiono11 · 2024-03-20T15:41:20Z

In the meantime, could you (@Fiono11) fill out the KYC form (assuming you are applying as an individual, otherwise please use this form)?

Done!

burdges · 2024-03-21T08:28:57Z

Amusingly @elizabeth-crites and I have not actually figured out if we like the delinearization in 1 or the delinearization in 2,3.

There is some malleability in 2,3 but we've not found any mechanism for abuse yet.

Fiono11 · 2024-03-21T12:14:11Z

Amusingly @elizabeth-crites and I have not actually figured out if we like the delinearization in 1 or the delinearization in 2,3.

There is some malleability in 2,3 but we've not found any mechanism for abuse yet.

Just noticed that step 2 of the FROST signing protocol in this document is actually wrongly described, since in the FROST3 optimization the Coordinator does not broadcast all nonce commitments but the multiplication of the nonce commitments.

Are you suggesting to implement Sparkle instead of FROST?

burdges · 2024-03-22T11:07:31Z

Isn't Sparkle 3 round? No not some three round one.

We'll stick with SimplePedPop because it's what serious folk like Tim picked, so other code exists for comparison.

We'll stick with Olaf because really nobody knows exploits for the malleability during signing.

All Approve this now.

burdges · 2024-03-22T11:12:08Z

applications/ThresholdSignature.md

+- **Full-Time Equivalent (FTE):**  1 FTE
+- **Total Costs:** 10,000 USD
+
+### Milestone 1 - Olaf Library Integration into [Schnorrkel repository](https://github.com/w3f/schnorrkel)


$5,000 is too little money for this. Increase it to $10,000. We'll add a third reviewer.

Add me on element: @jeff:web3.foundation and I'll help talk you through some of the schnorrkel code whenever you need help. In particular, there are already DLEQ proofs which work with more than two point pairs, which matye useful.

https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs#L627

https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs#L430

Thank you! I am really excited to work on this project!

…he FROST3 optimization

takahser

@Fiono11 thx for applying again with this improved proposal.
Pls adjust to lvl 2. Other than that, I think it's good to go. 👍

applications/ThresholdSignature.md

Co-authored-by: S E R A Y A <takahser@users.noreply.github.com>

github-actions · 2024-03-27T08:30:39Z

Congratulations and welcome to the Web3 Foundation Grants Program! Please refer to our Milestone Delivery repository for instructions on how to submit milestones and invoices, our FAQ for frequently asked questions and the support section of our README for more ways to find answers to your questions.

Before you start, take a moment to read through our announcement guidelines for all communications related to the grant or make them known to the right person in your organisation. In particular, please don't announce the grant publicly before at least the first milestone of your project has been approved. At that point or shortly before, you can get in touch with us at grantsPR@web3.foundation and we'll be happy to collaborate on an announcement about the work you’re doing.

Lastly, please remember to let us know in case you run into any delays or deviate from the deliverables in your application. You can either leave a comment here or directly request to amend your application via PR. We wish you luck with your project! 🚀

burdges · 2024-07-30T16:00:45Z

The work is basically done, and we should pay him. It'll be merged as w3f/schnorrkel#110

I've cleaned up a few minor things, primarily the clones and serializations that define the FRO part of FROST, and make sense for hardware signers, but looks really dangerous if used in pure software like Vault. I've some build stuff to clean up, but no reason not to go ahead and pay him.

semuelle · 2024-07-31T08:19:34Z

Thanks, @burdges!

Please submit your milestone(s) as per https://github.com/w3f/Grant-Milestone-Delivery, @Fiono11, so we can finish the evaluation and initiate the payment.

RouvenP · 2024-08-30T11:43:33Z

hi @Fiono11 we just settled the payment. Apologies for the delay!

github-actions bot added the admin-review This application requires a review from an admin. label Mar 14, 2024

Fiono11 mentioned this pull request Mar 14, 2024

FROST implementation #2225

Closed

11 tasks

Fiono11 force-pushed the new_frost_application branch 6 times, most recently from 0734fbe to ef44342 Compare March 14, 2024 15:42

Fiono11 force-pushed the new_frost_application branch 6 times, most recently from e1c5d9b to 95858ea Compare March 16, 2024 16:08

Threshold Signature Implementation

18cf899

Update ThresholdSignature.md

Fiono11 force-pushed the new_frost_application branch from 7ca6663 to 18cf899 Compare March 16, 2024 23:25

burdges reviewed Mar 17, 2024

View reviewed changes

semuelle self-assigned this Mar 20, 2024

semuelle removed the admin-review This application requires a review from an admin. label Mar 21, 2024

burdges approved these changes Mar 22, 2024

View reviewed changes

Fix the step 2 description of the FROST signing protocol to include t…

dc3518e

…he FROST3 optimization

github-actions bot added the admin-review This application requires a review from an admin. label Mar 22, 2024

Update Milestone 1 cost

6c2a1a9

semuelle added ready for review The project is ready to be reviewed by the committee members. and removed admin-review This application requires a review from an admin. labels Mar 22, 2024

semuelle previously approved these changes Mar 22, 2024

View reviewed changes

Noc2 previously approved these changes Mar 22, 2024

View reviewed changes

takahser requested changes Mar 24, 2024

View reviewed changes

applications/ThresholdSignature.md Outdated Show resolved Hide resolved

Fiono11 dismissed Noc2’s stale review via 4f6437d March 25, 2024 09:48

Update the application level

4f6437d

Co-authored-by: S E R A Y A <takahser@users.noreply.github.com>

Fiono11 dismissed semuelle’s stale review via 4f6437d March 25, 2024 09:48

github-actions bot added the admin-review This application requires a review from an admin. label Mar 25, 2024

Fiono11 requested review from takahser, Noc2 and semuelle March 25, 2024 09:49

Noc2 approved these changes Mar 25, 2024

View reviewed changes

takahser approved these changes Mar 27, 2024

View reviewed changes

semuelle approved these changes Mar 27, 2024

View reviewed changes

semuelle merged commit 03ccfc8 into w3f:master Mar 27, 2024
8 checks passed

Fiono11 mentioned this pull request Apr 5, 2024

Implementation of SimplPedPoP w3f/schnorrkel#102

Closed

Fiono11 mentioned this pull request Apr 19, 2024

Implementation of Olaf w3f/schnorrkel#104

Closed

This was referenced Aug 6, 2024

Threshold Signature Implementation: Milestone 1 Delivery w3f/Grant-Milestone-Delivery#1203

Merged

Amendment: Payment Address #2362

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Threshold Signature Implementation #2250

Threshold Signature Implementation #2250

Fiono11 commented Mar 14, 2024 •

edited

Loading

Fiono11 commented Mar 14, 2024

burdges Mar 17, 2024

burdges Mar 17, 2024

burdges Mar 17, 2024

Fiono11 Mar 18, 2024

burdges Mar 18, 2024

burdges Mar 17, 2024 •

edited

Loading

burdges Mar 17, 2024 •

edited

Loading

burdges Mar 17, 2024

burdges Mar 17, 2024

Fiono11 Mar 18, 2024

burdges Mar 18, 2024

burdges commented Mar 17, 2024

semuelle commented Mar 20, 2024

Fiono11 commented Mar 20, 2024

burdges commented Mar 21, 2024

Fiono11 commented Mar 21, 2024 •

edited

Loading

burdges commented Mar 22, 2024 •

edited

Loading

burdges Mar 22, 2024

Fiono11 Mar 22, 2024 •

edited

Loading

takahser left a comment

github-actions bot commented Mar 27, 2024

burdges commented Jul 30, 2024 •

edited

Loading

semuelle commented Jul 31, 2024

RouvenP commented Aug 30, 2024


		### General Overview

		This document outlines the proposal for implementing [Olaf](https://eprint.iacr.org/2023/899), the first FROST based protocol proven secure without relying on the [Algebraic Group Model](https://eprint.iacr.org/2017/620.pdf) (AGM) or an idealized key generation protocol. It is composed of:

Threshold Signature Implementation #2250

Threshold Signature Implementation #2250

Conversation

Fiono11 commented Mar 14, 2024 • edited Loading

Project Abstract

Grant level

Application Checklist

Fiono11 commented Mar 14, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burdges Mar 17, 2024 • edited Loading

Choose a reason for hiding this comment

burdges Mar 17, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burdges commented Mar 17, 2024

semuelle commented Mar 20, 2024

Fiono11 commented Mar 20, 2024

burdges commented Mar 21, 2024

Fiono11 commented Mar 21, 2024 • edited Loading

burdges commented Mar 22, 2024 • edited Loading

Choose a reason for hiding this comment

Fiono11 Mar 22, 2024 • edited Loading

Choose a reason for hiding this comment

takahser left a comment

Choose a reason for hiding this comment

github-actions bot commented Mar 27, 2024

burdges commented Jul 30, 2024 • edited Loading

semuelle commented Jul 31, 2024

RouvenP commented Aug 30, 2024

Fiono11 commented Mar 14, 2024 •

edited

Loading

burdges Mar 17, 2024 •

edited

Loading

burdges Mar 17, 2024 •

edited

Loading

Fiono11 commented Mar 21, 2024 •

edited

Loading

burdges commented Mar 22, 2024 •

edited

Loading

Fiono11 Mar 22, 2024 •

edited

Loading

burdges commented Jul 30, 2024 •

edited

Loading