The diagram below shows the trusted dealer key generation process. Dashed lines represent data being sent through an authenticated and confidential communication channel.
To generate the key shares, the dealer calls
It returns a
BTreeMap mapping the (automatically generated)
SecretShares, and a
PublicKeyPackage which contains the
VerifyingShare for each participant and the group public key (
use frost_ristretto255 as frost; use rand::thread_rng; use std::collections::BTreeMap; let mut rng = thread_rng(); let max_signers = 5; let min_signers = 3; let (shares, pubkey_package) = frost::keys::generate_with_dealer( max_signers, min_signers, frost::keys::IdentifierList::Default, &mut rng, )?;
SecretShare must then be sent via an authenticated and
participant, who must verify the package to obtain a
KeyPackage which contains
their signing share, verifying share and group verifying key. This is done with
let key_package = frost::keys::KeyPackage::try_from(secret_share)?;
Check the crate documentation for a full working example; keep in mind it's an artificial one since everything runs in the same program.
Which authenticated and confidential channel to use is up to the application. Some examples:
- Manually require the dealer to sent the
SecretShares to the partipants using some secure messenger such as Signal;
- Use a TLS connection, authenticating the server with a certificate and the client with some user/password or another suitable authentication mechanism;
Refer to the Terminology page for more details.
Failure of using a confidential channel may lead to the shares being stolen and possibly allowing signature forgeries if a threshold number of them are stolen.
Failure of using an authenticated channel may lead to shares being sent to the wrong person, possibly allowing unintended parties to generate signatures.
SecretPackage contents must be stored securely. For example:
- Make sure other users in the system can't read it;
- If possible, use the OS secure storage such that the package contents can only be opened with the user's password or biometrics.
The participants may wish to not fully trust the dealer. While the dealer
has access to the original secret and can forge signatures
by simply using the secret to sign (and this can't be
possibly avoided with this method; use Distributed Key Generation
if that's an issue), the dealer could also tamper with the
in a way that the participants will never be able to generate a valid
signature in the future (denial of service). Participants can detect
such tampering by comparing the
values from their
SecretShares (either by some manual process, or
by using a broadcast channel)
to make sure they are all equal.