A recovery key in one person’s password manager is convenient right up to the day that person is unreachable, coerced, or compromised. Copying the same key to five people is worse: you have created five complete points of failure.
Threshold secret sharing solves a narrower and more useful problem. The Shamir Secret Sharing tool on Elysia Tools splits a secret into n shares and requires any k of them to reconstruct it. A 3-of-5 policy can survive two unavailable custodians, yet no single share contains the original password, API key, or recovery phrase.
Choose the failure policy before the numbers
k and n are not decorative settings. They encode which failures your recovery plan will tolerate. In a 3-of-5 scheme, any three holders can recover the secret. Two missing holders do not stop recovery. One or two colluding holders still do not have enough material to reconstruct it.
The tempting mistake is to lower the threshold for convenience. A 2-of-5 policy is easier to activate, but it also takes only two compromised holders to activate it. A 5-of-5 policy minimizes collusion risk while making every holder a required dependency. Pick the threat model first: staff turnover, travel, disaster recovery, insider risk, or some mix of them.
For a small organization, 3-of-5 is often a sensible rehearsal scenario rather than a universal prescription. Put the shares under genuinely separate control. Five files in the same cloud drive are one failure domain wearing five filenames.
What the tool does with each byte
The implementation is concrete. For every byte of the UTF-8 secret, it creates a random polynomial of degree k-1 over GF(256). The secret byte is the constant term. The remaining coefficients come from Node’s crypto.randomBytes(), backed by the operating system CSPRNG, rather than Math.random().
Share i evaluates those byte polynomials at x=i. Recovery takes the supplied points and performs Lagrange interpolation at x=0, where the constant terms reveal the original bytes. The source uses the AES irreducible polynomial 0x11B and the primitive field element 0x03 to build its exponent and logarithm tables.
The generated representation starts with sss:, followed by base64url encoding of an x-coordinate and the evaluated y bytes. Keep the entire string. Truncating, wrapping, autocorrecting, or retyping a share can make recovery fail or, worse, produce bad input that the basic format parser cannot authenticate.
Split and combine are deliberately simple
In Split mode, paste the secret, set the threshold and total share count, and generate the shares. The tool accepts thresholds and totals from 2 through 255, with k no greater than n. Its secret input is capped at 10,000 characters. Each share should then move to a different custodian through an appropriate secure channel.
In Combine mode, paste one share per line. The current combine routine requires at least two lines but does not carry the original threshold inside each share, so the operator must know the policy and provide a valid subset. With too few or forged shares, the mathematics may still emit bytes. Do not interpret output alone as proof that the right secret was recovered.
You can try the split-and-combine workflow here with a disposable test phrase. The tool runs the cryptographic operation in process and does not use a network call for the split itself, but you should still avoid experimenting with a production secret on any system you have not approved for handling that secret.
The caveat that matters: secrecy is not integrity
Shamir’s scheme protects confidentiality below the threshold. It does not prove that a submitted share came from an authorized holder, and this implementation does not add verifiable secret sharing. A malicious custodian can alter a share. Recovery can then produce a plausible but incorrect value without identifying the bad participant.
Wrap the secret in an integrity mechanism before splitting it. Depending on the operating model, that may mean signing the secret, signing a hash, or authenticating an encrypted envelope. After recovery, verify that protection before anyone uses the result. The verification material must be stored so that an attacker cannot replace it together with the shares.
Run a recovery drill, not just a split ceremony
Start with a disposable test value. Generate a 3-of-5 set, then recover it from shares 1, 3, and 5. Repeat with 2, 3, and 4. Remove one custodian from the exercise. Corrupt a copy of one share and confirm that your external signature or MAC rejects the result. Record who is allowed to start recovery and how custody changes are handled when someone leaves.
Do not keep the only procedure next to the only shares. The recovery runbook should explain the threshold, approved custodians, share locations at a useful level, the verification step, and how to rotate the complete set after exposure. Never reuse an old share after generating a replacement set for the same secret.
A recovery design you can explain under pressure
The useful promise is modest: no single custodian holds the recovery secret, and the organization can lose some holders without losing access. The Shamir Secret Sharing tool makes the 3-of-5 mechanics easy to test, including the exact share format and GF(256) recovery path. The operational work remains yours. Separate the holders, authenticate the recovered secret, rehearse multiple valid subsets, and rotate the set after any suspected exposure.
Explore more focused utilities at elysiatools.com.
