Shamir Secret Sharing, Explained

After reading this you will understand how a secret splits into n shares so that any k rebuild it and any k-1 reveal nothing, why that guarantee is exact rather than merely hard to break, and how to store shares without creating a new single point of failure.

What the scheme does

Shamir Secret Sharing takes one secret (a wallet seed, a master key, a recovery code) and produces n shares. You pick a threshold k. Any k of the shares reconstruct the secret exactly. Any k-1 of them leave every possible secret equally likely.

Here is the hook. Split a 256-bit key into n=5 shares with threshold k=3, and hand one each to five people in different cities. No single person can recover the key. No pair can either. Lose two shares (a fire, a lost drive) and the remaining three still rebuild the key perfectly. Adi Shamir published this in 1979, and the math has not aged: the security is information-theoretic, not computational.

The tool implements the classic construction over the finite field GF(256), one byte at a time. It prepends a 2-byte CRC-16 to the secret before splitting so the combiner can flag an obviously wrong reconstruction. Shares print as index-hexdata, one per line.

When to use it, and when not to

Use threshold sharing when you want to survive both loss and theft of individual copies. The pattern fits master keys, backup encryption keys, and cryptocurrency seeds. Choosing k and n sets your two failure budgets at once: you can lose up to n-k shares and still recover, and an attacker needs k shares to steal the secret.

Do not use plain Shamir when the people holding shares might be adversaries who could submit forged shares during reconstruction. The basic scheme cannot detect a lying shareholder; it only detects accidents through the CRC. For that threat you need verifiable secret sharing, which adds commitments so each share can be checked against a public value.

The math, and why it works

Treat the secret byte as the constant term a_0 of a polynomial. Pick the other coefficients at random and evaluate at x = 1, 2, \dots, n. Each evaluation is one share.

Here a_0 is the secret, and a_1 \dots a_{k-1} are uniformly random field elements. The degree is k-1. Share i is the pair (i, f(i)). All arithmetic happens in GF(256), so every value is a single byte and there is no rounding.

Reconstruction uses Lagrange interpolation. Given any k points, exactly one degree-(k-1) polynomial passes through them, and you evaluate it at x=0 to read off a_0.

The y_j are the share values, the x_j are the share indices, and the product term is the Lagrange coefficient that isolates point j. Because a degree-(k-1) polynomial has k free coefficients, k points pin it down uniquely. With only k-1 points the constant term can still be any of the 256 byte values, and each is equally consistent with what you hold. That is the whole security argument: not "hard to guess" but "nothing to guess".

A worked example over GF(256)

Multi-byte secrets repeat this independently per byte, each with its own fresh random polynomial. The CRC-16 is computed over the whole secret first, prepended, and then the combined blob is what actually gets split.

What k-1 shares actually leak

The claim "reveals absolutely nothing" is precise. Fix any k-1 shares. For each of the 256 candidate secret bytes there is exactly one choice of the remaining random coefficients that makes those shares consistent. So all 256 candidates remain equally likely, a flat distribution with probability 1/256 \approx 0.0039 each. Adding the k-th share collapses that to a single value.

This is why more computing power does not help an attacker below threshold. There is no biased distribution to exploit and no shortcut, because the field arithmetic destroys any correlation between individual shares and the secret.

Reading the combiner output and the CRC

When you combine shares, the tool interpolates each byte at x=0, then checks the recovered CRC-16 against the recovered payload. A match means the reconstruction is plausible. A mismatch usually means you mixed shares from different secrets, mistyped a hex byte, or supplied fewer than k genuine shares.

Common mistakes

The failures below account for most real-world losses with threshold schemes. None of them are flaws in the math.

Storing all shares together

If a drawer holds all n shares, you have recreated a single point of failure. Distribution across independent locations is the point.

Setting k too high

With k=n you tolerate zero losses. One destroyed share makes the secret unrecoverable forever. Leave slack: n-k \ge 1.

Reusing a polynomial

Each split must use fresh random coefficients from a good CSPRNG. Predictable randomness weakens the guarantee. See the cryptographic key generator for high-quality random material.

Confusing share index with order

The index i in i-hexdata is the x coordinate. Two shares with the same index are the same point and cannot reconstruct. Keep indices distinct.

Splitting a low-entropy secret directly

Sharing a weak PIN does not make it strong. If your secret is a password, run it through a KDF first with PBKDF2 and HKDF, then split the derived key.

Frequently asked questions

Related tools

AES Encryption

Encrypt and decrypt text with AES-GCM or AES-CBC.

Cryptographic Key Generator

Random keys, IVs, salts and API tokens from a CSPRNG.

Key Derivation: PBKDF2 & HKDF

Derive keys from passwords (PBKDF2) or key material (HKDF).

Enigma Machine Simulator

Operate a full Enigma I — rotors, plugboard, lamp board — and watch each letter travel the wiring.

JWT Builder & Signer

Build and sign JSON Web Tokens (HS256/384/512).

Proof-of-Work Mining Simulator

Mine blocks with real SHA-256, tamper with a chain, and see why difficulty and 51% attacks work the way they do.