What is quorum-based (Shamir) secret sharing?
Glassbreak Team · Published 2026-07-17
Quorum-based secret sharing, most commonly implemented with an algorithm called Shamir's Secret Sharing, splits a single secret into N pieces (called shares) such that any T of them can reconstruct the original exactly, while any group of fewer than T shares reveals nothing about it — not a weak hint, but zero information, a mathematical property of the scheme rather than a policy someone enforces. That "T-of-N" threshold is what makes it quorum-based: recovery requires a defined number of independent people to act together, and no smaller group, including a single person who somehow gathered T-1 shares, can do anything with what they have.
How it actually works
The core idea comes from a simple fact about polynomials: two points determine a unique line, three points determine a unique parabola, and in general, T points determine a unique polynomial of degree T-1. Shamir's Secret Sharing puts the secret itself in as the polynomial's constant term, picks the remaining coefficients at random, and evaluates the resulting curve at N different points — each point becomes one share, handed to one person. Given any T of those points, you can solve for the polynomial (and therefore the secret) using standard interpolation. Given fewer than T, every possible secret value remains equally plausible; the missing points genuinely aren't a smaller, weaker version of the answer.
This is why quorum-based sharing is a different (and stronger) thing than the intuitive alternative of just splitting a password into fragments — say, giving three people six characters each of a master password. A fragment scheme like that leaks real information with each piece (an attacker with two of three fragments has narrowed the search space enormously) and it has no clean threshold: there's no mathematical line between "not enough" and "enough," just a gradual erosion of security as pieces accumulate.
Personal secrets vs. team secrets
Shamir's Secret Sharing is only useful once a secret needs more than one keyholder. For something only one person will ever need to decrypt, the simplest and strongest option is no sharing at all: the key is wrapped directly to that person's own private keys, and only they can open it — this is sometimes called the T=1, N=1 case, and no polynomial math is involved. Team or quorum-based recovery — T-of-N with T at least 2 — is for the harder case: a secret several people might legitimately need, where you want recovery to require agreement rather than trust in any single keyholder.
How Glassbreak implements it
Glassbreak stores team secrets using Shamir's Secret Sharing over the finite field GF(2^8), with a threshold you choose per secret (T at least 2, N at least T). A database constraint on the secrets table only allows the two valid shapes — personal (1-of-1) or quorum (T-of-N) — so there's no in-between state, no server-held extra share, and no per-secret override. When a team member approves a recovery request, the approval endpoint only ever handles already-encrypted material: the approver decrypts their own share locally with their own private keys, re-encrypts it to the requester's public keys, and the server forwards the ciphertext without ever being able to read it. The full cryptographic detail — including the hybrid RSA-OAEP-4096 + ML-KEM-1024 wrapping used to protect each share in transit — is on the security page.
Outside of secret recovery, the same quorum principle underlies Glassbreak's broader emergency-access model, described in what is a break-glass procedure — quorum approval is the authentication step in a well-designed break-glass process, and Shamir's Secret Sharing is one concrete way to implement it cryptographically rather than as an honor system. Teams evaluating whether they need this level of guarantee, versus a simpler single-approver setup, can see the fuller pricing and plan breakdown at pricing.
Choosing a threshold
There's no universally correct T-of-N ratio; it's a tradeoff. A higher N relative to T means the secret survives more people being unavailable at once — useful for a distributed or remote team. A higher T relative to N means more independent people must agree before anything is recovered — useful when the secret is high-value and insider risk matters. Most teams land somewhere around 2-of-3 for a small group's shared credential and 3-of-5 or higher for anything that would be genuinely damaging if recovered by the wrong two people acting together.
Frequently asked questions
- Is quorum-based secret sharing the same as multi-signature (multisig)?
- They solve a related problem differently. Multisig typically requires multiple independent signatures to authorize an action (like a transaction), where each signer holds their own full key. Shamir's Secret Sharing instead splits a single key into shares that must be combined to reconstruct the original — there's one secret, mathematically divided, rather than several independent keys each capable of signing.
- What happens if you have fewer than T shares?
- Nothing usable. Below the threshold, the shares carry no information about the secret at all — not "hard to guess," but information-theoretically nothing, the same way one point doesn't determine a line but two do. This is why quorum-based recovery is meaningfully stronger than a password split into pieces: there's no partial credit for holding some but not enough shares.
- Can you increase T or N after shares have already been distributed?
- Not by simply adding a new share to the existing set — that requires either redistributing entirely with a new polynomial, or a more advanced "proactive secret sharing" scheme that periodically refreshes shares without changing the secret. Most practical systems, including Glassbreak's, set the threshold when the secret is created and require re-sharing if it needs to change.
- Who chooses T and N for a team secret?
- Whoever creates the secret, based on how much damage a wrong or malicious recovery could cause and how many people should reasonably need to be involved. A low-stakes shared credential might use 2-of-3; a production database password might use 3-of-5. There's no universally correct number — it's a tradeoff between resilience (higher N, so losing one person doesn't strand the secret) and safety (higher T, so more people must agree).