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 by keeping a backdoor — an email reset, an admin override, or a "recovery key" stored on their servers. VaultKeepR uses a different approach: Shamir Secret Sharing.

The Recovery Problem

In a traditional password manager:

1. You forget your master password
2. You click "Forgot Password"
3. The company sends a reset link to your email
4. You create a new password
5. Your vault is re-encrypted with the new key

This works great for usability. But it means the company has the ability to access or re-encrypt your vault — which undermines the zero-knowledge guarantee.

If a company can reset your access, they can also grant access to someone else. Every recovery mechanism is also a potential attack vector.

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:

1. Your secret (recovery key) is encoded as the constant term of a random polynomial of degree K-1
2. N points on this polynomial are generated — these are the shares
3. With K or more points, you can reconstruct the polynomial (and thus the secret)
4. 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

Setup (One-Time Process)

1. Generate recovery key material (from your vault encryption key)
Split into 5 shares using Shamir's algorithm
Distribute shares to different locations:
   ├── Share 1 → Your device (local storage)

   ├── Share 2 → IPFS (encrypted, pinned)
   ├── Share 3 → Trusted contact (you share it)
   ├── Share 4 → Smart contract on-chain (encrypted)
   └── Share 5 → VaultKeepR API (encrypted fragment)

Store manifest with share metadata (hashed recovery ID)

Recovery Process

1. Enter your Recovery ID
System looks up the manifest (via hashed ID — prevents enumeration)
Collect shares from available sources (need 3 of 5)
Reconstruct recovery key using Shamir interpolation
Derive encryption key + decrypt vault
Set new master password

Key Security Properties

• Recovery ID is secret — only a hash is stored publicly; knowing the hash doesn't help reconstruct the ID
• Each share is individually useless — even the API share gives VaultKeepR zero knowledge of your vault
• No central reset authority — VaultKeepR cannot unilaterally recover your vault
• Threshold is configurable — advanced users can adjust K-of-N

Why Not Just Use Email Recovery?

Property	Email Reset	Shamir (3-of-5)
Requires trusting the provider	Yes	No
Provider can access your vault	Potentially	No (1 share ≠ threshold)
Resistant to email compromise	No	Yes (email isn't a share location)
Resistant to social engineering	No (support staff)	Yes (no human can override)
Works if provider shuts down	No	Yes (3 shares enough; shares are distributed)
Usability	Very easy	Moderate (requires planning)

The trade-off is real: Shamir recovery requires more setup than clicking "Forgot Password." But it provides a mathematically provable guarantee that no single party can access your vault.

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: company shutdown (but only 1 of 5 shares)

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.

Real-World Scenarios

Scenario 1: Lost Phone

You lose your phone (Share 1 gone).

• Remaining: IPFS + Contact + Smart Contract + API = 4 shares
• Need 3 → ✅ Recovery possible

Scenario 2: VaultKeepR Shuts Down

The company closes (Share 5 gone).

• Remaining: Device + IPFS + Contact + Smart Contract = 4 shares
• Need 3 → ✅ Recovery possible

Scenario 3: Forgot Master Password + Lost Device

Your phone is gone (Share 1) and you forgot your password.

• Remaining: IPFS + Contact + Smart Contract + API = 4 shares
• Need 3 → ✅ Recovery possible, set new master password

Scenario 4: Attacker Compromises VaultKeepR

Attacker gets Share 5 from VaultKeepR.

• They have: 1 share (encrypted)
• They need: 3 shares total
• → ❌ Attacker cannot recover your vault

Scenario 5: Total Catastrophe

You lose your device, forget your Recovery ID, your trusted contact moved countries, and VaultKeepR shut down.

• Available shares: possibly only Smart Contract = 1 share
• Need 3 → ❌ Recovery not possible

This is the trade-off. True self-custody means true responsibility. We recommend testing recovery on a secondary vault before relying on it.

Frequently Asked Questions

Can VaultKeepR recover my vault for me?

No. VaultKeepR holds at most 1 share — below the threshold of 3. Even if VaultKeepR wanted to (or was legally compelled to), they mathematically cannot reconstruct your recovery key.

What happens if I never set up Shamir recovery?

Your vault is protected by your master password + wallet signature. If you lose both, your vault is unrecoverable. Shamir recovery is a Premium feature that adds a safety net.

Can I change the threshold?

Advanced users can configure different K-of-N schemes. The default (3-of-5) balances security and recoverability for most users.

Is Shamir Secret Sharing quantum-resistant?

The underlying mathematical operation (polynomial interpolation over a finite field) is information-theoretically secure — it doesn't rely on computational hardness assumptions. It's secure against quantum computers.

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.

Set up your recovery today →