-
Notifications
You must be signed in to change notification settings - Fork 161
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK
Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
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) |
There was a problem hiding this comment.
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) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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. | |
No description provided.