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.
To generate the key shares, the dealer calls
generate_with_dealer()
.
It returns a BTreeMap
mapping the (automatically generated) Identifier
s to
their respective SecretShare
s, 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(
max_signers,
min_signers,
frost::keys::IdentifierList::Default,
&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
SecretShare
s 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 KeyPackage
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 SecretShare
s
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 SecretShare
s (either by some manual process, or
by using a broadcast channel)
to make sure they are all equal.