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

[ZIP 312] Key generation #883

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

[ZIP 312] Key generation #883

wants to merge 3 commits into from

Conversation

str4d
Copy link
Collaborator

@str4d str4d commented Jul 23, 2024

No description provided.

@str4d str4d marked this pull request as draft July 23, 2024 22:30
Copy link
Contributor

@nuttycom nuttycom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK

@daira daira changed the title ZIP 312: Key generation [ZIP 312] Key generation Jul 30, 2024
conradoplg and others added 2 commits August 13, 2024 19:53
Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
@conradoplg
Copy link
Contributor

I added sketches of possible approaches to key generation

This option SHOULD be used if distributed key generation was used.
- (TODO: evaluate if it is secure) Participants derive :math:`\mathsf{sk}` from
the public keys of the particpants (`PK_i` in [#FROST]_) via (TODO: specify
mechanism to hash all PK_i and derive sk)
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the R&D Meeting today, @daira, @ebfull, @nuttycom and myself were discussing post-quantum Zcash preparations, and part of the approach we are discussing requires that ivk can be treated as a commitment to sk. I raised the point that with this draft proposal for FROST keygen, this is not the case. After discussion, we decided to suggest here that for FROST viewing keys, rivk be derived from (sk, ak, nk) instead of just sk. This is sufficient to ensure that Commit^ivk is effectively post-quantum binding (the argument is complicated, but a draft ZIP is forthcoming).

- (TODO: evaluate if it is secure) Participants derive :math:`\mathsf{sk}` from
the public keys of the particpants (`PK_i` in [#FROST]_) via (TODO: specify
mechanism to hash all PK_i and derive sk)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In all cases, the specification in § 4.2.2 ‘Sapling Key Components’ or § 4.2.3 ‘Orchard Key Components’
MUST be followed when generating key components. If `draft-ecc-quantum-resilience` is adopted, the
$\mathsf{allow\_arbitrary\_ask}$ flag MUST be set to true for the last two options.

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

Successfully merging this pull request may close these issues.

4 participants