Choosing your m-of-n threshold

Stefan Thomas has 7,002 Bitcoin sitting on an IronKey he can no longer open. He used eight of the device's ten password attempts; the remaining two are likely the only ones he will ever get, because IronKey wipes the drive on the eleventh. At the time of writing the wallet is worth roughly $700M.

The story is widely told as a parable about backups. Write your password down. Don't lose the paper. The deeper lesson, which is harder to act on, is structural: a single point of failure is a design choice. The thing that replaces it is not "more backups". It is a threshold scheme, and the moment you adopt one you face two specific questions: how many shares should there be, and how many should be needed to recover.

Threshold cryptography splits a secret into n shares such that any m of them reconstruct it, and any fewer reveal nothing at all. Lose a share and you still recover. Have a share stolen and the secret stays safe. The attractive property is that n and m are independent dials. Choosing them well is most of the work.

What the two parameters actually do

Three quantities matter, and only the first two are knobs:

• n: total number of shares. Higher n means you can lose more before recovery becomes impossible. This is your durability budget.
• m: threshold required to reconstruct. Higher m means an attacker has to compromise more independent locations to assemble the secret. This is your secrecy budget.
• n − m: the redundancy gap. The number of shares that can be lost before you are locked out.

There is no free lunch. Raising m makes the secret harder to steal but also harder to recover when something goes wrong. Raising n increases your cushion but multiplies the operational burden, because every additional share is a small ongoing project of distribution, periodic checking, and eventual recovery instructions for whoever inherits the system.

The threat models worth distinguishing

The choice becomes tractable when you stop thinking about "security" in the abstract and write down the specific failure modes you want covered. The common ones:

Honest loss. Fire, flood, share decay over decades, a trusted person who moves house and quietly forgets. Defended by a generous n − m.

Single-share theft. A burglar finds one share. With m ≥ 2, the secret stays safe. A scheme where m = 1 is not threshold cryptography; it is regular backups in fancy clothing.

Coercion of the principal. You are pressured to hand over your secrets. With m large enough that you cannot independently reach the threshold, you genuinely cannot produce what you do not control alone. Typically achieved by holding fewer than m shares yourself and distributing the rest to parties who would not cooperate under pressure.

Collusion among shareholders. The shares you distributed conspire against you. Defended by keeping m high relative to n, and by deliberately choosing keyholders whose interests don't align.

Inheritance. You die, and your heirs need to recover the secret without you. Defended by m small enough, and shareholders trusted enough, that the threshold can actually be reached by the people you intend to inherit. This is the threat model that pulls hardest in the opposite direction from coercion resistance, which is why it has to be considered explicitly rather than assumed.

Several of these defences pull in opposite directions, and no single setup maximises every property. The choice is fundamentally about which failures matter most for the secret in question.

Splitting the secret vs. splitting the key

There are two distinct ways to build a threshold backup, and the choice has consequences for how the configurations below behave.

Split the secret. The secret itself (a seed phrase, a master key, a passphrase) is divided directly into n Shamir shares. To use it, you reconstruct the original secret from any m shares. This is the approach taken by Trezor's Shamir Backup and most hardware-wallet implementations. Each share is a fragment of the actual key material, and there is no other artefact to manage.

Encrypt the secret, split the key. The secret is encrypted under a freshly generated symmetric key, and only that key is split into n shares. To recover, you reconstruct the key from m shares and use it to decrypt the ciphertext. This is the approach PaperVault takes. The encrypted vault and the key shares are now independent objects: the vault can be replicated freely without weakening security, because the ciphertext is meaningless without m key shares.

The practical difference is flexibility. In a split-the-secret scheme, every keyholder is implicitly a vault-holder, because they hold a piece of the only copy of the secret material. In a split-the-key scheme, those two roles can be separated. You might give every keyholder a copy of the encrypted vault so any of them can initiate recovery. You might keep the vault in a single archival location (safe-deposit box, notary, fireproof safe) and distribute only key shares. Or both, in different combinations for different secrets.

This also affects collusion resistance specifically. In a split-the-secret scheme, m colluding shareholders by definition hold enough material to reconstruct the secret. In a split-the-key scheme, they still need to obtain the ciphertext from wherever it is held. Collusion is not blocked, but it now requires an independent step that another layer of the threat model can defend against.

The cost is one extra object to manage, because the ciphertext has its own durability requirements. On paper, this is cheap: the ciphertext is just another QR code on another sheet.

Concrete configurations

A few standard choices, each suited to a different profile:

2-of-3. The minimum workable scheme. Three shares, any two recover. One at home, one with a trusted person, one in a safe-deposit box or second location. Tolerates one share loss and defeats single-share theft. The right choice for most individual users. Trezor and Unchained Capital both treat it as the default for ordinary self-custody, on the principle that complexity is the enemy of good security: a smaller scheme that is genuinely maintained beats a larger one that is not.

3-of-5. The next step up. Better against coercion, because no two shareholders can collude into recovery. Better against simultaneous loss, because two shares can disappear before the system fails. Costs noticeably more to maintain. Appropriate when the secret matters across decades, when the value at stake justifies the operational overhead, or when distribution to family or organisational members is part of the design.

3-of-7 / 4-of-7. Common in family or organisational contexts where multiple heirs or stakeholders should each hold a share. The asymmetry forces coordination among heirs without requiring all of them.

5-of-9 and above. Reserved for organisational treasuries and other settings where the cost of getting it wrong dwarfs the cost of operating an unwieldy scheme.

Two configurations to specifically avoid:

• m = 1. Equivalent to n independent copies of the secret. Provides no protection against share theft. If you were going to make redundant copies, just make redundant copies.
• m = n. All shares required. Equivalent to a single secret split for transport, with strictly worse durability than not splitting at all. Every share becomes a single point of failure.

Working heuristics

If you do nothing else, keep these in mind:

1. n − m ≥ 2. Build in tolerance for at least two share losses before recovery becomes impossible.
2. m ≥ 2. Never let a single compromised share unlock the secret.
3. n should stay around 5 or below for personal use, and rarely above 7. Past that, the human and physical logistics dominate the cryptographic guarantees.
4. Test recovery once a year. The most common failure mode is not a stolen share. It is discovering, during an emergency, that one of your shares was misprinted, mislabelled, or quietly degraded.
5. Choose locations with low correlation. Two shares in the same house are one share. Two shares with the same person are one share.

A small exercise

Before deciding on numbers, write down the failure scenarios that actually keep you up about the secret in question. House fire. Phone stolen. You and your partner both unreachable for six months. Your accountant turns hostile. You die unexpectedly. Whichever three of these you can most plausibly see happening to you, those are the ones your choice of m and n needs to defend against.

Then pick the smallest scheme that defends against all three. Resist the pull toward larger numbers. A 2-of-3 scheme you actually maintain is worth more than a 5-of-9 scheme you don't.