Shamir Secret Sharing (SSS)
A browser-only implementation of Adi Shamir's 1979 secret-sharing scheme — the same construction used by Hashicorp Vault for its master key and by Trezor for sharded crypto seed backups. Choose how many shares to produce (N up to 255) and how many are needed to reconstruct (K, the threshold). Distribute the shares across people, devices, or safe-deposit boxes. Common real uses: splitting a 24-word wallet seed across three trustees so any two can recover it, escrowing a company root password 3-of-5 across executives, or making sure a partner can access important accounts if something happens to you.
How to use
Pick N (how many shares to make) and K (how many you need to recover). Common choices: 2-of-3 for personal, 3-of-5 for small team, 5-of-7 for high-value escrow.
Master password, seed phrase, encryption key — anything up to a few hundred bytes works.
Give each share to a different person, location, or device. Write them on paper, print them, or save in separate password managers.
When you need the secret, gather K of the shares, paste them into the Combine tab, and the secret is reconstructed.
Split a master password or seed phrase into N pieces — any K of them recover it, fewer reveal nothing
What Shamir Secret Sharing does
- Information-theoretic security: with fewer than K shares, an attacker learns NOTHING about the secret — not even its length.
- Each share is the same length as the secret plus a 1-byte index. No password, no key, no entropy lost in sharing.
- Uses the standard byte-wise scheme over GF(2^8) — the same algebra as AES, well-vetted across decades.
- Distribute shares across people, devices, geographic locations. Recovery only needs K of them.
- This implementation does NOT add any password layer on top — the shares ARE the protection. If a share leaks, you have lost one fraction of your safety margin.
Features
FAQ
How is this different from encrypting and giving everyone the password?
Encryption splits the secret into ciphertext + key — anyone with both has full access. Shamir splits the secret directly into N pieces; you need K of them, and K−1 shares reveal nothing mathematically (not just computationally).
What is a good (K, N)?
2-of-3 is the popular default for individuals (two locations, you, partner, lawyer). 3-of-5 for small teams. Higher K reduces risk of compromise; higher N improves survivability against loss.
Can I trust the implementation?
It uses the standard byte-wise Shamir scheme over GF(2⁸) — the same construction used by Hashicorp Vault, Trezor SLIP-0039 (BIP-39 sharded backups) and most other production SSS implementations. Splitting and combining run on your device only; the secret never reaches our server.
What if a share is lost?
As long as at least K shares remain, the secret can be recovered. Distribute N > K to add redundancy — a 3-of-5 scheme survives losing 2 shares.
What if a share is leaked to an attacker?
If fewer than K are leaked, your secret is still safe. You should rotate the secret and redistribute new shares; the old ones can no longer recover anything because the underlying secret has changed.
Is this compatible with other SSS tools?
It uses the canonical byte-wise scheme over GF(2⁸) with the standard 0x1b reduction polynomial. Compatible with most libraries that implement "Shamir over GF(256)" in the same byte format.
We can — and it's free! Just send us a quick message with your idea. If you'd like to discuss it in detail, leave your email and we'll get back to you. You can stay anonymous.
