zecfoundation
/
frost-zcash-demo
mirror of https://github.com/ZcashFoundation/frost-zcash-demo.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update READMEs (#54) (#71)

This commit is contained in:
natalie 2023-08-21 23:01:16 +01:00 committed by GitHub
parent bb4ea6b3e7
commit 2c0ad41227
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 238 additions and 52 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
README.md
View File

@ -1,7 +1,5 @@
# Zcash Foundation FROST Demos
TODO
This will be part of a set of demos and a proof of concept application that uses the FROST libraries and reference implementation. The purpose of these demos is to:
1. identify gaps in our documentation
@ -18,9 +16,20 @@ schemes in general assume that an adversary can corrupt strictly fewer than a th
[Two-Round Threshold Schnorr Signatures with FROST](https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/) presents a variant of a Flexible Round-Optimized Schnorr Threshold (FROST) signature scheme originally defined in [FROST20](https://eprint.iacr.org/2020/852.pdf). FROST reduces network overhead during threshold
signing operations while employing a novel technique to protect against forgery attacks applicable to prior Schnorr-based threshold signature constructions. This variant of FROST requires two rounds to compute a signature, and implements signing efficiency improvements described by [Schnorr21](https://eprint.iacr.org/2021/1375.pdf). Single-round signing with FROST is not implemented here.
## Projects
This repo contains 4 projects:
1. [Trusted Dealer](https://github.com/ZcashFoundation/frost-zcash-demo/tree/main/trusted-dealer)
2. [DKG](https://github.com/ZcashFoundation/frost-zcash-demo/tree/main/dkg)
3. [Coordinator](https://github.com/ZcashFoundation/frost-zcash-demo/tree/main/coordinator)
4. [Participant](https://github.com/ZcashFoundation/frost-zcash-demo/tree/main/participant)
## Status ⚠
TODO
Trusted Dealer demo - WIP
DKG demo - WIP
Coordinator demo - WIP
Participant demo - WIP
## Usage
@ -31,11 +40,13 @@ You will need to have [Rust and Cargo](https://doc.rust-lang.org/cargo/getting-s
To run:
1. Clone the repo. Run `git clone https://github.com/ZcashFoundation/frost-zcash-demo.git`
2. Run `cargo install`
3. Run `cargo run`
## Developer information
and in separate terminals:
3. Run `cargo run --bin trusted-dealer` or `cargo run --bin dkg`
4. Run `cargo run --bin coordinator`
5. Run `cargo run --bin participants`. Do this in separate terminals for separate participants.
TODO
## Developer Information
### Pre-commit checks

63
coordinator/README.md
View File

@ -1,22 +1,6 @@
# FROST Coordinator Demo
TODO
This will be part of a set of demos and a proof of concept application that uses the FROST libraries and reference implementation. The purpose of these demos is to:
1. identify gaps in our documentation
2. provide usage examples for developer facing documentation
3. provide reference implementations for developers wanting to use FROST in a “real world” scenario.
This demo uses the (Ed25519, SHA-512) ciphersuite. The crate can be found [here](https://crates.io/crates/frost-ed25519).
## About FROST (Flexible Round-Optimised Schnorr Threshold signatures)
Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers, each holding a share of a common private key. The security of threshold
schemes in general assume that an adversary can corrupt strictly fewer than a threshold number of participants.
[Two-Round Threshold Schnorr Signatures with FROST](https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/) presents a variant of a Flexible Round-Optimized Schnorr Threshold (FROST) signature scheme originally defined in [FROST20](https://eprint.iacr.org/2020/852.pdf). FROST reduces network overhead during threshold
signing operations while employing a novel technique to protect against forgery attacks applicable to prior Schnorr-based threshold signature constructions. This variant of FROST requires two rounds to compute a signature, and implements signing efficiency improvements described by [Schnorr21](https://eprint.iacr.org/2021/1375.pdf). Single-round signing with FROST is not implemented here.
[Overview of demos](https://github.com/ZcashFoundation/frost-zcash-demo/blob/main/README.md)
## Status ⚠
@ -31,18 +15,51 @@ You will need to have [Rust and Cargo](https://doc.rust-lang.org/cargo/getting-s
To run:
1. Clone the repo. Run `git clone https://github.com/ZcashFoundation/frost-zcash-demo.git`
2. Run `cargo install`
3. Run `cargo run`
3. Run `cargo run --bin coordinator`
TODO
### Step 1
## Using the output
The coordinator CLI will prompt for:
TODO
1. The public key package
2. The number of signers participating and their corresponding identifiers
### Communication round
Each participant will send their commitments
### Step 2
The coordinator CLI will prompt for:
1. A message
2. The commitments for each participant
The coordinator CLI will then use that data to generate:
1. Signing package
### Communication round
The signing package will be sent to all participants
The coordinator will receive each participant's signature shares
### Step 3
The coordinator CLI will prompt for:
1. Signature shares for ecah participant
The coordinator CLI will then use that data to generate:
1. The group signature
### Communication round
The group signature will then be sent to all participants
## Developer information
TODO
### Pre-commit checks
1. Run `cargo make all`

75
dkg/README.md Normal file
View File

@ -0,0 +1,75 @@
# FROST DKG Demo
[Overview of demos](https://github.com/ZcashFoundation/frost-zcash-demo/blob/main/README.md)
## Status ⚠
The DKG Demo is a WIP
## Usage
NOTE: This is for demo purposes only and should not be used in production.
You will need to have [Rust and Cargo](https://doc.rust-lang.org/cargo/getting-started/installation.html) installed.
To run:
1. Clone the repo. Run `git clone https://github.com/ZcashFoundation/frost-zcash-demo.git`
2. Run `cargo install`
3. Run `cargo run --bin dkg`
### Round 1 send package
The DKG demo will prompt for:
1. Minimum number of signers (>= 2) i.e. The threshold number of signers for the secret sharing scheme.
2. Maximum number of signers i.e. the number of shares to generate
3. An identifier
The dkg CLI will then use that data to generate:
1. A round 1 package to send to all other signers
### Round 2 send packages
The DKG demo will prompt for:
1. Identifiers of all signers
2. Their corresponding round 1 package
The dkg CLI will then use that data to generate:
1. A round 2 package to send to other users
### Round 2 receive packages
The DKG demo will prompt for:
1. Identifiers of all signers
2. Their corresponding round 2 package
The dkg CLI will then use that data to generate:
1. A key package
2. A public key package
## Using the output
To generate a key package the participant requires:
* The signer's identifier
* The signer's secret share
* The signer's public key
* The public signing key that represents the entire group
## Developer information
### Pre-commit checks
1. Run `cargo make all`
### Coverage
Test coverage checks are performed in the pipeline. This is configured here: `.github/workflows/coverage.yaml`
To run these locally:
1. Install coverage tool by running `cargo install cargo-llvm-cov`
2. Run `cargo make cov` (you may be asked if you want to install `llvm-tools-preview`, if so type `Y`)

53
participant/README.md
View File

@ -1,22 +1,6 @@
# FROST Participant Demo
TODO
This will be part of a set of demos and a proof of concept application that uses the FROST libraries and reference implementation. The purpose of these demos is to:
1. identify gaps in our documentation
2. provide usage examples for developer facing documentation
3. provide reference implementations for developers wanting to use FROST in a “real world” scenario.
This demo uses the (Ed25519, SHA-512) ciphersuite. The crate can be found [here](https://crates.io/crates/frost-ed25519).
## About FROST (Flexible Round-Optimised Schnorr Threshold signatures)
Unlike signatures in a single-party setting, threshold signatures require cooperation among a threshold number of signers, each holding a share of a common private key. The security of threshold
schemes in general assume that an adversary can corrupt strictly fewer than a threshold number of participants.
[Two-Round Threshold Schnorr Signatures with FROST](https://datatracker.ietf.org/doc/draft-irtf-cfrg-frost/) presents a variant of a Flexible Round-Optimized Schnorr Threshold (FROST) signature scheme originally defined in [FROST20](https://eprint.iacr.org/2020/852.pdf). FROST reduces network overhead during threshold
signing operations while employing a novel technique to protect against forgery attacks applicable to prior Schnorr-based threshold signature constructions. This variant of FROST requires two rounds to compute a signature, and implements signing efficiency improvements described by [Schnorr21](https://eprint.iacr.org/2021/1375.pdf). Single-round signing with FROST is not implemented here.
[Overview of demos](https://github.com/ZcashFoundation/frost-zcash-demo/blob/main/README.md)
## Status ⚠
@ -31,18 +15,41 @@ You will need to have [Rust and Cargo](https://doc.rust-lang.org/cargo/getting-s
To run:
1. Clone the repo. Run `git clone https://github.com/ZcashFoundation/frost-zcash-demo.git`
2. Run `cargo install`
3. Run `cargo run`
3. Run `cargo run --bin participant`
TODO
### Round 1
## Using the output
The participant CLI will prompt for:
TODO
1. Your secret share or key package
The participant CLI will then use that data to generate:
1. Signing nonces
2. Signing commitments
### Communication round
The signing commitments will be sent to the coordinator
The coordinator will then send the signing package
### Round 2
The participant CLI will prompt for:
1. Signing package
The participant CLI will then use that data to generate:
1. Signature share
### Communication round
The signature share will be sent to the coordinator
The coordinator will then send the Group signature
## Developer information
TODO
### Pre-commit checks
1. Run `cargo make all`

76
trusted-dealer/README.md Normal file
View File

@ -0,0 +1,76 @@
# Frost Trusted Dealer Demo
[Overview of demos](https://github.com/ZcashFoundation/frost-zcash-demo/blob/main/README.md)
## Status ⚠
The Trusted Dealer demo is a WIP.
## Usage
NOTE: This is for demo purposes only and should not be used in production.
You will need to have [Rust and Cargo](https://doc.rust-lang.org/cargo/getting-started/installation.html) installed.
To run:
1. Clone the repo. Run `git clone https://github.com/ZcashFoundation/frost-zcash-demo.git`
2. Run `cargo install`
3. Run `cargo run --bin trusted-dealer`
On startup, the Trusted Dealer demo will prompt for:
1. Minimum number of signers (>= 2) i.e. The threshold number of signers for the secret sharing scheme.
2. Maximum number of signers i.e. the number of shares to generate
```
> cargo run
Finished dev [unoptimized + debuginfo] target(s) in 0.05s
Running 'target/debug/frost-trusted-dealer-demo
The minimum number of signers: (2 or more)
2
The maximum number of signers: (must be greater than minimum number of signers)
5
```
The dealer CLI will then use that data to generate:
1. The group public key
2. A commitment to the secret
3. Each signer's public key
4. Each signer's secret share
5. An identifier for each signer
In a "real world" scenario, the secret share should be delivered securely to each participant. For the purposes of the Trusted Dealer demo only, the above data will be output to the terminal.
In the next round, all signers will receive the data but only the individual signers will receive their personal secret share.
## Using the output
To generate a key package the participant requires:
* The signer's identifier
* The signer's secret share
* The signer's public key
* The public signing key that represents the entire group
The commitment is used to verify the signer's secret share and to generate the group commitment.
The dealer should use a secure broadcast channel to ensure each participant has a consistent view of this commitment and each participant must [verify the commitments](https://github.com/ZcashFoundation/frost/blob/4055cb9439df2814800c678c8da1760a0f86dc10/frost-core/src/frost/keys.rs#L297).
The trusted dealer MUST delete the secret_key (used during calculation) and secret_share upon completion.
Use of this method for key generation requires a mutually authenticated secure channel between the dealer and participants to send secret key shares, wherein the channel provides confidentiality and integrity. Mutually authenticated TLS is one possible deployment option.
NOTE: A signer is a participant that generates a signing share which is aggregated with the signing shares of other signers to obtain the final group signature.
## Developer information
### Pre-commit checks
1. Run `cargo make all`
### Coverage
Test coverage checks are performed in the pipeline. This is configured here: `.github/workflows/coverage.yaml`
To run these locally:
1. Install coverage tool by running `cargo install cargo-llvm-cov`
2. Run `cargo cov` (you may be asked if you want to install `llvm-tools-preview`, if so type `Y`)