Frosty

FROST threshold signatures for ed25519.

Overview

FROST enables threshold signatures where a minimum number of participants (T) from a larger group (N) can collaboratively sign messages without any single party ever possessing the complete private key.

This library supports multiple key generation methods:

• DKG (Distributed Key Generation): Participants collaboratively generate key shares without any trusted party
• Trusted Dealer (planned): A single trusted party generates and distributes shares

Prerequisites

Before using this library, participants must coordinate to establish:

• Unique participant IDs (non-zero u16 values, 1-65535)
• Threshold parameters (max_signers, min_signers)

This coordination happens outside the library and is application-specific. Common approaches:

• Centralized coordinator assigns sequential IDs
• Deterministic ordering based on public keys
• Smart contract or blockchain registration
• Manual out-of-band agreement

Installation

[dependencies]
frosty = "0.1"
rand = "0.8"

Usage

Key Generation with DKG

Each participant executes three rounds independently, exchanging packages with others at each step:

use frosty::{keygen::Dkg, *};
use rand::rngs::OsRng;
use std::collections::BTreeMap;

// After ID coordination, each participant creates their DKG instance
let mut alice = Dkg::new(1, 3, 2)?; // participant 1, max 3, min 2

// Commit: Generate and broadcast commitment
let alice_commitment = alice.commit(&mut OsRng)?;
// ... broadcast to other participants ...

// Share: Process received commitments
let alice_shares = alice.share(&received_commitments)?;
// ... send targeted shares to recipients ...

// Complete: Generate key share
let (key_share, pubkey) = alice.complete(&received_commitments, &received_shares)?;

Threshold Signing

FROST signing uses a two-phase protocol for optimal performance:

Phase 1: Preprocessing (offline/async)

// Generate signing nonces (can be done before knowing the message)
let alice_nonces = preprocess(&alice_key_share, &mut OsRng)?;
let bob_nonces = preprocess(&bob_key_share, &mut OsRng)?;

// Exchange commitments with other participants
// (In a real system, send these over the network)

Phase 2: Signing (online, single round)

let message = b"Hello, FROST!";
let signature = sign(
    message,
    &[alice_nonces, bob_nonces],
    &[alice_key_share, bob_key_share],
    &pubkey,
)?;

// Verify using standard ed25519
let ed25519_key = pubkey.to_ed25519_key()?;
verify_signature(&signature, message, &ed25519_key)?;

Convenience API (combines both phases):

let message = b"Hello, FROST!";
let signature = threshold_sign(message, &key_shares, &pubkey, &mut OsRng)?;

Example

See examples/simple.rs for a complete working example:

cargo run --example simple

API

Key Generation (keygen module):

• Dkg - Coordinates DKG protocol for one participant
• CommitmentPackage, SharePackage - DKG coordination messages

Core Types:

• KeyShare - Secret key share (keep secure)
• PublicKeyPackage - Shared public key
• Signature - Threshold signature
• ParticipantId - Participant identifier

Signing Types:

• SigningNonces - Nonces generated during preprocessing (use exactly once)

Signing Functions:

• preprocess() - Generate signing nonces (offline/async phase)
• sign() - Create signature using nonces (online phase)
• threshold_sign() - Convenience API (combines preprocess + sign)
• verify_signature() - Verify using ed25519

Security

• Use OsRng or another cryptographically secure RNG
• Never reuse signing nonces - reusing nonces can leak the secret key share
• Never reuse key shares across different DKG ceremonies
• Keep key shares secure - they contain secret material
• Authenticate participants before DKG in production
• Ensure secure communication channels for package exchange

Testing

cargo test -p frosty

Features

• serde - Enable serialization support for all types

License

MIT OR Apache-2.0

Credits

Built on FROST by the Zcash Foundation.