THRESHOLD SIGNATURES
How FROST distributes a key without distributing the verifier’s work.
A threshold signature lets a subset of participants act for one public key. No participant holds the complete private key, yet the result can look like an ordinary Schnorr signature to every external verifier.
FROST makes that result efficient in two signing rounds. Its elegance is visible at the verification boundary. Its difficulty appears in the ceremony around that boundary: creating shares, choosing participants, protecting one-time nonces, handling failures and deciding what threshold authority means operationally.
One public key, many private shares
In a t-of-n arrangement, each participant holds a share associated with a unique identifier. Any authorized set of at least t participants can cooperate to produce a signature under the group public key.
An external verifier does not receive t signatures or a list of signers. It receives one signature and verifies it using the ordinary group public key and the relevant Schnorr or EdDSA verification procedure.
This differs from multisignature policies in which several independent public keys and signatures remain visible. Threshold signing distributes control while preserving a single-key interface.
The standard begins after key generation
RFC 9591 specifies the signing protocol. Distributed key generation is outside its main scope, although an appendix describes generation with a trusted dealer.
That boundary is important. A deployment still has to decide how shares are created, delivered, validated, backed up and associated with participant identities. A trusted dealer temporarily knows the complete secret. A distributed key-generation protocol avoids that concentration but introduces its own rounds, complaints and failure handling.
The assurance of a FROST deployment cannot exceed the assurance of its share-generation ceremony.
Two rounds with one-time commitments
In the first round, each selected participant creates nonce commitments. In the second, participants receive the complete signing package and produce signature shares. A coordinator verifies and combines the valid shares.
The commitments bind each participant to fresh secret nonces before the aggregate challenge is known. Binding factors connect those commitments to the message and to the exact participant set.
The two-round structure reduces communication while defending against attacks that affected simpler threshold Schnorr constructions. It does not make the rounds interchangeable or optional.
A signing nonce is a one-time asset
A participant’s secret nonce pair must never be reused. Reuse across distinct signing packages can reveal that participant’s long-lived key share.
Precomputation can improve latency, but it turns nonce storage into an inventory of highly sensitive one-time assets. Every stored pair needs an atomic state transition from available to consumed. A crash after commitment publication must not return the pair to the pool.
Backups and replicas make this harder. Restoring a snapshot can revive already consumed nonces. Two active replicas can allocate the same record. The problem has the same operational shape as nonce uniqueness in encryption, with the additional consequence that one participant’s share can be exposed.
The participant set enters the signature
Threshold coefficients depend on participant identifiers. The signing package also includes the message and commitments for the chosen set.
Each signer must independently verify that its own commitment appears exactly once, that all identifiers are valid and distinct, and that the message is the one it intends to authorize. Trusting a coordinator to summarize these facts weakens the protocol boundary.
A coordinator can simplify communication, but it should not acquire the power to change the statement invisibly.
The coordinator need not hold a share
The coordinator collects commitments, constructs the signing package, receives signature shares and aggregates them. It may be one of the participants or an untrusted service.
Cryptographic verification can detect invalid shares, but an adversarial coordinator can still delay, omit or selectively request signatures. It can also learn operational metadata about which participants are active and which messages they approve.
Availability, privacy and coercion therefore remain system properties. A protocol that prevents forgery does not guarantee fair scheduling or conceal the signer set from its coordinator.
Threshold is not the approval policy
A threshold expresses how many valid shares are sufficient. It does not express why those participants are authorized.
A 2-of-3 group might represent two officers, one service and one disaster-recovery function. If the service can silently choose whichever two are easiest to reach, the operational policy may differ from the intended governance.
Some deployments need role constraints in addition to a numeric threshold, such as one operational participant and one independent approver. That logic belongs outside base FROST and must be bound to the signing request and audit record.
Failure is part of the normal protocol
Participants can be offline, return malformed shares, lose state after round one or refuse a particular message. The coordinator may need to abandon one signing set and start again with another.
Restarting is not a continuation. It creates a new signing package and requires fresh nonces from every selected participant. Reusing commitments from an abandoned attempt requires exact support from the construction and implementation; casual reuse is unsafe.
Operational design should define timeouts, participant substitution, blame evidence and the point at which a request receives a new transaction identifier.
Hardware integration changes the API
Many secure modules expose complete signing operations but not the scalar arithmetic required for a threshold signature share. A conventional HSM may protect an Ed25519 private key while being unable to hold a FROST share under the same policy model.
Integration may require programmable secure hardware, a custom applet or a software boundary protected by the host platform. Nonce generation, share multiplication and zeroization then need to occur inside that boundary.
The fact that the final signature is compatible with Ed25519 does not imply that existing Ed25519 hardware can participate in its creation.
Share refresh and membership are separate protocols
Long-lived groups need to replace failed participants, remove compromised ones and refresh shares without changing the public key. These operations are not supplied by the base signing protocol.
Changing membership can require a resharing or proactive secret-sharing construction. Its authentication, complaint process and continuity rules deserve the same scrutiny as initial key generation.
If a removed participant retains an old share, the system must know which other historical shares could combine with it. A current threshold statement is not enough to describe cumulative compromise over time.
Audit without reconstructing the key
A useful audit record identifies the request, message digest, policy decision, selected participant set, commitments, verified shares and final signature. Secret nonces and shares must never enter the log.
The record should allow an investigator to distinguish a failed attempt from a completed signature and to determine which devices contributed. External verifiers will not learn that from the final signature alone.
This is a feature of threshold signing, but it places more responsibility on internal evidence.
Ordinary output, extraordinary state
FROST compresses distributed authority into an ordinary signature. That is its architectural strength.
The simplicity at the verifier is paid for by strict state inside the signer group. Shares need provenance. Nonces are consumed once. Participants must see the same package. Membership changes require their own protocol. Hardware must support more than a standard signing call.
The signature is ordinary. The ceremony that makes it legitimate is not.
