# Shamir Secret Sharing — Recovery Without a "Forgot Password" Button

# 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)
2. Split into 5 shares using Shamir's algorithm
3. 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)
4. Store manifest with share metadata (hashed recovery ID)
```

### Recovery Process

```
1. Enter your Recovery ID
2. System looks up the manifest (via hashed ID — prevents enumeration)
3. Collect shares from available sources (need 3 of 5)
4. Reconstruct recovery key using Shamir interpolation
5. Derive encryption key + decrypt vault
6. 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 → Yes Recovery possible

### Scenario 2: VaultKeepR Shuts Down
The company closes (Share 5 gone).
- Remaining: Device + IPFS + Contact + Smart Contract = 4 shares
- Need 3 → Yes 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 → Yes 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
- → No 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 → No 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](/blog/wallet-authentication-explained)
- [Argon2id Explained — Protecting Your Vault](/blog/argon2id-key-derivation)
- [Why We're Building VaultKeepR](/blog/why-were-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 →](https://vaultkeepr.xyz)