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

Frost CI check #3

Open
wants to merge 35 commits into
base: master
Choose a base branch
from
Open

Frost CI check #3

wants to merge 35 commits into from

Conversation

jonasnick
Copy link
Owner

No description provided.

This commit adds the foundational configuration and building scripts
and an initial structure for the project.
This commit adds share generation, as well as share serialization and
parsing.
This commit adds share aggregation and verification, as well as
computation of public verification shares.
This commits adds nonce generation, as well as serialization and
parsing.
This commits add BIP-341 ("Taproot") and BIP-32 ("ordinary") public key
tweaking.
This commit adds nonce aggregation, as well as adaptor signatures.
This commit adds signature generation and aggregation, as well as
partial signature serialization and parsing.
Add api tests, nonce tests, tweak tests, sha256 tag tests, and valgrind
constant time tests.
This commit adds an example file to demonstrate how to use the module.
This commit adds a documentation file with detailed instructions for how
to use the module properly.
Responds to comment from @jonasnick:

> `frost.md` says
>
> > the API supports an alternative protocol flow where generating the key (see Key Generation above) is allowed to happen after exchanging nonces (step 3).
>
> While this is possible with MuSig2, I haven't considered whether it's possible in FROST. If it is possible in principle, then I believe the `agg_pk` must also be input to the `noncehash` - similar to how this is done in MuSig2.
>
> The security proof for MuSig relies on the following property: For any two executions of the `sign` algorithm, if the challenge `c` in the first execution differs from the challenge `c'` in the second execution, then the nonce coefficient in the first execution `b` must differ from the nonce coefficient in the second execution `b'`. In short: `c != c' => b != b'`.
>
> If `agg_pk` is not hashed into `b` as is the case right now with this PR, then `agg_pk` affects `c` but not `b`, and the above implication does not hold.

See BlockstreamResearch#138 (comment)
Responds to comment by @jonasnick:

> If this is not done and a single nonce coefficient `b` is used for all signers, then the input to the hashing function that determines `b` must include all values that affect the value of Lagrange coefficient `l`. Otherwise, the implementation is vulnerable to an attack on `l` that is similar to the attack against two round musig without nonce coefficients.
>
> Similar to the implication `c != c' => b != b'` (where `b,c` and `b',c'` are the values for the nonce coefficients and challenges in two execution of the signing algorithm) mentioned [here](BlockstreamResearch#138 (comment)), we want `l != l' => b != b'`. In particular this means that the set of signers participating in the signature needs to be hashed into `b`.

See BlockstreamResearch#138 (comment)
Responds to comment by @ariard:

> It could be valuable to add an example for a FROST-based adaptor
signature protocol. I can try to add one later.

See
BlockstreamResearch#138 (comment)
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.

2 participants