There is duplicate code inside frost-core between it and frost-ristretto; we can retain testing for frost-core by using the MockCurve type provided by RustCrypto instead and remove the duplication.

Computer-aided cryptographic proofs: https://github.com/EasyCrypt/easycrypt

Even in an overkill way, just to be explicit and clear

Especially the test vectors right now

All things related to frost merged into one epic for tracking purposes

We want to have some stuff ready for Zcon, mainly the ZIP

Generic to groups where we define a cofactor (1 or other) and the order of the prime order group, so that we can share common logic across multiple impls / parameter sets.

https://github.com/cfrg/draft-irtf-cfrg-frost/pull/150/files

These are the signing pariticipant's secret share and corresponding public key, as opposed to the "full signature" signing key and verifying key. We have another type called SecretShare that has more metadata, hence not being named such, but we probably should rename them for clarity. This is somewhat low priority while the frost-core API remains unstable (by SemVer standards).

• Duplicate frost-ristretto255 framework
• Pull in RustCrypto/secp256k1, not the C one
• Implement concrete FrostSecp256k1 implementation of Ciphersuite
• Pull test vectors from draft-irtf-cfrg-frost
• Release frost-secp256k1

This repo needs a README

We want to support all curves defined in the spec.

https://github.com/hacspec/hacspec

Such as 2-of-2 threshold signing, whether allowing a scalar to be zero (or a group element to be the identity) breaks that.

https://github.com/cfrg/draft-irtf-cfrg-frost/pull/165/files

Ideas:

• can't extract honest participant's secret share
• can't deduce group secret signing key
• can't forge signature (EUF-CMA)
• can't forge colliding signature (SUF-CMA)
• can't forge/malleate signature to verify under !the group verification key (key substitution)

Show that any/all of these can be achieved with t colluding participants, then show that it fails with t-1 colluding participants.

We now have an Identifier type that wraps a Scalar field element, for polynomial id's, that is much harder to confused than an index into any data structure that may also have an index, like an array.

• Update all usage of participant ID's to be Identifier in frost-core
• Check the public API of frost-core to make sure all those are using Identifier
• Check all known consumers of public frost-core API to upgrade them to use Identifier where needed
• If any API changes are made, publish releases of those crates

This Epic will track any extensions in functionality not currently included in the IETF draft

Tasks

• Implement message serialization
• Implement DKG
• Implement ability for any signing participant to act as an aggregator
• Share redistribution- allow t signers to add/remove new members and ratchet forward the secret for forward secrecy

This is to just track the work, it will be done in the IETF repo

Some changes to share structure, new test vectors: https://www.ietf.org/id/draft-irtf-cfrg-frost-03.html

Motivation

We want to be able to:

• Repair a user share (recompute it if it's lost)
• Add new signers - Just "recover" the share of the new user (e.g. using its identifier)

Design

• Implement the Enrolment scheme from https://eprint.iacr.org/2017/1155.pdf
  (or the Reduced Enrolment scheme; evaluate which one is better)
• Like the rest of the FROST implementation, communication is up to the caller, so we just want to provide functions to repair and add signers
• Write a test, e.g. simulating the communication using a HashMap

Preliminary design of functions to be implemented:

- helpers: Set of identifiers (signers that will help recover)
- requester: The identifier of the signer that lost their share


# For every single helper i in helpers:

# i: the identifier of the signer helping
# helpers: as above
# share_i: i's secret share
# zeta_i: Lagrange coefficient (?)
# - Note: may be able to be computed inside the function, check
# Output: i_deltas: random values that sum up to zeta_i * share _i
compute_random_values(i, helpers, share_i, zeta_i) -> deltas_i

# Communication round:
# Helper i sends deltas_i[j] to helper j

# j: the identifier of the signer helping
# helpers: as above
# deltas_j: values received by j in the communication round
# Output: sigma_j
compute_sum_of_random_values(j, helpers, deltas_j) -> sigma_j

# Communication round
# Helper j sends sigma_j to signer r

# sigmas: all sigma_j received from each helper j
# Output: share_r: r's secret share
recover_share(sigmas) -> share_r

Specifications

See https://github.com/chelseakomlo/talks/blob/master/2019-combinatorial-schemes/A_Survey_and_Refinement_of_Repairable_Threshold_Schemes.pdf

• #44
• #47

This Epic will outline the required work to make the FROST library match the FROST draft spec

Tasks

• #12
• #13
• #14
• #15
• #16
• #17

Half of the public items are well-doc'd, half just have placeholders to allow compilation.

Currently the ristretto255 is working with frost-core V4. Update it to V5.

Per cfrg/draft-irtf-cfrg-frost#130

We want to support all curves defined in the spec.

The spec defines FROST on P256 curve, we should write a reference implementation for it.

Tasks

• [ ]

We want to support all curves defined in the spec.

• Create frost-p256 library crate
• Pull in p256 crate: https://docs.rs/p256/latest/p256/
• Pull in the sha2 crate
• Pull in frost-core
• Implement Ciphersuite and all dependent types and methods for a P256Sha256 type
• Pull in test vectors from spec/spec repo in json form
• Port/adapt code from frost-ristretto255 to parse and produce instances of types for P256Sha256 types
• Test against test vectors (

  frost/frost-ristretto255/src/tests.rs

  Line 30 in a0bf3c5

  fn check_sign_with_test_vectors() {

  )
• Test that secret sharing and reconstruction works (

  frost/frost-ristretto255/src/tests.rs

  Line 12 in a0bf3c5

  fn check_share_generation_ristretto255_sha512() {

  )
• Test signing from a fresh keygen by dealer (

  frost/frost-core/tests/frost.rs

  Line 11 in a0bf3c5

  fn check_sign_with_dealer() {

  )
  - [ ] Create frost-p256 crate on crates.io
  - [ ] Publish?

Publish as part of #79 when frost-core is updated, etc

Allows us to namespace types by their round, allowing us to enforce things like "only commitments generated in Round 1 are used to check signature shares in Round 2"

Right now this test only exists in frost-core, it should also have a version in each dependent library, and possibly be a doctest in the README of each top level crate.

Depends on cfrg/draft-irtf-cfrg-frost#17

We want to have a similar set of labels on the FROST repo as we do for Zebra

The draft introduces a performance improvement for how rho is derived and used. This change should be carried into this implementation.

See https://github.com/ZcashFoundation/frost/blob/main/frost-redjubjub/src/frost.rs#L473

and cfrg/draft-irtf-cfrg-frost#28

This removes the contribution of the participant id i from generating rho, so that all participants should be generating the same rho. This has been shown to be secure.

v5: https://www.ietf.org/archive/id/draft-irtf-cfrg-frost-05.html

From the spec changelog:

• Update test vectors to include version string
  • Rename THRESHOLD_LIMIT to MIN_SIGNERS (this will be automatically done when updating test vectors; the code doesn't read that field so no further changes are needed)
• Use non-contiguous signers for the test vectors
• Add a function to generate nonces (#182)
  - [ ] Add MUST that all participants have the same view of VSS commitment
• Use THRESHOLD_LIMIT instead of t and MAX_SIGNERS instead of n
  - [x] Remove wire format section (#156)
• Update group commitment derivation to have a single scalarmul
• Use RandomNonzeroScalar for single-party Schnorr example (this should not be needed if we use nonce_generate instead)

When #35 is done, use that to provide DKG for the Ristretto255 ciphersuite

• Pull in supporting frost-core version
• Implement for concrete FrostRistretto255 Ciphersuite
• Release minor version of frost-ristretto255 crate

We implemented FROST for redjubjub (and later ported to redpallas inside the zebra/zebra-chain repo) long ago, and while all that code needs to be updated to match the spec now, the goal was to slot that into the SpendAuth signature for Zcash Sapling and now Orchard.

There are notes for a re-randomized FROST signatures (at least in the Zcash setting) security proof that need to be completed to support the properties we need to preserve for Zcash and for FROST, but we should get started on a ZIP that defines the Jubjub and Pallas ciphersuites for Zcash usage, just like they are specified in the IETF spec, and how we think the re-randomization should work (pending verification by the security proof), and how this fits into the Sapling and Orchard key derivation trees.

We can draft that ZIP here and when we feel it is ready for Zcash consideration, move it the ZIPs repo and link to any final state of it from here.

We should also of course in frost-redjubjub and frost-redpallas include examples of how the re-randomization is done, and in Zebra code likely, call frost-redjubjub / frost-redpallas as part of keygen and signing operations, at least as an example/test.

This Epic will track the work required to implement cfrg/draft-irtf-cfrg-frost#22

Tasks

• Review code for the various implementations to check implementation is spec conformant
  • frost-dalek
  • frost-ristretto255
• Generate Test vectors
  • Define how test vectors are generated in spec
• Interop testing with frost-dalek
• Interop testing with frost-ristretto255
• Ensure implementations conform to spec

Implement the distributed key generation in frost-core, generic over the ciphersuite.

• Implement generic DKG
• Release minor version update for frost-core

Get everything ready for the IETF presentation