Summary
- RFC 9591 lets a threshold subset contribute shares that aggregate into one Schnorr signature verifiable under a group public key. The output contains
Randz, not the participant list, individual shares or an approval record. - A defensible deployment must preserve a separate session transcript: who was eligible, who was selected, which authenticated endpoints supplied commitments and shares, what message each signer validated, and which policy authorised release.
The proof that became smaller than the decision
Suppose a five-member control group uses a three-of-five threshold. Three members participate in a signing run and the resulting signature verifies. The verifier can establish that the message and group public key satisfy the Schnorr verification relation. It cannot open the signature and discover whether members one, three and five took part, whether a coordinator substituted a different eligible trio, or whether those people approved a payment, a software release or merely an opaque digest.
That is not a flaw in FROST. It is the property that makes a threshold signature useful to systems expecting a conventional signature. RFC 9591 says some FROST suites produce signatures compatible with Ed25519 or Ed448 verification, and its ciphersuite verification instructions are equivalent to those for a single participant. The wire object can remain compact while custody of the secret is distributed.
The compression creates an evidence boundary. A valid group signature is a strong cryptographic fact about the group key and signed bytes. “These named officers approved this business act” is a different statement. If an organisation wants both, it must retain both.
The participant set is chosen outside the primitive
FROST begins with a configured population, a minimum threshold, distinct participant identifiers, secret key shares and public verification shares. The group secret is never required in one place during ordinary signing. In a run with a coordinator, however, the coordinator determines which participants will take part, sends and receives the round messages, aggregates their shares and publishes the signature.
RFC 9591 explicitly says the coordinator and signer set are chosen externally to the protocol. It also permits a coordinator-free arrangement in which every participant communicates with every other participant. Removing the role does not remove the evidence problem. Someone or some application still determines the eligible population, the requested subset, the message and the rule under which a signature may be released.
A scalar participant identifier is useful inside the mathematics. It is not automatically a human identity, employment role, corporate power of attorney or current entitlement. Those bindings can change while the group key remains the same. The roster system therefore needs its own version, effective time, issuer, revocation history and mapping from cryptographic share to accountable principal.
Two rounds create the transcript the final signature discards
In round one, each selected participant creates two fresh secret nonces and publishes their corresponding commitments. In round two, the coordinator supplies the message and the complete ordered commitment list. The signer computes binding factors from the group public key, the message, the commitment list and its participant identifier, then returns one signature share.
The list matters. It binds the share to this message and this signing set, protecting against attacks on earlier threshold Schnorr constructions. The nonces matter too. They are secret, single-use state. RFC 9591 requires them never to be reused and requires their deletion after the signing operation. Reuse can enable complete recovery of a participant's key share.
Aggregation deliberately removes the detail. The coordinator adds the shares and releases a canonical (R, z) signature. That object does not carry the commitment list, the participant identifiers or the shares. Anyone who needs later attribution must preserve an authenticated transcript before that compression becomes irreversible.
RFC 9591 makes the importance of this continuity unusually visible. It declines to recommend an optimization that reduces scalar multiplications because the optimization loses the guarantee that the participants beginning round one are the participants producing the round-two result. Faster mathematics is not free when the missing property is exactly the one an auditor may later need.
Valid shares are not approvals
The coordinator can verify an individual share against the participant's public verification share, its commitments, the full participant list, the message and the group public key. If the aggregate fails, checking shares can identify a participant that submitted an invalid one. That identification depends on an authenticated channel; otherwise the protocol can detect a bad share without reliably naming its source.
Even a valid share establishes only that the holder of a corresponding key share participated in the cryptographic calculation. RFC 9591 leaves message policy to the application. It recommends validation so participants do not become signing oracles for arbitrary inputs. A payment system may require transaction syntax and stakeholder intent checks. A threshold TLS signer may require the raw handshake messages rather than trusting a supplied transcript hash.
This is the decisive separation. Parsing the message is not approving it. Approving it is not proving the approver's current role. A correct share is not evidence that the local policy engine saw the same business object the relying system later executed. The signature record needs a message fingerprint and canonicalization rule; the approval record needs the interpreted object, policy version, decision and principal.
Failure attribution is narrower than success attribution
FROST provides identifiable abort for an invalid share when the necessary authenticated transcript exists. It does not provide robustness: one participant can deny service by refusing to participate or contributing malformed data. The protocol does not itself identify a silent non-participant, and it leaves the response to misbehavior outside scope. ROAST is cited as a wrapper for robustness, not as a property silently inherited by FROST.
This asymmetry matters for incident reports. “The run aborted because participant four submitted an invalid share” can be supported by a verified share failure and authenticated source. “Participant four refused the approval” needs a different observation: a request was delivered, the response deadline expired and no valid response arrived. Neither statement proves motive, compromise or malicious intent.
Success also has limits. The final signature verifies only if the aggregate is valid, but the verifier cannot infer the successful subset from the output. The application must decide how long to retain the session evidence, who can inspect it and how to protect it from alteration without exposing secret nonces or shares.
Publication is not deployment
RFC 9591 is an IRTF Informational document representing CFRG consensus. It is not an IETF standard and explicitly says research results may not be suitable for deployment. Test vectors, supported ciphersuites and a library's successful self-test establish useful facts; they do not prove that a production roster, authenticated channel, one-time nonce store, policy engine or audit archive is operating correctly.
Running-code evidence must therefore be staged. Record the exact implementation and ciphersuite. Test malformed elements and shares. Prove nonce state cannot be rolled back or replayed. Reconcile the eligible roster against the public-share registry. Exercise aborted and silent-participant cases. Then observe a complete run and independently verify both the aggregate signature and the retained attribution record.
Heng Lu's distinction between reality and symbolic layers is sharp here. The valid signature is executable cryptographic reality. Calling it “board approval”, “committee consent” or “institutional authorization” adds a governance meaning the primitive does not contain. That meaning can be legitimate, but only through a separate mandate and evidence chain.
Sources
- RFC 9591 — The FROST Protocol
- RFC Editor information record for RFC 9591
- IETF Datatracker record for RFC 9591
- RFC 8032 — Edwards-Curve Digital Signature Algorithm
- RFC 9496 — The ristretto255 and decaf448 Groups
- RFC 4086 — Randomness Requirements for Security
- FROST: Flexible Round-Optimized Schnorr Threshold Signatures
- ROAST: Robust Asynchronous Schnorr Threshold Signatures
- Lu Heng — Running-Code Primacy
- Lu Heng — Minimum Initial Specification and Localized Future Decision
- Lu Heng — Reality Layers and Symbolic Power
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance

