# Threat Model for CQRIT

## Overview

This document describes:
- **What CQRIT protects against** (security guarantees)
- **What CQRIT partially protects against** (mitigations available)
- **What CQRIT does NOT protect against** (out of scope)

**Principle:** Transparent about limitations. No security through obscurity.

---

## Assumptions

### 1. Cryptographic Assumptions

**We assume:**
- CRYSTALS-Kyber is quantum-resistant (NIST selected)
- AES-256-GCM is secure (industry standard)
- KDF (Argon2id/PBKDF2) is resistant to brute force with high iterations
- SHA-256 is collision-resistant
- PQXDH protocol is secure (hybrid classical + post-quantum)

**If these break:**
System security compromised.

### 2. Implementation Assumptions

**We assume:**
- Browser sandbox is secure (malicious sites cannot access CQRIT data)
- Browser crypto libraries (Web Crypto API) correctly implemented
- Rust/WebAssembly execution is secure (no critical bugs in toolchain)
- JavaScript fallback uses vetted libraries (TweetNaCl, etc.)

**If these break:**
Client-side execution compromised.

### 3. User Assumptions

**We assume:**
- User chooses high-entropy memory inputs (not "password123")
- User does not share memory inputs publicly
- User sets up social recovery if they might forget inputs
- User uses trusted devices (not malware-infected)

**If these fail:**
User-specific compromise (not system-wide).

### 4. Trust Assumptions

**We assume:**
- Social recovery guardians are trustworthy (if enabled)
- M-of-N threshold is set appropriately (if using high-security mode)
- User does not intentionally sabotage own security

**If these fail:**
User-level compromise (system design allows, user choice).

---

## Threat Categories

### ✅ Strong Protections (What CQRIT Guarantees)

#### 1. Server-Side Compromise

**Threat:**
- Attacker breaks into CQRIT server/database
- Steals all data

**CQRIT Protection:**
- All data encrypted client-side
- Server never sees plaintext
- Server never sees keys
- Even full database dump reveals only ciphertext

**Guarantee:**
Server breach cannot decrypt user data.

**Why:**
Keys never leave client. Server is untrusted by design.

---

#### 2. Quantum Computer Attacks (Future-Proofing)

**Threat:**
- Attacker has quantum computer
- Breaks RSA/ECC encryption
- Decrypts classical encrypted data

**CQRIT Protection:**
- Uses CRYSTALS-Kyber (post-quantum KEM)
- Uses PQXDH (hybrid classical + post-quantum key exchange)
- Symmetric encryption (AES-256) already quantum-resistant

**Guarantee:**
Future quantum computers cannot decrypt CQRIT data (assuming CRYSTALS-Kyber holds).

**Why:**
Post-quantum algorithms designed to resist quantum attacks.

---

#### 3. Man-in-the-Middle (MITM) on Encrypted Data

**Threat:**
- Attacker intercepts encrypted data in transit
- Modifies or replaces ciphertext

**CQRIT Protection:**
- AES-256-GCM provides authenticated encryption
- Tampering detected
- Decryption fails if ciphertext modified

**Guarantee:**
Attacker cannot tamper with encrypted data undetected.

**Why:**
AEAD (Authenticated Encryption with Associated Data) included.

---

#### 4. Passive Network Surveillance

**Threat:**
- Attacker monitors all network traffic
- Collects encrypted data for later analysis

**CQRIT Protection:**
- Encryption performed client-side
- Network sees only ciphertext
- Keys never transmitted

**Guarantee:**
Network surveillance cannot decrypt data.

**Why:**
End-to-end encryption. No keys in transit.

---

#### 5. Cloud Provider Compromise

**Threat:**
- Cloud storage provider breached
- Attacker downloads all user files

**CQRIT Protection:**
- Files encrypted before upload
- Cloud provider never sees plaintext
- Zero-knowledge storage

**Guarantee:**
Cloud provider breach cannot decrypt user files.

**Why:**
Client-side encryption. Cloud stores only ciphertext.

---

### ⚠️ Partial Protections (Mitigations Available)

#### 1. Coercion / $5 Wrench Attack

**Threat:**
- Attacker kidnaps user
- Forces user to reveal key/passphrase
- Gains access to encrypted data

**CQRIT Mitigation:**
- Social recovery with high threshold (e.g., 10-of-10)
- User cannot decrypt alone (needs guardians)
- Coercion becomes pointless

**Limitation:**
- Only works if user configures high-threshold recovery
- Not enabled by default (usability trade-off)
- Attacker with resources could coerce all guardians

**See:** [Coercion Resistance](coercion.md)

---

#### 2. User Forgets Memory Inputs

**Threat:**
- User forgets memory inputs
- Cannot regenerate key
- Data lost forever

**CQRIT Mitigation:**
- Social recovery (M-of-N guardians)
- User can reconstruct key with guardian assistance

**Limitation:**
- Only works if user configured recovery beforehand
- If no recovery configured, data unrecoverable

**See:** [Social Recovery](recovery.md)

---

#### 3. Device Compromise (Malware on User's Device)

**Threat:**
- User's device has malware
- Malware steals key from memory during use
- Or keylogger captures memory inputs

**CQRIT Mitigation (Partial):**
- Keys exist in memory only during use (short window)
- Secure memory wiping after use
- Browser sandbox limits malware access

**Limitation:**
- If device fully compromised, attacker can steal keys during active session
- No protection against keylogger capturing memory inputs
- Cannot protect against root-level malware

**Recommendation:**
Users should use trusted, malware-free devices.

---

#### 4. Phishing Attacks

**Threat:**
- Attacker creates fake CQRIT site
- User enters memory inputs
- Attacker steals inputs

**CQRIT Mitigation (Partial):**
- Users should verify URL (HTTPS, domain)
- Browser security warnings

**Limitation:**
- CQRIT cannot prevent user from using fake site
- User responsibility to verify authenticity

**Recommendation:**
Users should bookmark official site and verify HTTPS.

---

#### 5. Weak Memory Inputs (Low Entropy)

**Threat:**
- User chooses weak memory inputs (e.g., "password")
- Attacker brute forces

**CQRIT Mitigation (Partial):**
- High KDF iterations (slow down brute force)
- Entropy checking during setup (warn user)

**Limitation:**
- Cannot force user to choose strong inputs
- Brute force still possible if inputs weak enough

**Recommendation:**
Use multiple high-entropy memory inputs.

---

### ❌ No Protection (Out of Scope)

#### 1. Compromised Browser/JavaScript Supply Chain

**Threat:**
- Browser itself is malicious
- Or CQRIT's JavaScript dependencies compromised

**CQRIT Protection:**
None. System assumes browser and libraries are trustworthy.

**Why Out of Scope:**
Cannot protect against compromised execution environment.

**Mitigation:**
- Use open-source code (auditable)
- SubResource Integrity (SRI) for CDN scripts
- Content Security Policy (CSP)

---

#### 2. Evil Maid Attack (Physical Device Access)

**Threat:**
- Attacker has physical access to user's device (unlocked)
- Extracts data or installs malware

**CQRIT Protection:**
None. Assumes device is physically secure.

**Why Out of Scope:**
Client-side encryption cannot protect against physical access to unlocked device.

**Mitigation:**
- User should lock device when unattended
- Full-disk encryption
- Hardware security modules (future)

---

#### 3. Side-Channel Attacks

**Threat:**
- Attacker uses timing, power analysis, or EM radiation
- Extracts cryptographic keys

**CQRIT Protection:**
Minimal. Browser environment not designed for side-channel resistance.

**Why Out of Scope:**
Web platform lacks constant-time guarantees.

**Mitigation:**
- Rust may have some constant-time operations
- Mobile apps could use hardware enclaves (future)

---

#### 4. Rubber-Hose Cryptanalysis (Torture)

**Threat:**
- Attacker tortures user until they reveal memory inputs

**CQRIT Protection:**
None, unless high-threshold recovery configured (see Coercion Resistance).

**Why Out of Scope:**
Cannot protect user from physical harm.

**Mitigation:**
- High-threshold social recovery makes torture pointless (user cannot decrypt alone)

---

#### 5. Zero-Day Exploits in Cryptographic Libraries

**Threat:**
- Unknown vulnerability in CRYSTALS-Kyber, AES, KDF, etc.
- Attacker exploits before patch

**CQRIT Protection:**
None. Relies on library correctness.

**Why Out of Scope:**
All systems rely on underlying crypto correctness.

**Mitigation:**
- Use NIST-approved algorithms
- Monitor CVEs and patch quickly
- Use multiple layers (hybrid crypto)

---

#### 6. Government Backdoors in Algorithms

**Threat:**
- NIST/NSA backdoored CRYSTALS-Kyber (conspiracy theory)
- Attacker uses backdoor to decrypt

**CQRIT Protection:**
None. Trusts NIST selection process.

**Why Out of Scope:**
If government backdoors standard algorithms, all systems using them are compromised.

**Mitigation:**
- CRYSTALS-Kyber is open-source (auditable)
- Community review (no backdoors found)
- Hybrid crypto (classical + post-quantum) provides defense-in-depth

---

#### 7. User Voluntarily Shares Data

**Threat:**
- User decrypts data and shares plaintext with attacker

**CQRIT Protection:**
None. User choice.

**Why Out of Scope:**
Encryption protects at rest, not user decisions.

**Mitigation:**
None. User controls their data.

---

## Adversary Profiles

### Adversary 1: Script Kiddie

**Capabilities:**
- Uses automated tools
- Scans for common vulnerabilities

**CQRIT Defense:**
✅ Strong. No server-side keys to exploit. Encrypted data useless without brute-forcing.

---

### Adversary 2: Cybercriminal

**Capabilities:**
- Sophisticated tools
- Can exploit software vulnerabilities
- May use phishing, malware

**CQRIT Defense:**
✅ Partial. Client-side encryption protects data. Malware on user device can steal keys during use. Phishing can steal memory inputs.

**Mitigations:** User education, secure device practices.

---

### Adversary 3: Nation-State

**Capabilities:**
- Zero-day exploits
- Quantum computers (future)
- Coercion / legal compulsion
- Supply chain attacks

**CQRIT Defense:**
⚠️ Mixed.
- ✅ Quantum resistance (CRYSTALS-Kyber)
- ⚠️ Zero-days may compromise browser/WASM
- ⚠️ Coercion mitigated by high-threshold recovery (if configured)
- ❌ Supply chain compromise out of scope

**Mitigations:** High-threshold recovery for coercion. Open-source code for auditability.

---

### Adversary 4: Insider Threat (CQRIT Employee)

**Capabilities:**
- Access to CQRIT server/database
- Can modify code (if malicious)

**CQRIT Defense:**
✅ Strong against data theft. All data encrypted client-side. Employee cannot decrypt.
❌ Weak against code modification. Malicious employee could inject backdoor.

**Mitigations:**
- Open-source code (community review)
- Code signing
- Reproducible builds

---

### Adversary 5: Kidnapper / Coercive Attacker

**Capabilities:**
- Physical control over user
- Torture, threats
- Can force user to cooperate

**CQRIT Defense:**
⚠️ Conditional. If user configures high-threshold recovery (e.g., 10-of-10), coercion becomes pointless (user cannot decrypt alone).

**Mitigations:** See [Coercion Resistance](coercion.md).

---

## Attack Scenarios

### Scenario 1: Database Breach

**Attack:**
1. Attacker breaches CQRIT server
2. Downloads entire database
3. Attempts to decrypt user data

**Outcome:**
- ✅ Data remains encrypted (keys never on server)
- Attacker has ciphertext only
- Must brute-force each user's memory inputs (infeasible if high entropy)

**CQRIT Success:** ✅

---

### Scenario 2: Quantum Computer in 2035

**Attack:**
1. Attacker has working quantum computer
2. Attempts to break CQRIT encryption
3. Uses Shor's algorithm on key exchange

**Outcome:**
- ✅ CRYSTALS-Kyber resists Shor's algorithm
- Symmetric encryption (AES-256) already quantum-resistant (Grover's algorithm only halves key strength to 128-bit, still secure)
- Data remains encrypted

**CQRIT Success:** ✅

---

### Scenario 3: Malware on User's Device

**Attack:**
1. User downloads malware
2. Malware runs during CQRIT session
3. Steals key from memory

**Outcome:**
- ⚠️ Current session compromised
- Attacker can decrypt data user accessed during that session
- Stored encrypted data safe (if user not using it)

**CQRIT Success:** ⚠️ Partial (damage limited to active session)

---

### Scenario 4: Phishing Attack

**Attack:**
1. Attacker creates fake CQRIT site
2. User enters memory inputs
3. Attacker steals inputs

**Outcome:**
- ❌ User's key compromised
- Attacker can decrypt user's data

**CQRIT Success:** ❌ (user error, not system flaw)

**Mitigation:** User must verify URL.

---

### Scenario 5: Coercion (Without High-Threshold Recovery)

**Attack:**
1. Attacker kidnaps user
2. Demands decryption
3. User reveals memory inputs

**Outcome:**
- ❌ Attacker decrypts data

**CQRIT Success:** ❌ (unless high-threshold recovery configured)

---

### Scenario 6: Coercion (With 10-of-10 Recovery)

**Attack:**
1. Attacker kidnaps user
2. Demands decryption
3. User reveals memory inputs but cannot access guardians

**Outcome:**
- ✅ User cannot decrypt alone (needs all 10 guardians)
- Attacker must coerce 10 people in 10 countries (infeasible)
- Data remains encrypted

**CQRIT Success:** ✅ (with proper configuration)

---

### Scenario 7: Man-in-the-Middle (MITM) on Network

**Attack:**
1. Attacker intercepts HTTPS traffic
2. Attempts to modify encrypted data
3. Or inject malicious code

**Outcome:**
- ✅ HTTPS prevents MITM
- Even if HTTPS broken, encrypted data has authentication tag (GCM)
- Tampering detected, decryption fails

**CQRIT Success:** ✅

---

### Scenario 8: Supply Chain Attack (Compromised Dependency)

**Attack:**
1. Attacker compromises npm package used by CQRIT
2. Injects backdoor
3. Steals keys during execution

**Outcome:**
- ❌ If undetected, backdoor can steal keys

**CQRIT Success:** ❌

**Mitigations:**
- SubResource Integrity (SRI)
- Dependency pinning
- Security audits
- Open-source review

---

## Security Properties Summary

| Property | CQRIT Provides | Notes |
|----------|----------------|-------|
| Confidentiality | ✅ Yes | Data encrypted, keys never stored |
| Integrity | ✅ Yes | AEAD (GCM) detects tampering |
| Availability | ⚠️ Conditional | If user forgets inputs, data lost (unless recovery configured) |
| Authentication | ✅ Yes | User must know memory inputs |
| Non-repudiation | ❌ No | User can deny creating data (plausible deniability) |
| Quantum Resistance | ✅ Yes | CRYSTALS-Kyber + PQXDH |
| Coercion Resistance | ⚠️ Conditional | Only with high-threshold recovery |
| Forward Secrecy | ✅ Yes | Past sessions safe if current session compromised (key not persistent) |
| Anonymity | ⚠️ Partial | CQRIT doesn't link data to identity, but network metadata may |

---

## Compliance and Standards

### Cryptographic Standards

**CQRIT Uses:**
- NIST-approved algorithms:
  - AES-256-GCM (FIPS 197)
  - SHA-256 (FIPS 180-4)
  - CRYSTALS-Kyber (NIST PQC winner)
- Industry-standard KDF (Argon2id or PBKDF2)

**Compliance:**
- ✅ Meets modern cryptographic best practices
- ✅ FIPS 140-2 algorithms (AES, SHA-256)
- ✅ NIST post-quantum recommendation (CRYSTALS-Kyber)

### Privacy Regulations

**GDPR (EU):**
- ✅ Client-side encryption supports data minimization
- ✅ Zero-knowledge architecture supports privacy by design
- ⚠️ Data recovery requires user (or guardians) cooperation

**CCPA (California):**
- ✅ User control over data (can delete)
- ✅ No sharing of plaintext with third parties

**HIPAA (Healthcare, USA):**
- ✅ Encryption at rest and in transit
- ⚠️ Requires access controls (CQRIT provides via memory inputs)
- ⚠️ Audit trail not built in (future feature)

---

## Risk Assessment

### High Risk (Must Address)

🔴 **User Forgets Memory Inputs (Without Recovery):**
- Impact: Data lost forever
- Mitigation: Encourage social recovery setup

🔴 **Weak Memory Inputs:**
- Impact: Brute-forceable
- Mitigation: Entropy checking, user education

### Medium Risk (Monitor)

🟡 **Device Malware:**
- Impact: Current session compromised
- Mitigation: User device security practices

🟡 **Phishing:**
- Impact: User-specific compromise
- Mitigation: User education, HTTPS verification

### Low Risk (Acceptable)

🟢 **Server Breach:**
- Impact: None (data encrypted)
- Mitigation: Already mitigated by design

🟢 **Quantum Computers (Future):**
- Impact: None (post-quantum crypto)
- Mitigation: Already mitigated by design

---

## Future Threat Considerations

### 1. Quantum Computers (>2030)

**Status:** Mitigated (CRYSTALS-Kyber).

**Monitor:** NIST PQC standardization updates.

---

### 2. AI-Powered Cryptanalysis

**Status:** Unknown.

**Monitor:** Research on AI breaking KDFs or finding patterns in ciphertext.

---

### 3. Browser Exploitation

**Status:** Ongoing risk.

**Monitor:** CVEs in browsers, WebAssembly, Web Crypto API.

---

### 4. Side-Channel Attacks on Web Platform

**Status:** Minimal protection.

**Future:** Hardware security modules, Trusted Execution Environments (TEE).

---

## Recommendations

### For Users

✅ **Use strong memory inputs** (multiple, high-entropy)
✅ **Set up social recovery** (for important data)
✅ **Use trusted devices** (malware-free)
✅ **Verify CQRIT URL** (HTTPS, official domain)
✅ **Configure high-threshold recovery** (if coercion risk)

### For Developers

✅ **Keep dependencies updated** (patch CVEs)
✅ **Audit cryptographic code** (third-party review)
✅ **Use SubResource Integrity** (SRI for CDN)
✅ **Implement Content Security Policy** (CSP)
✅ **Monitor NIST PQC updates** (future algorithm changes)

---

**See Also:**
- [Cryptography Details](crypto.md)
- [Key Management](key-management.md)
- [Social Recovery](recovery.md)
- [Coercion Resistance](coercion.md)