Shamir Secret Sharing — Recovery Without a "Forgot Password" Button
Here's the paradox of zero-knowledge password managers: if the provider truly can't access your data, how do you recover if you lose your master password?
Most password managers solve this through a provider-mediated path: an email reset, an admin override, or a recovery key the provider holds. These are documented mechanisms with their own key custody, not automatically provider backdoors; Bitwarden, for example, documents Emergency Access that shares an encrypted key with a contact you choose. VaultKeepR uses a different approach: Shamir Secret Sharing, where you split the key and set the threshold.
The Recovery Problem
A backup should allow recovery without automatically giving storage access to the secret. Competing products offer different mechanisms; a reset or recovery key is not inherently a backdoor. Inspect what it recovers and who holds the required material.
What Is Shamir Secret Sharing?
Shamir Secret Sharing (SSS) was invented by Adi Shamir (the "S" in RSA) in 1979. It's a mathematical technique that splits a secret into N parts (shares), such that any K of N shares can reconstruct the original secret, but fewer than K shares reveal absolutely nothing.
The Math (Simplified)
The core idea uses polynomial interpolation:
- Your secret (recovery key) is encoded as the constant term of a random polynomial of degree K-1
- N points on this polynomial are generated — these are the shares
- With K or more points, you can reconstruct the polynomial (and thus the secret)
- With fewer than K points, the secret could be anything — no information leaks
This isn't "splitting the key in half." It's mathematically provable that K-1 shares give zero information about the secret.
Example: 3-of-5
VaultKeepR's default configuration is 3-of-5:
- Your recovery key is split into 5 shares
- Any 3 shares are sufficient to reconstruct the key
- 2 or fewer shares reveal nothing
This means:
- You can lose 2 shares and still recover
- An attacker must compromise 3 separate locations
- No single location holds enough to access your vault
How VaultKeepR Implements Shamir Recovery
VaultKeepR Premium uses Shamir 3-of-5 recovery for the vault encryption key. The five configured channels are the device, remote storage, a trusted contact or QR handoff, a smart contract, and the API. Any three valid fragments can reconstruct the key; losing too many fragments or the recovery identifier can prevent recovery. See the current SDK defaults, channel distribution, and recovery guide. This recovers a vault key, not a hardware passkey or each seed phrase stored in the vault.
Why Not Just Use Email Recovery?
Email is an identification or contact channel, not proof that a provider holds plaintext. Shamir distributes a recovery secret under a threshold, but security depends on distribution, fragment encryption and the recovery identifier.
Distributing Your Shares: Best Practices
Share 1: Device Storage
- Automatically stored on your primary device
- Encrypted at rest
- Risk: device loss or theft
Share 2: IPFS
- Encrypted fragment stored on IPFS
- Content-addressed (CID), persistent, distributed
- Risk: requires your Recovery ID to locate
Share 3: Trusted Contact
- Share a fragment with someone you trust (family, close friend)
- They can't do anything with just one share
- Risk: relationship breakdown, contact loses the share
Share 4: Smart Contract
- Encrypted fragment stored on-chain (e.g., Base network)
- Indexed by a hash of your lookup ID
- Immutable and censorship-resistant
- Risk: blockchain fees, permanence (can't delete)
Share 5: VaultKeepR API
- Encrypted fragment stored on VaultKeepR's servers
- VaultKeepR sees only encrypted data, not the share content
- Risk: a shutdown can hit several channels at once (API, storage or pinning, access services), so the remaining shares must still meet the threshold on their own; five channel names do not establish five independent operators
The Golden Rule
Never store more than K-1 shares in locations controlled by the same entity (including yourself). If you have all 5 shares on one device, a single device compromise recovers everything.
Recovery test scenarios
Illustrative test scenarios, not customer cases: losing a device may still allow recovery if three valid fragments, their required decryption material and the ciphertext remain accessible. A provider shutdown can affect more than one channel; five channel names do not establish five independent operators.
Test those losses on a non-sensitive vault before depending on recovery.
Frequently Asked Questions
The SDK supports threshold configuration; its current default is 3-of-5. Do not assume every SDK setting is exposed in a public client screen. Biometric, wallet and password paths have their own requirements.
Keep Reading
- Wallet-Based Authentication Explained
- Argon2id Explained — Protecting Your Vault
- Why We're Building VaultKeepR
Recovery shouldn't require asking a company for permission. VaultKeepR's Shamir Secret Sharing gives you a backup plan that no single entity can override — including us.
