RFC 9591

FROST Threshold Signatures

Flexible Round-Optimized Schnorr Threshold Signatures - An interactive visualization of how multiple signers collaborate to create a single, unforgeable signature.

🧊 What is FROST?

FROST (Flexible Round-Optimized Schnorr Threshold) is a threshold signature scheme where t-of-n participants must cooperate to create a valid signature. The resulting signature is indistinguishable from a regular Schnorr signature.

🔒

Threshold Security

No single party holds the complete private key. At least t participants must collaborate, preventing any individual from signing alone.

🔄

Two-Round Protocol

Efficient signing in just two communication rounds: commitment exchange followed by signature share generation.

✅

Standard Verification

The final signature is a standard Schnorr signature, verifiable with any compatible Schnorr verification implementation.

🎯

Existential Unforgeability

Provides EUF-CMA security: even with t-1 corrupted participants, adversaries cannot forge signatures.

Threshold Configuration

3 of 5

Adjust the threshold: At least 3 signers must participate to create a valid signature.

👥 Participants & Roles

FROST involves two types of participants: Signers who hold secret key shares and contribute to signature generation, and a Coordinator who orchestrates the protocol and aggregates the final signature.

S1
Signer 1
Participant
Key Share sk_1
Public Key PK_1
S2
Signer 2
Participant
Key Share sk_2
Public Key PK_2
S3
Signer 3
Participant
Key Share sk_3
Public Key PK_3
🎯

Coordinator

Orchestrates the protocol, collects commitments and shares, aggregates the final signature.

💡 Key Distribution

Each signer receives their secret key share through Shamir's Secret Sharing during the Distributed Key Generation (DKG) ceremony. The complete private key is never reconstructed - only signature shares are combined.

1️⃣ Round 1: Commitment Phase

In the first round, each signer generates cryptographic nonces and sends commitments to the Coordinator. These commitments ensure the protocol's security by binding signers to their random values before seeing the message.

🎲 Nonce Generation

Each signer generates two random nonces using secure randomness combined with their secret key:

hiding_nonce (d)
binding_nonce (e)
Generate

📤 Commitment

Compute public commitments and send to Coordinator:

D = d * G
E = e * G
nonce_generate(sk) → (d, D, e, E)

where d, e are secret scalars and D, E are the corresponding elliptic curve points (commitments)

⚠️ Security Note

Nonces must never be reused. The hiding and binding nonces are deleted immediately after generating the signature share. Reusing nonces can lead to complete key recovery by an attacker.

2️⃣ Round 2: Signature Generation

The Coordinator broadcasts the message and all commitments to participating signers. Each signer then computes their signature share using their secret key share and nonces.

📝

1. Receive Message

Coordinator sends the message m and the complete commitment list [(i, D_i, E_i)] to all signers.

🔢

2. Compute Binding Factor

Each signer computes binding factors from the commitment list to prevent manipulation attacks.

➕

3. Group Commitment

Calculate the combined group commitment R from all individual commitments.

✍️

4. Signature Share

Generate signature share z_i using Lagrange interpolation and the challenge.

ρ_i = H(i, m, commitment_list) // binding factor
R = ∑ (D_i + ρ_i * E_i) // group commitment
c = H(R, PK, m) // challenge
z_i = d_i + (e_i * ρ_i) + (λ_i * sk_i * c) // signature share

🧮 Lagrange Coefficient

The λ_i value is the Lagrange interpolation coefficient, allowing signature shares to be combined correctly. It's computed as:
λ_i = ∏(j / (j - i)) for all j ≠ i in the participant set.

🏁 Signature Aggregation

The Coordinator collects all signature shares and combines them into the final Schnorr signature. Before releasing the signature, verification should be performed.

z1
z2
z3

Signature Shares

→
∑

Aggregation

→
(R, z)

Final Signature

z = ∑ z_i // sum all signature shares
σ = (R, z) // final Schnorr signature

✅ Verification

The final signature (R, z) is verified using standard Schnorr verification:
z * G == R + c * PK
where c = H(R, PK, m) is the challenge.

🎮 Interactive Demo

Watch the FROST protocol in action. Click "Start Signing" to see how signers exchange commitments and generate signature shares.

0 Idle
1 Commitments
2 Signing
3 Aggregate
✓ Complete
🎯
Coordinator
Aggregator
S1
Signer 1
Participant
Status Idle
Nonces -
S2
Signer 2
Participant
Status Idle
Nonces -
S3
Signer 3
Participant
Status Idle
Nonces -
[00:00:00] INIT FROST demo initialized. Click "Start Signing" to begin.

📋 Current Step

The demo is ready. Three signers will collaborate with the Coordinator to produce a threshold signature. Watch as commitments and signature shares flow through the network.

🔐 Ciphersuites

RFC 9591 defines five ciphersuites for different elliptic curves and hash functions. Choose based on your compatibility requirements and security preferences.

Ciphersuite Curve Hash Use Case Notes
FROST(ristretto255, SHA-512) ristretto255 SHA-512 General purpose Recommended
FROST(Ed25519, SHA-512) Ed25519 SHA-512 EdDSA compatibility EdDSA
FROST(Ed448, SHAKE256) Ed448 SHAKE256 EdDSA compatibility EdDSA
FROST(P-256, SHA-256) P-256 (secp256r1) SHA-256 NIST compliance ECDSA compatible curve
FROST(secp256k1, SHA-256) secp256k1 SHA-256 Bitcoin/Ethereum Blockchain compatible

Domain Separation

Each ciphersuite uses domain-separated hash functions (H1-H5) to prevent cross-protocol attacks and ensure cryptographic isolation.

Serialization

Group elements and scalars are serialized in a ciphersuite-specific manner, ensuring interoperability within the same ciphersuite.