Cryptographic Secret Sharing Tool

Open Split Secret, enter the phrase, choose the total number of shares (N) and the recovery threshold (M), select Base58, Hex, or Base64, then generate. This tool runs real Shamir Secret Sharing inside a browser Web Worker. Download or print each share and store them separately. For high-value secrets, load the page and optional QR assets first, disconnect from the network, generate the shares, verify a recovery with test data, and wipe the session when finished.

No. Secret encoding, random coefficient generation, finite-field arithmetic, checksums, QR rendering, share parsing, and reconstruction all happen on your device. The tool does not use fetch, beacons, XMLHttpRequest, WebSockets, localStorage, sessionStorage, IndexedDB, cookies, analytics, or telemetry. Values exist only in browser memory until you wipe or close the tab.

N is the total number of shares and M is the minimum required to recover the secret. In a 3-of-5 plan, any 3 distinct shares reconstruct the secret, while 1 or 2 cannot. You may lose up to N−M shares. Choose M high enough to prevent one person from recovering the secret, but low enough that unavailable custodians do not cause permanent loss.

The share payload reveals no information about the original secret under ideal Shamir Secret Sharing with uniformly random coefficients: for fewer than M points, every possible secret remains equally likely. The envelope still exposes operational metadata such as byte length, threshold, total shares, share number, and group linkage. Shamir also cannot protect you if the browser, device, or generation code is compromised.

The split and combine engine works locally after the application assets are loaded. For full QR, image-import, and ZIP functionality offline, make sure those bundled assets have loaded or are available in your saved deployment/cache before disconnecting. No secret-dependent request is ever made. A production offline copy should include the generated JavaScript worker and asset chunks, not only a lone HTML file.

Shamir Secret Sharing is a threshold scheme published by Adi Shamir in 1979. It stores a secret as the constant term of a random polynomial and gives each participant a different point on that polynomial. M points determine a degree M−1 polynomial; fewer points leave the secret mathematically undetermined.

It uses GF(2^8), the 256-element binary field defined by the AES irreducible polynomial x^8 + x^4 + x^3 + x + 1 (0x11B). Every UTF-8 byte receives its own independent random polynomial. GF(2^8) is efficient, exact, and naturally supports arbitrary byte strings without large-integer rounding errors.

Each share supplies a polynomial point (x, f(x)). With M distinct coordinates, Lagrange interpolation computes the unique degree M−1 polynomial through those points. Evaluating the interpolation at x = 0 returns f(0), which is the secret byte. All addition, multiplication, division, and inversion happen inside GF(2^8), not ordinary integer arithmetic.

Yes. The tool detects standard 12, 15, 18, 21, and 24-word counts and validates the checksum against the official English BIP39 wordlist. A warning never prevents splitting because some wallets use non-English lists, custom mnemonics, or intentionally invalid test phrases. The original text is shared exactly as entered.

No. This tool applies standard Shamir mathematics to arbitrary UTF-8 text and wraps points in the FreeDeskTools SSS1 envelope. SLIP-0039 is a separate mnemonic-share standard with its own wordlist, metadata, iteration exponent, and compatibility rules. Do not import SSS1 shares into a wallet expecting SLIP-0039.

Not automatically. Shamir's mathematics is standard, but tools differ in field polynomial, coordinate conventions, byte packing, metadata, checksums, and text encoding. SSS1 shares are self-describing for this implementation. Keep an offline copy of the tool and format documentation with long-term backups.

Each binary envelope includes a 128-bit checksum made from the first 16 bytes of a domain-separated SHA-256 digest. This provides extremely strong accidental corruption detection. It is not authentication: anyone who can alter a share can also recompute its checksum. Active tampering requires signatures, a separately keyed MAC, or a verifiable secret-sharing protocol.

Not reliably. Duplicate coordinates, metadata mismatches, checksum failures, and inconsistent extra points can be detected, but ordinary Shamir sharing is not verifiable secret sharing. With exactly M forged but structurally valid points, interpolation always produces some result. Extra shares can prove inconsistency without always identifying the culprit.

There is no universal answer. 2-of-3 is simple and tolerates one loss, while 3-of-5 gives stronger separation and tolerates two losses. Consider who can collude, who may be unavailable, geographic risks, inheritance needs, and how often recovery will be tested. Never choose a threshold you may be unable to assemble years later.

Store shares in independent places: separate fire-rated safes, bank deposit boxes, trusted custodians, or geographically distant secure sites. Do not put all shares in one folder, cloud account, email thread, password manager, or building. For long-term wallet recovery, durable engraved metal may resist water and fire better than paper.

Yes, when the encoded share fits a practical QR size. Export PNG or SVG, preserve the quiet zone, print at high contrast, and test scanning before relying on it. A QR code adds no encryption. Use a trusted offline scanner because many mobile scanner apps send scanned content to external services.

If fewer than M valid shares remain, the secret is unrecoverable by design. There is no backdoor, password reset, or server copy. This protects against unauthorized recovery but makes testing, inventory records, durable storage, and carefully chosen thresholds essential.

Yes. The tool reconstructs from a deterministic threshold-sized basis and checks every extra share against that polynomial. Extra valid shares do not change the secret, but they can expose an inconsistent point. They do not turn the scheme into authenticated or error-correcting secret sharing.

It clears fields, drops JavaScript references, overwrites accessible typed arrays where practical, terminates the worker, and resets the DOM. JavaScript cannot guarantee forensic erasure of immutable strings, garbage-collected copies, operating-system clipboard contents, swap, screenshots, browser extensions, or compromised devices. Use a clean offline environment for the highest-value secrets.

Define custodians, approval rules, secure locations, succession plans, and a tested recovery ceremony. Record share identifiers without recording share contents. Separate physical and organizational failure domains, rotate shares after staff changes or suspected exposure, and combine Shamir with existing HSM, audit, and incident-response controls rather than treating it as a complete key-management system.