Shamir's Secret Sharing, explained without the math degree

Here's a problem every team eventually hits: you have one credential that matters too much. The root signing key. The production database master password. The recovery codes for the company's domain registrar. Give it to one person and you have a single point of failure — they leave, get phished, or lose a laptop. Give it to everyone and you've multiplied the attack surface by headcount.

In 1979, Adi Shamir (the "S" in RSA) published a two-page paper that solves this exactly: split the secret into n shares so that any k of them reconstruct it, while k − 1 shares reveal nothing at all. Not "nothing practical" — mathematically, provably nothing.

The intuition: points on a curve

Two points define a line. Three points define a parabola. In general, you need k points to pin down a polynomial of degree k − 1.

Shamir's trick: hide the secret as the y-intercept of a random polynomial. Want a 3-of-5 split? Pick a random degree-2 polynomial whose value at x = 0 is your secret, then hand out five points on the curve — one per person. Any three holders can redraw the parabola and read the intercept. Two holders? There are infinitely many parabolas through their two points, one for every possible secret value, all equally likely. Their shares are literally worthless — which is the entire point.

This is what cryptographers call information-theoretic security: the guarantee doesn't depend on a computational problem being hard. A quantum computer the size of Jupiter cannot extract a secret from k − 1 shares, because the information simply isn't in them.

From parabolas to bytes

Real implementations don't draw curves over ordinary numbers — rounding would leak information. They work in a finite field, typically GF(256), which conveniently has exactly one element per possible byte value. Each byte of your secret gets its own polynomial; each share ends up the same size as the secret. The arithmetic is exact, fast, and runs comfortably in a browser.

Choosing k and n in practice

2-of-3 — the founder setup. You, your co-founder, and a sealed share in a safe. Either of you plus the safe recovers it; a single stolen laptop doesn't.
3-of-5 — the classic ops-team split. Any three engineers can rotate the master credential at 3 a.m.; no pair can collude quietly, and two people can be on holiday without blocking an incident.
4-of-7 — board-level or DAO-style control for keys that move money or sign releases.

The two failure modes to balance: set k too high and you've built a denial-of-service against yourself (shares get lost; people leave); too low and collusion gets cheap. A useful rule of thumb is k = ⌈n/2⌉ + 1.

What Shamir doesn't solve

Honesty requires the fine print. Plain Shamir assumes shares are delivered securely (splitting a secret and then emailing the shares defeats the purpose), assumes holders return correct shares at reconstruction (verifiable secret sharing extends the scheme if you need that), and says nothing about the moment of reconstruction itself — wherever the secret is reassembled becomes, briefly, the thing you were trying to avoid: a single point holding the whole secret.

How Secretus uses it

Team Split in Secretus runs Shamir over GF(256) entirely in your browser — the splitting, and later the reconstruction, never touch our servers. Each holder receives their share inside a link's URL fragment, which browsers never transmit to any server, so delivery doesn't leak shares either. Reconstruction happens client-side when k holders contribute their shares, and optional expiry (24 hours to 30 days) bounds the exposure window. No single teammate, no single channel, and certainly not us, ever holds enough to read the secret.

Shamir's paper was titled "How to share a secret". Forty-seven years later, it's still the correct answer.