Why secret sharing exists

How do you store a secret - a wallet seed, a master password, a safe combination, a short message - such that no single point of failure can either lose or leak it? Keep it in one place and you create a single point of loss: fire, flood, or theft destroys your only copy. Copy it to several places and you create several points of compromise, each an independent risk. Secret sharing is the way out of this dilemma.

Approaches that don't work

Photocopy the secret

Storing the same secret in several locations solves the availability problem but destroys confidentiality. Each additional copy is an independent surface for compromise: a house fire is survived, but a burglary, a nosy relative, or a careless executor now exposes the whole secret. You have traded one failure mode for another. More copies means more risk, not less - and there is no threshold property: one copy in the wrong hands is already a total loss.

Split the secret in half

Giving two people half the secret each feels intuitive, but it fails three ways. First, there is no redundancy: lose either half and the secret is gone for good - worse than a single copy, not better. Second, recombining the halves is an informal ritual - you have to remember which half is which and in what order they join, with nothing to record or verify it. Third, half a secret is rarely half-secret: for a password, a combination, or a message, the missing half is often guessable from the half an attacker already holds. Only a uniformly random value, like a wallet seed's entropy, keeps real strength in its remaining bits - and even then, cutting it in two has bought you nothing over keeping it whole in one place.

Encrypt with a passphrase

Encrypting the secret backup with a strong passphrase sounds like a defense in depth, but it moves the problem rather than solving it. The passphrase is now the single point of failure. Forget the passphrase and the backup is useless; write it down and you have a new unprotected secret to protect; split it across memories of two trusted people and you have an informal secret-sharing scheme with no formal security properties. Encryption with a passphrase solves storage confidentiality, not the threshold problem.

Shamir's insight

In 1979, Adi Shamir observed that a polynomial of degree M−1 is uniquely determined by exactly M points. If you encode the secret as the constant term of a random degree-(M−1) polynomial, then each share is one point on that polynomial - a pair (x, y) where x is the share's x-coordinate and y is the polynomial evaluated at x. To recover the secret you need M shares: M points uniquely determine the polynomial, and evaluating it at x=0 gives back the secret.

chela picks each x at random from 1..32 rather than handing out a sequential 1..N, so a share leaks neither the total number of shares nor its own position. The x is public - it is printed on the share - so its randomness is a privacy property, not a confidentiality one; what must stay secret is the polynomial's coefficients.

Below M points, infinitely many polynomials of degree M−1 pass through any M−1 (or fewer) given points. Every possible secret is equally consistent with the shares you hold. This is not "computationally hard to invert" - it is information-theoretically impossible to distinguish. A share holder with M−1 shares learns exactly nothing about the secret beyond what they already knew.

Ordinary polynomial arithmetic over the integers would leak information because share values can grow without bound and statistical relationships creep in. chela works over GF(2^8) - a finite field of 256 elements that operates on individual bytes - so each byte of the secret is processed independently with no carry between bytes and no information leak. How that field arithmetic becomes the actual words on a share is laid out in the share format.

If you want to skip to the implementation: chela-sss/src/lib.rs