Giters

zcash / orchard

Implementation of the Zcash Orchard Protocol

Home Page:https://zcash.github.io/orchard/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

API changes required for FROST

conradoplg opened this issue · comments

commented

I've updated our signing tool to the latest ECC crates and mapped out the API changes that are required in this crate:

  • Allowing constructing a SpendValidatingKey from bytes. Done in #428
  • Allow creating a FullViewingKey from a given SpendValidatingKey. The other components can be randomly generated, but there may be some utility in specifying them too. Done in #432
    • Locally I did this by adding a FullViewingKey::from_sk_ak(sk: &SpendingKey, ak: SpendValidatingKey) method, but not sure what is the best approach.
  • Allow creating a UnifiedFullViewingKey from a FullViewingKey. Done in zcash/librustzcash#1478
  • Allowing getting the generated randomizers (alphas) (done in #433), or preferrably, allow specifying which alphas to use.
    • I did the former by adding a alpha() getter to SigningParts (also added ak() getter which is useful to sanity check if I'm accessing the right SigningParts). The latter would be more complicated and would require passing the alphas in Builder::build() (which is awkward) or doing some refactoring.
    • (This might be moot now, see comment below) The reason the latter would be preferred is that Re-randomized FROST specifies a mechanism to generate alphas from the FROST signing package along with randomness, making sure that different packages will have different alphas. But the crate seems to assume that randomness will always be generated correctly (which is a fair assumption in this context) so this might not be needed.
    • While writing this I also realized that this crate does not seem to strictly follow Zcash's spec on how the alpha is generated (it doesn't use the H* hash function). Again, not a big deal for the same reason.

My intention is to spark discussion on these API changes but let me know if you'd prefer individual tickets for each of those. I can also create PRs if you're happy with the proposed APIs or can also create PRs with other APIs you suggest.

commented

I realized there is a chicken-and-egg problem regarding the second approach to alpha handling:

  • The sighash, which is the thing FROST signs, depends on rk, which depends on alpha
  • The "FROST alpha generation" requires the SigningPackage, which contains the message, which is the sighash

So it seems the "FROST alpha generation" can't be used.

commented

please edit:

  • Allow creating a UnifiedFullViewingKey from a FullViewingKey. There is a new() method which could be used but it's gated under the test-dependencies feature. zcash/librustzcash#1478
commented

please edit:
Allow creating a FullViewingKey from a given SpendValidatingKey. The other components can be randomly generated, but there may be some utility in specifying them too.
Locally I did this by adding a FullViewingKey::from_sk_ak(sk: &SpendingKey, ak: SpendValidatingKey) method, but not sure what is the best approach.

#432