One signing key can sit in several hands at once, so that two of three holders together can sign and any single holder alone cannot. This page walks one 2-of-3 ceremony end to end twice: once with a trusted dealer who briefly holds the whole key, and once with distributed key generation, where the whole key is never assembled anywhere. It closes with the failure stories bad randomness keeps writing, and with where threshold ideas touch this estate. Every ceremony value on this page is a recorded transcript: it was generated offline by a pinned cryptography library before this page was written, and the page itself runs no cryptography.
Two steps: what a verifier actually sees when a signature arrives, and how one key can be split so that no single holder alone can use it.
One ordinary signing key answers three questions at once: who approves, where the key lives, and what happens when that one place burns. Threshold signing changes the middle answer: the same single key, in effect, lives in several hands, and a quorum of those hands must agree before anything is signed.
A multisignature scheme keeps separate keys and produces separate signatures, so the policy is visible on the wire: a verifier counts three signatures and learns that three parties were involved. A threshold scheme produces one signature under one public key, and the quorum policy stays private to the holders. That privacy is a design choice with a cost: the ceremony that splits the key has to be run well, which is the subject of the next three steps.
Why does one signature from three holders look identical, to any outside verifier, to one signature from a single key?
Three steps: the trusted-dealer track, where one party briefly sees everything; distributed key generation, where no party ever does; and the signing step, where two holders produce one signature. Every value in these steps was recorded offline and is quoted, truncated, from that recording.
The oldest way to cut a key: a dealer generates the whole key, cuts it into shares, hands one share to each holder, and deletes the key. It works, and it has a structural weakness: for a moment, one machine held everything, and the ceremony is only as trustworthy as that machine and its randomness.
The recorded dealer run drew the whole key first, then cut it into the three shares shown, each share paired with a public verifying share so holder 1 can check what it received. RFC 9591, the FROST specification, sketches exactly this shape in its Appendix C, because key generation is out of that document's scope. The whole-key value above is real and is published deliberately: this ceremony was recorded for teaching, the key was born in a sealed offline run, and showing what the dealer saw is the point. That exposure is why the next step exists.
What exactly does the dealer see in the trusted-dealer setup, at which moment, and what must be trusted about that machine?
Distributed key generation removes the dealer: every holder contributes randomness, the shares are formed in public round messages, and the whole signing key exists only as a sum that is never assembled anywhere. The ceremony holds together as long as one participant is honest.
This three-round shape, with the proof of knowledge in round one, is the distributed key generation implemented in @noble/curves 2.4.0, the Zcash Foundation construction. RFC 9591 covers the FROST signing that follows; it deliberately leaves key generation out of scope, so the DKG wording here names the library's construction rather than the RFC. In the recorded run, all three holders derived byte-identical group public keys and mutually consistent verifying shares, and each share validated against the published commitments.
Walk the three DKG rounds. What is public after each round, and where does the whole signing key never exist?
Signing is RFC 9591 FROST signing, in two rounds: the participating holders publish nonce commitments, then each produces a partial signature, and an aggregation step folds the partials into one ordinary 64-byte Schnorr signature under the group public key.
The message signed in both recorded runs was the ASCII string threshold-signing-explainer recorded ceremony. The recorded transcript also includes, for completeness, the dealer run signing by holders 1 and 2. Every verification below passed in the recorded run, and the second one is the quietly important result: the aggregate is a well-formed RFC 8032 Ed25519 signature, so an ordinary verifier with no FROST code accepts it.
| Run | Key generation | Signing pair | Aggregate signature | RFC 9591 verify | Ordinary Ed25519 verify |
|---|---|---|---|---|---|
| Dealer | trusted dealer | holders 1 + 2 | 50688ca151bf4a13…82c3ed00 | PASS | PASS |
| DKG | DKG.round1/2/3 | holders 2 + 3 | a8369d73f96814e3…9bc90ea0e | PASS | PASS |
Different holder pairs signed the two runs, which is the threshold property doing its job: any two of the three can form a quorum. The nonce discipline matters as much as the shares; the randomness step of this page is where that story lands.
Which values from the recorded transcript would an external verifier need in order to check the aggregate signature, and which verifier code can it use?
Four steps: choosing holders as a design value, FROST against MuSig2, the randomness failure stories with their primary sources, and where threshold ideas touch the AINumbers estate.
A threshold is only as strong as the spread of its holders. Holder choice is a design value: pick holders by jurisdiction, by authentication type, and by whether each is a person or an organisation, so that one compromise, one legal demand, or one mistake stays below the quorum.
The three axes do different work. Jurisdiction spread keeps one court or one regulator from reaching a quorum. Authentication spread means one class of credential compromise, for example a stolen passkey, reaches at most one share. The person-or-organisation choice sets who is accountable and who is reachable in an emergency. A sound policy names its holders along all three axes before the ceremony is scheduled.
Give three holder-selection policies for a 2-of-3 set and name the failure each one survives.
Two Schnorr multi-party schemes answer different questions. FROST, specified in RFC 9591 (an Informational RFC), lets a threshold subset of n sign. MuSig2, specified in BIP 327 (a draft Bitcoin Improvement Proposal), requires all participants and exists to make several keys look like one ordinary BIP340 key.
| FROST | MuSig2 | |
|---|---|---|
| specification | RFC 9591, Informational | BIP 327, draft |
| who must take part | any t of n holders (this page: 2 of 3) | all n participants |
| signing rounds | two: nonce commitments, then partial signatures | two |
| key generation | out of scope for RFC 9591; trusted dealer sketched in its Appendix C; distributed key generation per @noble/curves, the Zcash Foundation construction | built into the scheme (public-key aggregation) |
| nonce discipline | a reused nonce in any partial signature leaks that holder's share | a reused nonce leaks the private key |
For custody of one key across several holders, the threshold column is the one that matters: MuSig2 cannot express 2-of-3, because all participants must sign. MuSig2 shines where a fixed group wants the efficiency and privacy of one key. Both live or die by nonce discipline, which is the next step's subject.
Compare FROST and MuSig2 for a 2-of-3 custody policy and say which applies at all.
Threshold structures spread a key across holders, and every one of those holders still draws randomness: to generate shares, and for every single nonce at signing. The recorded failure stories below are all, at bottom, randomness stories, and each is linked to its primary source.
Between 17 September 2006 and 13 May 2008, a Debian-specific change to the OpenSSL package made its random number generator predictable, so cryptographic key material was guessable. The Debian advisory DSA 1571-1 (CVE-2008-0166) told every affected user to recreate keys: SSH keys, OpenVPN keys, DNSSEC keys, and key material for X.509 certificates and TLS sessions, and it flagged DSA signing keys as compromised outright, because DSA signs with a fresh secret random value each time. Two years of keys, one quiet packaging change.
Three public compliance cases in 2019, none of them key generation: certificate serial numbers. The Baseline Requirements ask certificate authorities for at least 64 bits of output from a cryptographically secure random number generator, and three authorities landed just under it. GoDaddy's serials carried about 63.994 bits after a 2016 change, Entrust's AffirmTrust issuers produced 63-bit serials through an EJBCA flaw, and DarkMatter's platform was configured for 64-bit serials that left about 63 bits of entropy. All three were disclosed on the Mozilla bug tracker, remediated, and the affected certificates re-issued or revoked.
The lesson for a threshold ceremony: the shares and the nonces both come from randomness, so the ceremony's health is the health of its entropy sources at every draw. The estate's Ed25519 guide covers where per-signature randomness sits in the signatures used here.
What did the Debian OpenSSL weakness and the 2019 CA serial-number findings have in common, and where does the same risk sit in a FROST ceremony?
Two statements close this page: what a threshold signer would change for this estate's verifiers, which is design only, and the k-of-n structure the estate runs today, which is a set of independent cosignatures rather than one shared key.
A FROST-Ed25519 threshold signer would produce one ordinary Ed25519 signature under one group public key. The estate's receipt verifier T568 and envelope verifier T624 already verify ordinary Ed25519 signatures, so both would accept such a signature with no code change on their side. The threshold signer itself is a design on this page: the estate runs no threshold signing today, and this page runs no cryptography at all.
The estate's real k-of-n today is the Sigsum witness set behind anchor.ainumbers.co: twelve pinned witnesses, each an independent key on its own device, cosigning every transparency-log checkpoint, with verification requiring a quorum of those independent cosignatures. That is k-of-n agreement among separate signatures, shown here as exactly that, rather than one threshold key. Measured 23 October 2026 from anchor-suite/public/lib/sigsum.mjs (witness list last changed 20 August 2026).
The distinction matters for anyone tempted to read a witness quorum as threshold signing. Each Sigsum witness signs with its own key, visibly, and the policy counts the cosignatures; a FROST quorum produces one signature and keeps the policy private. Both are k-of-n trust, and they are different mechanisms.
Which estate verifier would accept a FROST-Ed25519 aggregate signature unchanged, and what does the estate use today instead of threshold keys?
55279c71b0201d6c0e58d0206d15825359e02a3932f326ba7b7909ac2d334aa9; exact dependency @noble/hashes 2.4.0, tarball sha256 e1946149b780017b2564fcc092cb01c04e1d7f20627d0296c17da8868f4436dc. The generator lives outside this repository and this page runs no cryptography; hex values are displayed truncated, with the full transcript downloadable below.