-
Notifications
You must be signed in to change notification settings - Fork 152
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] FROST for Spend Authorization Signatures #662
Conversation
Co-authored-by: Deirdre Connolly <durumcrustulum@gmail.com>
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: teor <teor@riseup.net>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
Co-authored-by: Daira Hopwood <daira@jacaranda.org>
zip-0312.rst
Outdated
- H1(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubR", m), interpreting | ||
the 64 bytes as a little-endian integer, and reducing the resulting integer | ||
modulo ``G.Order()``. | ||
- H2(m): Implemented by computing BLAKE2b-512("Zcash_RedJubjubH", m), interpreting | ||
the 64 bytes as a little-endian integer, and reducing the resulting integer | ||
modulo ``G.Order()``. | ||
(This is equivalent to :math:`\mathsf{H}^\circledast(m)`, as defined by | ||
the :math:`\mathsf{RedJubjub}` scheme instantiated in [#protocol-concretereddsa]_.) | ||
- H3(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubN", m), interpreting | ||
the 64 bytes as a little-endian integer, and reducing the resulting integer | ||
modulo ``G.Order()``. | ||
- H4(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubM", m). | ||
- H5(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubC", m). | ||
- HR(m): Implemented by computing BLAKE2b-512("FROST_RedJubjubA", m), interpreting | ||
the 64 bytes as a little-endian integer, and reducing the resulting integer | ||
modulo ``G.Order()``. |
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.
Check if some of those can be matched to RedDSA hashes
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.
RedDSA basically uses the same function for HR and H2. I don't think we gain anything by making them them equal in this ZIP since FROST already requires a bunch of domain-separated hash functions anyway.
Co-authored-by: Daira Emma Hopwood <daira@jacaranda.org>
zip-0312.rst
Outdated
While key generation is out of scope for this ZIP and the FROST spec [#FROST]_, | ||
it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The spend | ||
authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_ is the | ||
particular key that must be used in the context of this ZIP. Note that the | ||
:math:`\mathsf{ask}` is usually derived from the spending key | ||
:math:`\mathsf{sk}`, though that is not required. Not doing so allows using | ||
distributed key generation, since the key it generates is unpredictable. Note | ||
however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents | ||
using seed phrases to recover the original secret (which may be something | ||
desirable in the context of FROST). |
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.
While key generation is out of scope for this ZIP and the FROST spec [#FROST]_, | |
it needs to be consistent with FROST, see [#frost-tdkg]_ for guidance. The spend | |
authorization private key :math:`\mathsf{ask}` [#protocol-spendauthsig]_ is the | |
particular key that must be used in the context of this ZIP. Note that the | |
:math:`\mathsf{ask}` is usually derived from the spending key | |
:math:`\mathsf{sk}`, though that is not required. Not doing so allows using | |
distributed key generation, since the key it generates is unpredictable. Note | |
however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents | |
using seed phrases to recover the original secret (which may be something | |
desirable in the context of FROST). | |
While key generation is out of scope for this ZIP and the FROST spec [#FROST]_, | |
it needs to be consistent with FROST; see [#frost-tdkg]_ for general guidance. | |
To define a spending or viewing key that uses FROST, the Sapling and Orchard key | |
trees [#protocol-saplingkeycomponents]_ [#protocol-orchardkeycomponents]_ are | |
adjusted as follows: | |
- The Spend validating key :math:`\mathsf{ak}` is replaced by the FROST group | |
public key `PK` [#frost-protocol]_. | |
- The Spend authorizing key :math:`\mathsf{ask}` is replaced by the logical | |
signing key that corresponds to the group public key `PK`. By design, this | |
key never exists, and instead is represented by each participant's FROST | |
signing key share `sk_i`. | |
The remaining parts of the Sapling and Orchard key trees are generated from | |
a common... (TODO: Finish specifying how the other common parts of the | |
Sapling and Orchard key trees are derived for participants, perhaps in terms | |
of a common `sk` or a common HD path.) | |
(Old remaining content below, which might change after the above TODO.) | |
Note that the :math:`\mathsf{ask}` is usually derived from the spending key | |
:math:`\mathsf{sk}`, though that is not required. Not doing so allows using | |
distributed key generation, since the key it generates is unpredictable. Note | |
however that not deriving :math:`\mathsf{ask}` from :math:`\mathsf{sk}` prevents | |
using seed phrases to recover the original secret (which may be something | |
desirable in the context of FROST). |
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.
Moved to #883.
Co-authored-by: Daira-Emma Hopwood <daira@jacaranda.org>
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.
Scanned over this in a pairing with @nuttycom. ACK 6e6893d8323103013163586eb7e3c53e929a14b4
for merging as draft. There are editorial changes that we can make in subsequent PRs; I'll also move my suggestion for keygen to a new PR.
Adds a ZIP specifying how to use FROST to generate Spend Authorization signatures.
Note that there was a previous round of review on the PR targetting our fork (which will be closed): ZcashFoundation#3
But now this is the "official" submission.
I chose to leave the commit history, let me know if you'd like for me to squash them.
fixes #382