Trusted Dealer Key Generation

The diagram below shows the trusted dealer key generation process. Dashed lines represent data being sent through an authenticated and confidential communication channel.

Diagram of Trusted Dealer Key Generation, illustrating what is explained in the text

To generate the key shares, the dealer calls generate_with_dealer(). It returns a BTreeMap mapping the (automatically generated) Identifiers to their respective SecretShares, and a PublicKeyPackage which contains the VerifyingShare for each participant and the group public key (VerifyingKey).

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(
    &mut rng,

Each SecretShare must then be sent via an authenticated and confidential channel for each 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 KeyPackage::try_from():

    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.


You can specify which identifiers to use by using IdentifierList::Custom. Refer to the DKG section for an example on how to create identifiers.


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.


The 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 SecretShares 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 VerifiableSecretSharingCommitment values from their SecretShares (either by some manual process, or by using a broadcast channel) to make sure they are all equal.