Secret Sharing and Threshold Cryptography Guide: Split Keys So No One Holds Them

Secret sharing splits a key into pieces so that any agreed number of pieces can rebuild it, while fewer reveal nothing; threshold cryptography goes further and lets those pieces sign or decrypt together without ever rebuilding the key. Both answer the same problem: a single key held by a single person, server or device is a single point of compromise and a single point of loss. They sit behind familiar controls such as HashiCorp Vault's unseal keys, HSM quorum approvals, key ceremonies and multi-party computation (MPC) wallets for digital assets. This explainer defines the terms in plain language, then gives practitioners the detail needed to choose parameters, run custodians and avoid the usual mistakes. It is for security engineers, key custodians, platform teams and anyone designing controls over high-value keys. For wallet-specific controls, see the Crypto Wallet Security Guide.

Key takeaways

• Threshold means "t of n". A secret split into n shares with threshold t can be rebuilt by any t shares; with t minus 1 shares, Shamir's scheme reveals nothing at all about the secret.
• Secret sharing protects keys at rest, not in use. With plain Shamir sharing the key is reconstructed in one place to be used, so that place becomes the target; threshold signing and decryption avoid reconstruction.
• Quorum approval is a different control. HSM "M of N" quorum and multisig wallets require several approvals, but they are policy or protocol checks, not a split of the key itself.
• Custodians are the real attack surface. Where shares are stored, who holds them, how they are delivered and how the signing interface presents what is being approved matter more than the mathematics.
• Standards are maturing. FROST threshold Schnorr signatures were published as RFC 9591 (Informational, June 2024), and NIST's Multi-Party Threshold Cryptography project issued its first call for threshold schemes (NIST IR 8214C, final 20 January 2026).

What it is

Secret sharing is a method of dividing a secret, usually a cryptographic key, into n shares and distributing them to different holders, so that only an authorised group can recover it. The best-known scheme is Shamir's Secret Sharing, published by Adi Shamir in 1979. Threshold cryptography applies the same idea to cryptographic operations: a group of parties, each holding a share of a private key, cooperates to produce a signature or decrypt a message, and the full private key never exists in one place. NIST describes threshold cryptography as applying secure multiparty computation so that trust in cryptographic operations is distributed across parties.

How it works

Shamir's Secret Sharing in plain terms

Two points define a straight line, three define a parabola, and in general t points define a polynomial of degree t minus 1. Shamir's scheme hides the secret as the constant term of a random polynomial of degree t minus 1 over a finite field, then hands each holder one point on that curve. Any t holders can interpolate the polynomial and read off the secret. Anyone with fewer than t points can fit every possible secret equally well, which is why the scheme is called information-theoretically secure: no amount of computing power helps, including a quantum computer.

Two practical consequences follow. Shares are the same size as the secret, and each share is useless on its own, so a stolen share is a reduced risk rather than a breach, as long as fewer than t are stolen. But plain Shamir has no integrity: a holder who submits a wrong share can cause a wrong secret to be rebuilt without anyone noticing, which is why verifiable schemes exist.

From sharing to threshold operations

Reconstructing a key to use it puts the whole key back in one memory space, for a moment at least. Threshold schemes avoid this. In FROST (RFC 9591), each participant holds a share of the signing key; a coordinator gathers commitments in a first round and signature shares in a second, and combines them into one Schnorr signature. The RFC states FROST takes two rounds, and that its Ed25519 and Ed448 ciphersuites produce signatures that RFC 8032 verifiers accept, so relying parties need no changes. RFC 9591 lists ciphersuites for ristretto255, Ed25519, Ed448, P-256 and secp256k1.

The security conditions are precise. RFC 9591 says security holds if shares were distributed securely and no more than the threshold minus one participants, plus the coordinator, are corrupted. Nonces must be random and never reused; the RFC links nonce reuse to full key recovery. FROST can identify participants who send invalid signature shares, but it does not provide robustness, so a participant who simply refuses to take part can block signing.

Where you meet it in practice

Vault's own documentation notes that unseal shares can be entered one at a time, in any order, from different machines, and that rekeying is done with vault operator rekey once the threshold is met. With auto unseal, Vault depends on the KMS or HSM key: if that key is permanently deleted, the cluster cannot be recovered, even from backup. The HashiCorp Vault Guide covers the wider deployment.

Why it matters

The most valuable keys in an organisation, root CA keys, HSM master keys, secrets manager root keys, code signing keys and digital asset keys, are non-human identity credentials whose compromise is catastrophic and whose loss can be permanent. Splitting them addresses both risks at once: no single insider, stolen laptop or compromised server holds enough to act, and losing one custodian does not lose the key. It also gives auditors a clean separation of duties story, mapped to controls such as NIST SP 800-53 AC-5 Separation of Duties and SC-12 Cryptographic Key Establishment and Management.

Choosing parameters

• Set t for compromise, n minus t for loss: t is how many custodians an attacker must compromise; n minus t is how many can be lost or unavailable before the key is gone. 3 of 5 tolerates two losses and requires three compromises.
• Spread shares across failure domains: different people, teams, sites and, for digital shares, different clouds or HSMs. Five shares in one safe are one share.
• Avoid t equals n: any single loss destroys the key.
• Avoid t of 1: it is replication, not sharing.
• Small organisations: 2 of 3 with named custodians and a sealed offline share is often the realistic minimum; large organisations typically use 3 of 5 or more with geographic spread.

Running custodians safely

1. Generate in a controlled ceremony: scripted, witnessed and recorded, on a clean or air-gapped system. The Cryptographic Key Ceremony Template provides a structure.
2. Encrypt shares to custodians: Vault's operator init can encrypt each share to a custodian's PGP key with -pgp-keys, so no one sees shares in clear at delivery. RFC 9591 likewise requires shares to travel over mutually authenticated, confidential channels.
3. Verify shares on receipt: with verifiable schemes each holder checks their share against the commitments and aborts if it fails.
4. Record holders, not values: keep a register of which custodian holds which share, where, and since when.
5. Test recovery on a schedule: rehearse reconstruction or threshold signing at least annually with real custodians; an untested scheme is a hope.
6. Rekey on custodian change: when a custodian leaves or a share may be exposed, rekey so the old share is worthless.

What to monitor

• Use events: every unseal, generate-root, rekey, quorum approval and threshold signing session, with who took part.
• Metrics: days since last recovery rehearsal; custodians with a current, verified share out of n; time from custodian departure to rekey; failed or aborted threshold sessions; unexpected unseal events outside change windows.

Common misconceptions

• "Multisig and MPC are the same thing." Multisig uses several independent keys and visible policy, usually on-chain; MPC or threshold wallets use shares of one key and produce a single ordinary signature. They have different failure modes, covered in the Multisig Treasury Operations Guide.
• "A threshold makes approvals safe." Every approver can be shown a falsified transaction. In the Bybit Hack 2025, the signatures were genuine but malicious code in the wallet's web interface altered what was signed; the root cause was a supplier developer's hijacked AWS session tokens, not the cryptography. Verify transaction content independently of the signing interface.
• "Shamir protects the key while it is used." Plain Shamir rebuilds the key in one place. If the key must stay distributed during use, you need threshold operations.
• "HSM quorum splits the key." Quorum authentication requires several HSM users to approve an operation; the key itself remains whole inside the HSM.
• "Vault recovery keys can unseal Vault." With auto unseal, recovery keys cannot decrypt the root key, so they cannot unseal Vault if the KMS or HSM is lost.
• "Threshold signatures are quantum-safe." Shamir sharing itself is information-theoretic, but RFC 9591 states FROST is not post-quantum secure, because the underlying signature schemes are not.

Practitioner checklist

• Decide whether you need key splitting at rest (Shamir) or key use without reassembly (threshold operations), and record why.
• Set the threshold and share count so that losing one custodian does not lock you out and no single custodian can act alone.
• Generate and distribute shares in a witnessed key ceremony, and log who holds each share.
• Show every approver an independent view of what they are approving, so a falsified signing interface cannot win a quorum.
• Test recovery on a schedule, including the loss of the KMS or HSM behind auto unseal.
• Rotate or reshare after any custodian leaves or any share is suspected exposed.

Related concepts

Standards and references

• IRTF: RFC 9591 The Flexible Round-Optimized Schnorr Threshold (FROST) Protocol for Two-Round Schnorr Signatures
• NIST: Multi-Party Threshold Cryptography project
• HashiCorp: Vault seal and unseal concepts
• HashiCorp: vault operator init command
• AWS: CloudHSM quorum authentication
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls (AC-5, SC-12)

Related NHI Mgmt Group resources: Crypto Wallet Security Guide · HashiCorp Vault Guide · Cryptographic Key Ceremony Template · Cryptographic Key Management Guide