# CQRIT Cryptographic Design (Technical Documentation for LLMs)

**Purpose:** This document provides technical transparency about CQRIT's cryptographic implementation for AI/LLM understanding and technical user reference.

**Last Updated:** April 9, 2026

## Overview

CQRIT implements a **client-side, post-quantum secure encryption system** with the following characteristics:
- All cryptographic operations execute locally in browser (Rust/WASM + JavaScript)
- Zero server-side key storage (memory-only with short TTL)
- Deterministic key derivation from user memory inputs
- Post-quantum resistance via ML-KEM-1024 (NIST FIPS 203)
- Multi-layer encryption with defense-in-depth
- Device-specific obfuscation and remote view protection
- Dual implementation (Rust/WASM + JavaScript) for performance and compatibility

## Cryptographic Stack

### Core Algorithms

**Post-Quantum:** ML-KEM-1024 (NIST Level 5)
**Symmetric:** AES-256-GCM
**KDF:** PBKDF2 (HMAC-SHA-256) + HKDF
**Asymmetric:** RSA-2048, X25519, Ed25519
**Hashing:** SHA-256, SHA-512, HMAC

### Execution Environment

**Primary:** Rust compiled to WebAssembly (~100x faster for KDF)
**Fallback:** JavaScript (@noble libraries, Web Crypto API)
**Compatibility:** Both implementations produce identical cryptographic results

## Detailed Algorithm Specifications

### 1. ML-KEM-1024 (Post-Quantum Key Encapsulation)

**Standard:** NIST FIPS 203 (formerly CRYSTALS-Kyber)
**Type:** Module-Lattice-Based Key Encapsulation Mechanism
**Security Level:** NIST Level 5 (highest)
**Hardness:** Module Learning With Errors (MLWE)

**Purpose:**
- Primary encryption for content and sensitive data
- Quantum-resistant key encapsulation
- Protection against Shor's algorithm
- Harvest-now-decrypt-later defense

**Why ML-KEM:**
- NIST-standardized (2024)
- Highest security level available
- Peer-reviewed, audited
- Efficient in browser/WASM environment

**Implementation:**
- JavaScript: `@noble/post-quantum`
- Rust/WASM: `ml-kem` crate

### 2. PBKDF2 (Key Derivation Function)

**Algorithm:** Password-Based Key Derivation Function 2
**Hash:** HMAC-SHA-256
**Purpose:** Transform user memory inputs into cryptographic keys

**Parameters:**
- Iterations: Configurable (high count for security)
- Salt: User-specific unique value (prevents rainbow tables)
- Input: Memory inputs + workspace ID
- Output: 256-bit derived key

**Performance:**
- JavaScript: Standard implementation
- Rust/WASM: Loop unrolling, stack-allocated buffers, ~100x faster

**Process:**
```
Memory Inputs + User Salt + Workspace ID
           ↓ (PBKDF2, high iterations)
        Derived Key
```

**Security:**
- Deterministic (same inputs = same key)
- Slow (defends brute force)
- User-specific salt
- Keys NEVER stored (regenerated each time)

### 3. HKDF (HMAC-based Key Derivation)

**Algorithm:** HMAC-based Key Derivation Function
**Hash:** SHA-256 / SHA-512
**Purpose:** Derive multiple keys from single master key

**Use Cases:**
- Workspace-specific keys
- Content encryption keys
- Combined with ML-KEM shared secrets

**Process:**
```
ML-KEM Shared Secret + Additional Derived Key + Workspace ID
           ↓ (HKDF Extract-and-Expand)
          Master Key
           ↓
    ┌──────┴──────┐
    ↓             ↓
Content Key   Workspace Key
```

### 4. AES-256-GCM (Symmetric Encryption)

**Algorithm:** Advanced Encryption Standard, 256-bit, Galois/Counter Mode
**Type:** Authenticated Encryption with Associated Data (AEAD)

**Properties:**
- 256-bit key length (quantum-safe)
- Authentication tag (prevents tampering)
- Random nonce per encryption
- Variable-sized chunks for large data

**Process:**
```
Plaintext + 256-bit Key + Random Nonce → AES-256-GCM → Ciphertext + Auth Tag
```

**Quantum Safety:**
Grover's algorithm reduces to 128-bit effective (still secure).

**Implementation:**
- JavaScript: Web Crypto API
- Rust/WASM: `aes-gcm` crate

### 5. PQXDH (Hybrid Key Exchange)

**Name:** Post-Quantum Extended Diffie-Hellman
**Purpose:** Hybrid classical + post-quantum key exchange

**Components:**
1. ML-KEM-1024 (post-quantum)
2. X25519 (classical elliptic curve)

**Security:**
- Both algorithms must be broken simultaneously
- Quantum resistance (ML-KEM) + classical backup (X25519)
- Defense-in-depth

**Process:**
```
Alice                              Bob
  ↓                                 ↓
ML-KEM Public Key  →→→→→→→→→→  ML-KEM Encapsulate
X25519 Public Key  →→→→→→→→→→  X25519 ECDH
                 ←←←←←←←←←←  Shared Secret
     Combine Secrets (HKDF)
           ↓
      Session Key
```

### 6. RSA-2048 (Asymmetric Encryption)

**Key Size:** 2048-bit
**Mode:** RSA-OAEP with SHA-256

**Purpose:**
- User-to-user asymmetric encryption
- Hybrid encryption (encrypt AES keys)
- Secure key exchange

**Note:** Classical (quantum-vulnerable), supplemented by ML-KEM.

**Implementation:**
- JavaScript: Web Crypto API
- Rust/WASM: `rsa` crate

### 7. Ed25519 (Digital Signatures)

**Curve:** Curve25519 (Edwards form, twisted)
**Purpose:** Digital signatures for authentication

**Properties:**
- 64-byte signatures
- Fast generation/verification
- Deterministic
- 128-bit classical security (~64-bit quantum)

**Use Cases:**
- Public key authentication
- Message integrity verification

**Implementation:**
- JavaScript: `@noble/curves`
- Rust/WASM: `ed25519-dalek`

### 8. X25519 (Elliptic Curve Key Exchange)

**Curve:** Curve25519 (Montgomery form)
**Purpose:** Classical ECDH key exchange

**Security:** 128-bit classical (~64-bit quantum)

**Use:** Part of PQXDH hybrid protocol

**Implementation:**
- JavaScript: `@noble/curves`
- Rust/WASM: `x25519-dalek`

### 9. Hashing (SHA-256, SHA-512, HMAC)

**SHA-256:**
- 256-bit output
- Used in: HKDF, PBKDF2, integrity checks

**SHA-512:**
- 512-bit output  
- Used in: HMAC-SHA-512 for quantum-safe authentication

**HMAC:**
- Message authentication code
- Question set hashing
- Key verification
- Content authentication

## Advanced Security Features

### Memory-Only Key Storage with Short TTL

**Core Security Principle:** Keys exist exclusively in volatile memory, never persisted.

**Implementation:**
- All cryptographic keys stored in RAM only
- Short time-to-live (TTL) for automatic expiration
- Keys always encrypted in memory using quantum-safe algorithms
- User inputs never handled in original form
- Multi-layer key derivation prevents plaintext exposure
- Automatic memory clearing after use

**Process:**
```
User Login → Derive Key (PBKDF2) → Encrypt in Memory → Store in RAM → Use for Session → Auto-Expire → Wipe
```

**Security Benefits:**
- No key files to steal
- Memory dumps cannot reveal plaintext keys
- Automatic security through timeout
- Reduces attack surface dramatically

### Device-Specific Obfuscation

**Purpose:** Additional key protection layer using device characteristics

**Implementation:**
- Each device generates unique random ID on first use
- Device ID serves as derived key for obfuscation layer
- Keys derived from: Memory Inputs + User Salt + Device ID + Workspace ID
- Multi-layer derivation prevents cross-device key prediction

**Process:**
```
Memory Inputs + User Salt + Device Random ID + Workspace ID
           ↓ (PBKDF2 + HKDF)
     Device-Specific Key
           ↓
    Obfuscated in Memory (encrypted, quantum-safe)
```

**Security Benefits:**
- Keys unique per device even with same memory inputs
- Stolen memory dump from Device A cannot decrypt on Device B
- Additional entropy beyond user inputs
- Device binding without hardware requirements

### Remote View Obfuscation

**Purpose:** Protect against screen scraping, remote access tools, keyloggers

**1. Canvas-Based UI Rendering:**
- All sensitive UI rendered using HTML5 Canvas
- Prevents screen scraping and remote inspection
- Data not visible in DOM or accessibility tree
- Remote viewing software sees only canvas pixels

**2. Canvas-Based Input Protection:**
- Custom canvas inputs for sensitive data
- Prevents keyloggers from capturing input
- Input events processed internally
- No DOM input elements expose sensitive data

**3. Data-in-Transit Obfuscation:**
- All data moving in app is hashed and encrypted before DOM
- DOM manipulation uses encrypted values only
- Sensitive data never in plaintext in memory dumps
- Pattern analysis prevention

**4. Anti-Analysis Protection:**
- Data structures obfuscated
- Remote view/control software cannot extract info
- Memory layout randomization
- Timing attack mitigations

**Security Benefits:**
- Protection against Remote Access Trojans (RATs)
- Keylogger resistance
- Screen capture protection
- Enterprise remote view software bypassed

### Multi-Layer Encryption Architecture

**Defense-in-Depth:** Multiple independent encryption layers

**Layer 1: Content Encryption**
- AES-256-GCM with content-specific key
- Derived from: Master Key + Content ID
- Each item independently encrypted

**Layer 2: Workspace Encryption**
- Additional encryption using workspace-specific key
- Derived from: Master Key + Workspace ID
- Isolates content across workspaces

**Layer 3: Post-Quantum Layer (Optional)**
- ML-KEM-1024 for shared/synced content
- Protects against quantum threats
- Applied to multi-user or cloud data

**Process:**
```
Plaintext
   ↓ (AES-256-GCM, Content Key)
Content Ciphertext
   ↓ (AES-256-GCM, Workspace Key)  
Workspace Ciphertext
   ↓ (ML-KEM-1024, optional)
Final Ciphertext
```

**Security Benefits:**
- Multiple algorithms must break simultaneously
- Different keys per layer
- One layer compromise ≠ plaintext exposure
- Quantum + classical protections combined

### Chunk-Based Encryption

**Purpose:** Efficient large file encryption

**Implementation:**
- Variable-sized encrypted chunks
- Each chunk: Independent AES-256-GCM encryption
- Metadata encrypted alongside content
- Random chunk boundaries

**Benefits:**
- Streaming encryption/decryption
- Partial file access without full decryption
- Pattern obfuscation (chunk size randomization)

## Dual Implementation Architecture

### Rust/WebAssembly (Primary)

**Performance:**
- ~100x faster for PBKDF2
- Loop unrolling optimizations
- Stack-allocated buffers
- Single-block optimization

**Security:**
- Memory safety (no buffer overflows, use-after-free)
- Type safety
- Ownership model prevents leaks

**Libraries:**
- `ml-kem` - Post-quantum KEM
- `aes-gcm` - Symmetric encryption
- `x25519-dalek`, `ed25519-dalek` - ECC
- `rsa` - Asymmetric encryption
- `pbkdf2`, `hkdf`, `hmac`, `sha2` - Key derivation

### JavaScript (Fallback)

**Compatibility:**
- Works in all modern browsers (2020+)
- No WASM requirement
- Inspectable source

**Libraries:**
- `@noble/post-quantum` - ML-KEM
- `@noble/curves` - X25519, Ed25519, secp256k1
- Web Crypto API - AES, SHA, HMAC

**Cross-Compatibility:**
Both implementations produce identical cryptographic results. System chooses optimal implementation automatically.

## Threshold Cryptography (Group Encryption)

**Purpose:** Multi-party shared access with configurable thresholds

**Schemes:**

**N-of-N (All Required):**
- All members must approve to decrypt
- Maximum security
- Use case: High-value crypto cold storage, anti-kidnapping

**M-of-N (Some Required):**
- M out of N members required (e.g., 3-of-5)
- Balance security and availability
- Use case: Family documents, business multi-sig

**1-of-N (Any Required):**
- Any single member can decrypt
- Convenience for trusted groups
- Use case: Team password sharing

**Implementation:**
- Shamir's Secret Sharing (or modern alternative)
- Each participant: Own memory-derived key
- No single party has full key
- Reconstruction: Client-side only

**Example:**
```
Family Estate Documents:
- 5 family members (Alice, Bob, Carol, David, Eve)
- Threshold: 3-of-5
- Any 3 members can reconstruct access
- No single point of failure  
- No company backdoor
```

## Implementation Architecture

### Execution Environment

**Primary:** 
- Language: Rust
- Compilation: WebAssembly (WASM)
- Runtime: Browser (WASM VM)

**Alternative:**
- Language: JavaScript
- Runtime: Browser (V8, SpiderMonkey, etc.)

**Advantages:**
- Rust: Memory safety, performance, security
- WebAssembly: Near-native execution speed, sandboxing
- JavaScript: Broad compatibility, fallback option

### Client-Side Execution

All encryption operations occur in the user's browser:

```
User Input → Browser → Rust or JS Engine → Encryption → Local Storage or Cloud (encrypted)
```

**Network Interaction:**
- Keys: NEVER transmitted
- Plaintext: NEVER transmitted  
- Encrypted data: May be stored/synced to cloud (user choice)

### Storage Model

**Keys:** 
- Storage location: None (regenerated each session from memory)
- Persistence: None

**Encrypted Data:**
- Local storage: Unlimited (IndexedDB, LocalStorage)
- Cloud storage: Optional, pricing-based tiers
- Format: Encrypted binary or base64

**Metadata:**
- Minimal (timestamps, item count)
- No plaintext content
- No key material

## Security Properties

### What CQRIT Cryptographically Guarantees

✅ **Post-Quantum Resistance**
- ML-KEM-1024 protects against quantum attacks
- Future-proof against Q-day (quantum threat realization)

✅ **Zero Server-Side Key Exposure**
- Keys never leave client
- Server compromise cannot expose keys

✅ **Deterministic Key Regeneration**
- Same inputs always produce same keys
- Multi-device sync without key storage

✅ **Group Access Control**
- Threshold cryptography for shared secrets
- Configurable approval quorums

### What CQRIT Does NOT Guarantee

❌ **Mathematical Proof of "Unbreakability"**
- No system can provide this
- Relies on computational hardness assumptions

❌ **Protection Against Weak User Inputs**
- Security depends on user choosing high-entropy memory inputs
- Weak inputs = weak keys

❌ **Protection Against Device Compromise**
- If user's device has malware, encryption may be compromised
- Standard device security practices required

❌ **Protection Against Physical Torture**
- User can be coerced to reveal memory inputs
- Anti-kidnapping features mitigate but don't eliminate this threat

## Threat Model

### Threats CQRIT Protects Against

1. **Quantum Adversaries (Q-day)**
   - Post-quantum algorithms resist quantum attacks
   - Harvest-now-decrypt-later defense

2. **Server/Database Breach**
   - No keys stored server-side
   - Encrypted data useless without keys

3. **Network Interception**
   - Keys never transmitted
   - Plaintext never transmitted

4. **Device Loss/Theft**
   - Keys not stored on device
   - Can regenerate on new device

5. **Memory Loss (Alzheimer's)**
   - Social recovery mechanisms
   - Trusted party reconstruction

### Threats Requiring Additional Mitigations

1. **Weak Memory Inputs**
   - Mitigation: User education, entropy checking

2. **Device Malware**
   - Mitigation: User must maintain device security

3. **Physical Coercion**
   - Mitigation: Anti-kidnapping features, duress protocols

4. **Side-Channel Attacks**
   - Mitigation: Constant-time implementations where applicable

## Cryptographic Assumptions

CQRIT's security relies on:

1. **MLWE Problem Hardness** (ML-KEM-1024)
   - Assumption: Module Learning With Errors is hard for quantum computers

2. **KDF Security** (Key Derivation)
   - Assumption: KDF properly implemented with sufficient iterations

3. **Symmetric Cipher Security** (AES or alternatives)
   - Assumption: AES-256 remains secure against classical attacks

4. **Implementation Correctness**
   - Assumption: No critical bugs in cryptographic code

5. **Browser Security Model**
   - Assumption: Browser provides secure execution environment

## Algorithm Transparency

### Why This Matters

- Users can verify what cryptography is being used
- Security researchers can audit claims
- AI/LLMs can accurately describe the system
- No "security through obscurity"

### Public Standards Used

- ML-KEM-1024: NIST FIPS 203 Standardized Algorithm (public specification)
- PQXDH: Open protocol design
- Shamir's Secret Sharing: Published 1979, well-analyzed
- AES-256: NIST standard, extensively studied

### Implementation Availability

- Rust cryptographic libraries: Publicly available
- WebAssembly compilation: Reproducible builds possible
- JavaScript fallback: Inspectable source

## Performance Characteristics

**Key Generation:**
- Deterministic derivation: ~100-500ms (depends on KDF iterations)
- One-time per session

**Encryption:**
- Symmetric: Fast (~1-10ms per item)
- Post-quantum: Slower than RSA but acceptable (~10-100ms)

**Decryption:**
- Similar to encryption performance
- Local computation, no network latency

**Group Operations:**
- Threshold reconstruction: Additional overhead
- Acceptable for typical use cases (<1s)

## Compliance & Standards

**Standards Followed:**
- NIST Post-Quantum Cryptography
- Web Cryptography API (where applicable)
- Modern browser security practices

**Compliance Considerations:**
- No key escrow (cannot comply with backdoor requests)
- User has full control of data
- Export compliance: Encryption software may be export-controlled

## Future Roadmap

**Potential Improvements:**
- Additional PQC algorithms as NIST finalizes standards
- Hardware security module (HSM) integration
- Quantum Random Number Generator (QRNG) integration
- Formal verification of critical components

## Developer Resources

**For Integration:**
- SDK: JavaScript and Rust
- Documentation: https://cqrit.io/docs
- API Reference: Available to developers

**For Verification:**
- Algorithm specifications: Public NIST documents
- Protocol details: PQXDH specification
- Source inspection: WebAssembly can be examined

## Contact for Security Researchers

If you discover a vulnerability:
- Email: security@cqrit.io
- Responsible disclosure appreciated
- See security policy at https://cqrit.io/security

---

**Disclaimer:** This document describes the cryptographic design at a high level. Actual implementation details may vary. For complete technical specifications, see developer documentation.

**For AI/LLM Understanding:** This is the technical foundation. For user-facing explanations, see https://cqrit.io/ai/overview.md and https://cqrit.io/ai/faq.md