lit-frost

A Rust implementation of the FROST (Flexible Round-Optimized Schnorr Threshold) signature scheme, providing threshold signatures across multiple elliptic curve ciphersuites.

Overview

FROST is a threshold signature scheme that allows a group of n signers to produce a single signature on a message, where the signature is valid if and only if at least t (threshold) of the signers have participated. This implementation is based on the FROST paper and the IETF FROST RFC.

This crate provides a unified interface across multiple elliptic curve ciphersuites, making it easy to use FROST with your preferred cryptographic curve.

Supported Signature Schemes

Installation

Add this to your Cargo.toml:

[dependencies]
lit-frost = "0.4"

Features

• default - Full signing and verification capabilities
• verify_only - Signature verification only (excludes signing functionality for reduced binary size)

How FROST Works

FROST requires 2 rounds to complete a signature:

Round 1: Commitment Generation

Each signer generates signing nonces and commitments. These can be:

• Pre-generated in batches using Scheme::pregenerate_signing_nonces() for efficiency
• Generated on-demand using Scheme::signing_round1()

Round 2: Signature Share Generation

Each signer uses their secret share, nonces, and the collected commitments to generate a signature share using Scheme::signing_round2().

Aggregation

The signature shares are combined into a single threshold signature using Scheme::aggregate(). The resulting signature can be verified by anyone using Scheme::verify().

Usage Example

use lit_frost::{Scheme, KeyPackage, Identifier};
use std::num::NonZeroU16;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let scheme = Scheme::Ed25519Sha512;
    let mut rng = rand::rngs::OsRng;
    
    // Generate keys with a trusted dealer (for demonstration)
    // In production, use distributed key generation (DKG)
    let threshold = 2u16;
    let num_signers = 3u16;
    let (secret_shares, verifying_key) = scheme
        .generate_with_trusted_dealer(threshold, num_signers, &mut rng)?;
    
    // Each signer performs Round 1
    let mut signing_commitments = Vec::new();
    let mut signing_nonces = Vec::new();
    
    for (id, secret_share) in &secret_shares {
        let (nonces, commitments) = scheme.signing_round1(secret_share, &mut rng)?;
        signing_nonces.push((id.clone(), nonces, secret_share.clone()));
        signing_commitments.push((id.clone(), commitments));
    }
    
    // Each signer performs Round 2
    let message = b"Hello, FROST!";
    let mut signature_shares = Vec::new();
    let mut verifying_shares = Vec::new();
    
    for (id, nonces, secret_share) in signing_nonces {
        let key_package = KeyPackage {
            identifier: id.clone(),
            secret_share: secret_share.clone(),
            verifying_key: verifying_key.clone(),
            threshold: NonZeroU16::new(threshold).unwrap(),
        };
        
        let sig_share = scheme.signing_round2(
            message,
            &signing_commitments,
            &nonces,
            &key_package,
        )?;
        
        signature_shares.push((id.clone(), sig_share));
        verifying_shares.push((id.clone(), scheme.verifying_share(&secret_share)?));
    }
    
    // Aggregate signature shares
    let signature = scheme.aggregate(
        message,
        &signing_commitments,
        &signature_shares,
        &verifying_shares,
        &verifying_key,
    )?;
    
    // Verify the signature
    scheme.verify(message, &verifying_key, &signature)?;
    println!("Signature verified successfully!");
    
    Ok(())
}

Key Types

Security Considerations

• Nonce Reuse: SigningNonces must never be reused. Reusing nonces will leak the signer's long-lived secret key.
• Secret Storage: SigningShare and SigningNonces must be stored securely and zeroized when no longer needed.
• Threshold Selection: Choose an appropriate threshold t based on your security requirements. A higher threshold provides better security but requires more signers to be available.

Security Audit

This crate has been audited by Kudelski Security. The audit report is available in the audit/ directory.

Interoperability

This crate provides From and TryFrom implementations to convert between lit-frost types and types from popular cryptographic libraries including:

• k256 (secp256k1)
• p256 (NIST P-256)
• p384 (NIST P-384)
• curve25519-dalek
• ed448-goldilocks
• jubjub
• decaf377
• schnorrkel

References

• FROST Paper - Original academic paper
• IETF FROST RFC - IETF standardization draft
• ZCash FROST - ZCash Foundation's FROST resources

License

Licensed under the MIT License.