# Social Recovery in CQRIT

## The Problem

**Traditional encryption key management:**
```
User loses key → Data lost forever → No recovery possible
```

**Centralized solutions:**
```
Forget password → Company resets it → Company has control
```

**CQRIT challenge:**
- Keys never stored (see [Key Management](key-management.md))
- No company backdoor exists
- User forgets memory inputs → Key cannot be regenerated
- Need recovery without central authority

## The Solution: Social Recovery

**Concept:**
Distribute secret knowledge across trusted individuals. No single person has full access. Minimum threshold required to reconstruct.

**Mathematical Basis:**
Shamir's Secret Sharing (threshold cryptography)

**Example:**
```
Split secret into 5 shares
Require any 3 to reconstruct
Each friend gets 1 share
If you forget inputs, get help from 3+ friends
```

## How It Works

### Setup Phase

**Step 1: User Creates Shares**
```
User's Key Inputs: "fluffy", "blue", "elm street"
↓
Generate Recovery Secret
↓
Split into N shares (e.g., 5)
↓
Share 1, Share 2, Share 3, Share 4, Share 5
```

**Step 2: Distribute to Guardians**
```
Alice gets Share 1
Bob gets Share 2
Carol gets Share 3
David gets Share 4
Eve gets Share 5
```

**Properties:**
- Each guardian has 1 share
- No guardian can reconstruct secret alone
- Any M guardians (e.g., 3) can reconstruct
- Remaining guardians (2) cannot

### Recovery Phase

**Step 1: User Needs Recovery**
```
User: "I forgot my memory inputs. I cannot regenerate my key."
```

**Step 2: Contact Guardians**
```
User contacts Alice, Bob, Carol
(or any 3 of the 5 guardians)
```

**Step 3: Guardians Provide Shares**
```
Alice: Share 1
Bob: Share 2
Carol: Share 3
↓
Threshold Met (3 of 5)
↓
Reconstruct Recovery Secret
```

**Step 4: Derive New Key**
```
Recovery Secret → New Memory Inputs (or direct key)
↓
User sets new memory inputs
↓
Access restored
```

## Threshold Cryptography

### M-of-N Schemes

**Definition:**
- N = Total shares created
- M = Minimum shares needed to reconstruct

**Common Configurations:**

| Scheme | Use Case | Risk Profile |
|--------|----------|--------------|
| 2-of-3 | Small family | Low risk, easy recovery |
| 3-of-5 | Friend group | Balanced |
| 5-of-9 | High security | Harder to collude |
| 7-of-10 | Enterprise | Maximum security |

**Choosing M and N:**
- Higher M: More secure (harder to collude)
- Lower M: Easier recovery (fewer people needed)
- Higher N: More redundancy (guardians can be unavailable)

### Mathematical Properties

**Property 1: Threshold Requirement**
```
M-1 shares: Cannot reconstruct (information-theoretically secure)
M shares: Can reconstruct fully
```

**Property 2: Share Independence**
```
Each share contains zero information about secret
Combining M-1 shares reveals nothing
Only M shares reveal everything
```

**Example:**
```
3-of-5 scheme:
- 2 shares together: 0% of secret revealed
- 3 shares together: 100% of secret revealed
```

## Security Properties

### Guarantees

✅ **No Single Point of Failure:**
- One guardian compromised = no secret leaked
- Requires M compromises

✅ **Unavailability Tolerance:**
- Up to N-M guardians can be unavailable
- Example: 3-of-5 means 2 guardians can disappear

✅ **Collusion Resistance:**
- M-1 guardians colluding cannot access secret
- Requires at least M dishonest guardians

### Risks

⚠️ **Guardian Collusion:**
- If M guardians collude, secret exposed
- Mitigation: Choose trustworthy guardians, high M value

⚠️ **All Guardians Unavailable:**
- If fewer than M guardians reachable, recovery fails
- Mitigation: Choose N high enough for redundancy

⚠️ **Guardian Coercion:**
- Attacker coerces M guardians
- Mitigation: Geographic distribution, anti-kidnapping features

## Implementation in CQRIT

### Guardian Types

**1. Family Members**
```
Use Case: Personal data recovery
Example: Crypto wallet, family documents
Guardians: Parents, siblings, spouse
Scheme: 2-of-3 or 3-of-5
```

**2. Close Friends**
```
Use Case: Personal projects, business data
Example: Startup files, development keys
Guardians: Co-founders, trusted colleagues
Scheme: 3-of-5
```

**3. Professional Services**
```
Use Case: Enterprise recovery
Example: Company secrets, IP
Guardians: Lawyers, executives, board members
Scheme: 5-of-9
```

### Share Storage

**Where Guardians Store Shares:**

**Option 1: Physical**
- Written on paper
- Stored in safe
- Pros: Offline, air-gapped
- Cons: Can be lost/destroyed

**Option 2: Digital (Encrypted)**
- Encrypted file on guardian's device
- Guardian has own CQRIT account
- Pros: Durable, backed up
- Cons: Digital attack surface

**Option 3: Hybrid**
- Physical backup + digital copy
- Best of both worlds

**Recommendation:**
Guardians encrypt their share with their own CQRIT key (memory-based).

### Recovery Process (Technical)

```javascript
// Pseudocode

// 1. User initiates recovery
function startRecovery() {
  const guardians = selectGuardians(M)
  const shares = []
  
  for (const guardian of guardians) {
    const share = requestShare(guardian)
    shares.push(share)
  }
  
  return shares
}

// 2. Reconstruct secret
function reconstructSecret(shares) {
  if (shares.length < M) {
    throw new Error("Insufficient shares")
  }
  
  const secret = shamirReconstruct(shares, M, N)
  return secret
}

// 3. Derive new key or reset memory inputs
function finalizeRecovery(secret) {
  // Option A: Use secret directly as key
  const key = deriveKeyFromSecret(secret)
  
  // Option B: User sets new memory inputs
  const newInputs = promptNewMemoryInputs()
  const newKey = generateKey(newInputs)
  
  // Re-encrypt data with new key
  reEncryptAllData(oldKey, newKey)
  
  // Optionally create new shares
  createNewShares(newInputs)
}
```

### Cross-Device Recovery

**Scenario:** User loses Device A, has Device B, forgot inputs

**Steps:**
1. On Device B, start recovery process
2. Contact M guardians
3. Guardians provide shares (via QR code, encrypted message, etc.)
4. Device B reconstructs secret
5. User regains access on Device B

**Network Transmission:**
- Shares transmitted encrypted (end-to-end)
- Each guardian encrypts share with user's public key
- User decrypts with recovery key

## Use Cases

### Use Case 1: Crypto Wallet Recovery

**Setup:**
- User has crypto wallet encrypted in CQRIT
- User creates 3-of-5 recovery scheme
- Guardians: 2 family, 3 friends

**Recovery Event:**
- User forgets memory inputs
- User contacts any 3 guardians
- Guardians provide shares
- User reconstructs key
- Wallet access restored

**Result:**
No seed phrase backup needed. Social recovery instead.

### Use Case 2: Family Document Sharing

**Setup:**
- Family documents (wills, deeds, passwords)
- Parents create 2-of-4 scheme
- Guardians: 2 adult children, 2 trusted relatives

**Recovery Event:**
- Parents incapacitated/deceased
- Any 2 children can recover
- Documents accessible to family

**Result:**
Estate planning without third-party escrow.

### Use Case 3: Enterprise Secrets

**Setup:**
- Company IP, signing keys
- CEO creates 5-of-9 scheme
- Guardians: C-suite, board members, legal counsel

**Recovery Event:**
- CEO leaves company / passes away
- 5 board members provide shares
- Company retains access to secrets

**Result:**
No single person dependency. Company continuity.

### Use Case 4: Anti-Kidnapping

**Setup:**
- High-value crypto wallet
- User creates 10-of-10 scheme (all shares required)
- Guardians: Distributed globally

**Recovery Event:**
- User kidnapped, coerced
- Attacker cannot get all 10 guardians
- Even if user cooperates, insufficient shares

**Result:**
Kidnapping becomes pointless. See [Coercion Resistance](coercion.md).

## Configuration Recommendations

### Personal Use
```
Recommendation: 2-of-3 or 3-of-5
Guardians: Close family, best friends
Balance: Easy recovery, reasonable security
```

### Business Use
```
Recommendation: 3-of-5 or 4-of-7
Guardians: Co-founders, executives, board members
Balance: Business continuity, collusion protection
```

### High-Security Use
```
Recommendation: 5-of-9 or 7-of-10
Guardians: Geographically distributed, professional relationships
Balance: Maximum collusion resistance, redundancy
```

### Anti-Kidnapping Use
```
Recommendation: N-of-N (all required) with high N (e.g., 10)
Guardians: Global distribution, some anonymous
Balance: Maximum coercion resistance, recovery still possible
```

## Edge Cases

### Case 1: Guardian Dies
**Impact:** Reduces available shares from N to N-1
**Solution:** If still have M shares available, recovery works. Otherwise, recreate shares.

### Case 2: Guardian Loses Share
**Impact:** Same as death (reduces N to N-1)
**Solution:** User regenerates and redistributes shares

### Case 3: Guardian Becomes Adversary
**Impact:** One adversarial guardian = no risk (needs M)
**Solution:** If concerned, recreate shares and exclude that guardian

### Case 4: User Wants to Change Guardians
**Process:**
1. User accesses account (via current memory inputs)
2. Regenerate shares with new N
3. Distribute to new guardians
4. Revoke old shares

### Case 5: All Guardians Unavailable
**Impact:** Recovery impossible
**Prevention:** 
- High N with geographic distribution
- Multiple guardian groups
- Physical backup of one share (user's own safe)

## Privacy Considerations

### What Guardians See

**What Guardians Know:**
- They hold a recovery share
- They are part of an M-of-N scheme
- (Optionally) what the shares protect

**What Guardians DO NOT Know:**
- The actual secret
- Who the other guardians are (unless told)
- Contents of encrypted data

### Anonymous Guardians

**Possible Implementation:**
```
User: Creates share for "Guardian 5"
Guardian 5: Anonymous service/person, user has contact method
Reconstruction: Guardian provides share via anonymous channel
```

**Use Case:** 
High-security scenarios where guardian identity needs protection.

## Integration with Other Features

### Social Recovery + Coercion Resistance
See [Coercion Resistance](coercion.md)

**Combination:**
- User sets up N-of-N recovery (all shares needed)
- Attacker coerces user
- User cannot provide all shares alone
- Attacker must coerce all guardians (infeasible if distributed)

### Social Recovery + Group Encryption
**Combination:**
- Group of users share encrypted data
- Each user has own recovery scheme
- Group continuity even if members forget inputs

## Future Enhancements

- Time-locked shares (share unlocks after X time)
- Conditional shares (share unlocks if condition met)
- Geographic-based shares (require physical presence)
- Multi-signature recovery (M-of-N + biometric + hardware key)

---

**Next:** Read [Coercion Resistance](coercion.md) to understand anti-kidnapping protections