[ZIP 312] Specify key generation, change randomizer handling #895
Conversation
conradoplg
left a comment
conradoplg
left a comment
There was a problem hiding this comment.
Addressed comments in did some additional improvements/cleanups
nuttycom
force-pushed
the
frost-randomizer
branch
from
42b086e to
0d08f3f
Compare
|
force-pushed to resolve conflicts with |
daira
force-pushed
the
frost-randomizer
branch
from
5100d80 to
9c24f21
Compare
|
Recent changes all look good to me. What are you thinking for next steps? I think we could merge this and work on the rest in other PRs? What I think is missing:
|
| The "Owners", "Credits", and "Original-Authors" headers always use | ||
| these plural spellings even if there is only one Owner, one person to | ||
| be credited, or one original author. The "Pull-Request" header always | ||
| uses this singular spelling even there are multiple Pull Requests. |
There was a problem hiding this comment.
I confirmed that these changes to ZIP 0 are either clarifications, or straightforward improvements to the ZIP metadata by a ZIP Editor, and I do not think these require full consensus from the ZIP Editors. But also, ACK on these changes with my ZIP Editor hat on.
There was a problem hiding this comment.
I hadn't finished reviewing the changes in this file, and didn't have any comments indicating where I'd reached in my review, so assume I didn't review this one file.
daira
force-pushed
the
frost-randomizer
branch
from
9c24f21 to
5d9375d
Compare
Co-authored-by: Daira-Emma Hopwood <[email protected]>
Co-authored-by: Jack Grigg <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
ZIP 0: Document that the Pull-Request header uses the singular spelling even if there are multiple PRs (there are several existing cases of this). Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
update references. Signed-off-by: Daira-Emma Hopwood <[email protected]>
as a prerequisite for unlinkability of Sapling and Orchard spend authorization signatures. Signed-off-by: Daira-Emma Hopwood <[email protected]>
(In my opinion it completely defeats the point of a threshold signature scheme.) Signed-off-by: Daira-Emma Hopwood <[email protected]>
(This might be moved into another PR.) Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
daira
force-pushed
the
frost-randomizer
branch
from
5d9375d to
e4f37a4
Compare
…IP 2005. Signed-off-by: Daira-Emma Hopwood <[email protected]>
Signed-off-by: Daira-Emma Hopwood <[email protected]>
| multiplication, where the protocol spec would use $[k] P$ with the group | ||
| implied by $P$. | ||
|
|
||
| An additional per-ciphersuite hash function is used, denote ``HR(m)``, which |
There was a problem hiding this comment.
Also remove the corresponding instantiations of HR below.
EDIT: maybe not, see comment below.
| A suitable DKG protocol is COCKTAIL-DKG [#cocktail-dkg]_, which is supported by | ||
| the Zcash Foundation's reference implementation of FROST [#zf-frost-dkg]_. | ||
| COCKTAIL-DKG assumes that each participant has a static public key known to all | ||
| other participants. As noted in its documentation, the reference implementation | ||
| also requires participants to broadcast the commitment values honestly (i.e. | ||
| participants do not provide different commitment values to a subset of | ||
| participants), over a secure broadcast channel [#frost-term-broadcast-channel]_. | ||
|
|
||
| Other Distributed Key Generation protocols MAY be used. |
There was a problem hiding this comment.
@conradoplg Does the ZF reference impl actually implement ChillDKG (on which COCKTAIL-DKG is based), or does it implement the DKG from the original FROST paper? If the latter, is that actually compatible with ChillDKG?
Without confirmation to the affirmative (especially because COCKTAIL-DKG is not finished), we should not claim it:
| A suitable DKG protocol is COCKTAIL-DKG [#cocktail-dkg]_, which is supported by | |
| the Zcash Foundation's reference implementation of FROST [#zf-frost-dkg]_. | |
| COCKTAIL-DKG assumes that each participant has a static public key known to all | |
| other participants. As noted in its documentation, the reference implementation | |
| also requires participants to broadcast the commitment values honestly (i.e. | |
| participants do not provide different commitment values to a subset of | |
| participants), over a secure broadcast channel [#frost-term-broadcast-channel]_. | |
| Other Distributed Key Generation protocols MAY be used. | |
| A suitable DKG protocol is COCKTAIL-DKG [#cocktail-dkg]_. | |
| COCKTAIL-DKG assumes that each participant has a static public key known to all | |
| other participants. | |
| Other Distributed Key Generation protocols MAY be used. For example, the Zcash | |
| Foundation's reference implementation of FROST [#zf-frost-dkg]_ includes a DKG | |
| implementation for some ciphersuites. As noted in its documentation, the reference | |
| implementation requires participants to broadcast the commitment values honestly | |
| (i.e. participants do not provide different commitment values to a subset of | |
| participants), over a secure broadcast channel [#frost-term-broadcast-channel]_. |
EDIT: https://github.com/ZcashFoundation/frost/blob/main/frost-core/src/keys/dkg.rs makes it clear that it implements the DKG from the original FROST paper. So we need confirmation about whether or not that is exactly compatible with COCKTAIL-DKG.
There was a problem hiding this comment.
Apologies, I missed that. No we don't support COCKTAIL-DKG (though you could build it on top of the libraries)
| - One participant generates a random $\mathsf{sk}$ and sends it to the | ||
| others via an encrypted and authenticated channel. This option SHOULD be used | ||
| if trusted dealer key generation was used, and the $\mathsf{sk}$ value | ||
| can be sent along with the FROST shares during key generation. This option MAY | ||
| be used if Distributed Key Generation was employed, if participants find it | ||
| acceptable to trust one participant to correctly generate $\mathsf{sk}$. | ||
| - Participants generate a $\mathsf{sk}$ in a contributory manner, for example | ||
| using the method defined in `Contributory Generation of sk`_. This approach | ||
| SHOULD be used to generate $\mathsf{sk}$ if Distributed Key Generation was | ||
| employed. |
There was a problem hiding this comment.
| - One participant generates a random $\mathsf{sk}$ and sends it to the | |
| others via an encrypted and authenticated channel. This option SHOULD be used | |
| if trusted dealer key generation was used, and the $\mathsf{sk}$ value | |
| can be sent along with the FROST shares during key generation. This option MAY | |
| be used if Distributed Key Generation was employed, if participants find it | |
| acceptable to trust one participant to correctly generate $\mathsf{sk}$. | |
| - Participants generate a $\mathsf{sk}$ in a contributory manner, for example | |
| using the method defined in `Contributory Generation of sk`_. This approach | |
| SHOULD be used to generate $\mathsf{sk}$ if Distributed Key Generation was | |
| employed. | |
| - Participants generate a $\mathsf{sk}$ in a contributory manner, for example | |
| using the method defined in `Contributory Generation of sk`_. This approach | |
| SHOULD be used to generate $\mathsf{sk}$ if Distributed Key Generation was | |
| employed. | |
| - One participant generates a random $\mathsf{sk}$ and sends it to the | |
| others via an encrypted and authenticated channel. This option SHOULD be used | |
| if trusted dealer key generation was used, and the $\mathsf{sk}$ value | |
| can be sent along with the FROST shares during key generation. This option is | |
| NOT RECOMMENDED if Distributed Key Generation was employed. |
|
|
||
| A contribution list is a value of the form $[(i, \mathtt{contribution}_{\,i}),\, \ldots]$. | ||
| Each element in the list indicates a NonZeroScalar identifier $i$ and a byte | ||
| sequence $\mathtt{contribution}_{\,i}$. This list MUST be sorted in ascending |
There was a problem hiding this comment.
Clarify that all contribution_is in a contribution list are the same length (so the encoding is well-defined).
| randomizer_input = rng_randomizer || signing_package_enc | ||
| return HR(randomizer_input) | ||
| def randomizer_generate(commitment_list): | ||
| return randomness_generate(commitment_list, Ns, H2) |
There was a problem hiding this comment.
Bug: in the existing ZIP this is HR, not H2. Check whether this was a bug in the existing ZIP contents, or a bug in this PR removing HR, and resolve the bug.
| 1. The Coordinator chooses a random seed | ||
| $\mathtt{sk\_seed} = \mathtt{random\_bytes}(\mathtt{Nh})$. |
There was a problem hiding this comment.
Bug: this sk_seed is not used.
| 1. The Coordinator chooses a random seed | |
| $\mathtt{sk\_seed} = \mathtt{random\_bytes}(\mathtt{Nh})$. |
| 4. All parties regenerate $\mathsf{sk}$ using | ||
| $\mathtt{sk\_regenerate}(\mathtt{sk\_seed}, \mathtt{contribution\_list})$, | ||
| and they include a Pedersen commitment to it in the transcript. |
There was a problem hiding this comment.
Bug: the other participants cannot run this, as they do not learn the contribution_i values from the other participants due to (in the current spec) them not being broadcast.
We have instead suggested a modification to COCKTAIL-DKG to enable us to leverage its broadcast properties: C2SP/C2SP#164 (comment)
If the modification were made, them we'd use it as follows:
additional_contribution_{i,j} = contribution_i- Add some sufficiently-blinding commitment to
skto the transcript, to ensure that everyone computed the same value.
str4d
changed the title
|
The next step is to rebase out f9e077d and afc247b since those changes cannot work, and instead do what @str4d says in #895 (comment) . I cannot do that on my phone; can someone else do it? |
Changes to randomizer handling after I realized that it couldn't possibly be generated using the message as an input. It does simplify things too.
Some additional fixes (using "Re-Randomized FROST" consistently; updating Owners)
fixes #1051