Shamir secret sharing

We use a 2-of-3 Shamir Secret Sharing (SSS) scheme over GF(256). One key, three shares, any two suffice.

Why 2-of-3

Combination	Outcome
Device + Provider	Normal sign — the user has their device, server validates them
Device + Recovery	Disaster recovery if Sigil is unreachable
Provider + Recovery	New-device flow: user signs in, we rebuild the key with the recovery share, then re-share with a fresh polynomial

A single share is information-theoretically useless. Stealing one share reveals zero bits about the private key.

Where the math runs

SSS combine and split run only inside the iframe. The Sigil backend never sees a plaintext share concatenated with the others. The iframe imports shamir-secret-sharing (TS), wipes intermediate buffers in finally blocks, and never persists reconstructed material.

Polynomial rotation

Every recovery rotates the polynomial. New shares are issued for the same private key (mathematically: a fresh f(x) of degree 1 with the same f(0)), the old shares are marked rotated, and after a grace period they’re purged. A leaked old share becomes useless once rotation completes.