Blind Replica Defence-in-Depth

Document version

Version 1.0.0 — 2026-02-09

Executive Summary

The blind replica is the disaster recovery root of the VardKista ecosystem. It is the only component that holds the complete encrypted history for all sync groups belonging to a user, with retention measured in years rather than hours. This makes it the single highest-value target in the system and the component where long-horizon threats — particularly harvest-now-decrypt-later quantum attacks — are not theoretical but operationally concrete.

This document specifies a three-ring defence-in-depth model where each ring is cryptographically independent. An attacker must defeat all three rings to access plaintext. Compromising any single ring — or even two — yields only ciphertext protected by the remaining ring(s). No ring shares key material, algorithms, or trust assumptions with any other.

Why the Blind Replica Exists

The VardKista device hierarchy positions the desktop as the operational vault holding all six drawer sync groups. Mobile devices hold one drawer each on the free tier, or the full filing cabinet for sync subscribers (each app contains all six tables, populated via cross-app sync through the relay). Recovery flows downward: a lost phone re-pairs from the desktop. But if the desktop is also lost — fire, theft, hardware failure — the user loses everything.

The blind replica eliminates that risk. It is architecturally identical to the ephemeral sync relay (same codebase, same zero-knowledge properties, confirmed across both security audits) but with TTL disabled. It receives the same encrypted blobs as every other device in each sync group, stores them indefinitely, and serves them back on demand. It holds no keys and can decrypt nothing.

When the user provisions a new desktop, they pair it with the blind replica. The desktop pulls the complete encrypted archive, decrypts it locally using the GroupSecrets derived from the user’s passphrase, and resumes normal operation as the vault. Phones then re-pair from the desktop as usual.

The user’s only responsibility is their passphrase. No seed phrases, no iCloud backup, no Google account, no recovery email. The filing cabinet metaphor made real: the blind replica is the fireproof safe in the basement that holds copies of everything.

The Three-Ring Model

Each ring provides an independent cryptographic barrier. They use different algorithms, different keys, and protect against different threat classes.

Ring 1 — Application-Layer End-to-End Encryption

What it is: Every blob stored on the blind replica is encrypted with XChaCha20-Poly1305 before it leaves the client device. The encryption key is derived from the user’s GroupSecret via HKDF-SHA256 with domain-separated info strings. The GroupSecret itself is derived from the user’s passphrase via Argon2id with a per-group random 16-byte salt (F-001 fix confirmed in audit v2). The blind replica has zero cryptographic dependencies and cannot derive, compute, or store any key material.

What it protects against: Complete server compromise. Even an attacker with root access to the blind replica, its database, its backups, and its entire operational history sees only opaque encrypted blobs. This was verified at HIGH confidence across both security audits (XC-004, SR-006, CL-003). The relay crate’s Cargo.toml contains no encryption libraries — this is an architectural guarantee, not a policy one.

Quantum resistance: XChaCha20 is a symmetric cipher. Grover’s algorithm reduces the effective key strength from 256 bits to 128 bits. A 128-bit symmetric key remains computationally infeasible for any known or projected quantum computer. Ring 1 is inherently quantum-resistant without modification.

Key independence: The encryption key derives from the user’s passphrase, which never touches the blind replica. Even if Rings 2 and 3 are completely defeated, Ring 1 holds.

Ring 2 — Hybrid Post-Quantum Transport Encryption

What it is: All communication between client devices and the blind replica uses a Noise XX handshake providing mutual authentication and forward secrecy. The hybrid construction combines ML-KEM-768 (NIST-standardised lattice-based KEM, designed to resist quantum attack) with X25519 (classical elliptic curve Diffie-Hellman). Both key exchanges must be broken to derive the session key. Implemented via the clatter crate (v2.2) for hybrid Noise patterns.

What it protects against: Harvest-now-decrypt-later attacks on network traffic. An adversary who captures all wire traffic between clients and the blind replica today cannot decrypt it with a future quantum computer because the key exchange is hybrid PQ. This is the ring specifically designed for the Class 4 (nation-state / quantum) adversary.

Quantum resistance: An attacker must break both ML-KEM-768 (lattice-based, NIST PQC standard) and X25519 (classical ECDH). Breaking only one yields nothing — the session key is derived from both. This is the NIST-recommended hybrid approach for the transition period.

Current implementation status: The clatter dependency is declared (v2.2) but not yet integrated into the codebase (audit finding F-002). iroh’s QUIC transport provides classical TLS 1.3 encryption in the interim. Ring 2 integration is the highest-priority pre-GA security item, elevated from “important” to “critical” by the blind replica’s long-term retention model.

Key independence: Session keys are ephemeral, derived from the Noise handshake. They share no material with Ring 1’s GroupSecret or Ring 3’s volume key. Compromising Ring 2 reveals transport-level data (which is Ring 1 ciphertext), not plaintext.

Ring 3 — Hybrid Post-Quantum Volume Encryption

What it is: The blind replica’s storage volume (SQLite database and any associated blob files) is encrypted at rest with a volume key derived from a hybrid PQ key exchange. The volume encryption key is generated during initial blind replica provisioning and wrapped twice: once with ML-KEM-768 and once with X25519. Decryption requires unwrapping both. The wrapped key copies are stored separately from the encrypted volume.

Implementation options (in order of preference):

1. SQLCipher with hybrid-derived key. SQLCipher provides transparent AES-256-CBC encryption of the SQLite database. The encryption key is derived from a hybrid KEM ceremony performed during provisioning. This keeps the encryption within the Rust/SQLite stack and avoids OS-level dependencies. The hybrid KEM output feeds into HKDF to produce the SQLCipher key.

2. LUKS2 with hybrid key wrapping. Linux dm-crypt/LUKS2 encrypts the entire block device. The volume master key is wrapped with both ML-KEM-768 and X25519 derived keys, stored as separate LUKS key slots. Requires Linux and kernel-level integration but provides protection below the application layer.

What it protects against: Physical disk seizure, hosting provider data disclosure (voluntary or compelled), offline forensic imaging, and backup exfiltration. An attacker who obtains the raw disk, a database dump, or a Litestream replica sees encrypted storage that requires a hybrid PQ key to unlock.

Quantum resistance: Same hybrid model as Ring 2. Both ML-KEM-768 and X25519 must be broken to derive the volume key.

Key independence: The volume key is generated independently during blind replica provisioning. It has no relationship to Ring 1’s GroupSecret or Ring 2’s transport session keys. It is not derived from any user passphrase. Even if an attacker knows every user’s passphrase (breaking Ring 1) and has captured all transport traffic (breaking Ring 2), they still cannot read the volume without the volume key.

Adversary Analysis

This section maps each adversary class to the rings they must defeat.

Class 1 — Opportunistic attacker (script kiddie, automated scanner). Cannot breach any ring. Stopped by standard infrastructure hardening (Cloudflare, rate limiting, SSH key auth). The blind replica is not directly addressable from the public internet; it connects to sync groups as a client device behind Cloudflare Tunnel.

Class 2 — Targeted attacker (motivated individual, small group). May attempt to compromise the blind replica server via phishing, credential theft, or exploiting a vulnerability. If they achieve server access, they encounter Ring 3 (encrypted volume). If they somehow obtain the volume key, they encounter Ring 1 (E2E encrypted blobs with no key material on the server). Practical outcome: two independent barriers, both beyond typical capability.

Class 3 — Institutional attacker (corporation, law enforcement, intelligence agency). Can compel the hosting provider to hand over disk images, database backups, and network traffic. This is the design scenario for all three rings working together:

• Disk images / database backups → Ring 3 blocks. Encrypted volume, hybrid PQ key required.
• Network traffic capture → Ring 2 blocks. Hybrid PQ transport, forward secrecy means past sessions are unrecoverable even with server private key compromise.
• Server access with running process → Ring 3 may be open (volume is mounted). Ring 1 still blocks. Blobs are opaque ciphertext. No key material exists on the server.

Worst case for Class 3: they access the running server (Ring 3 open) and capture the database of encrypted blobs. They then need to break Ring 1, which requires the user’s passphrase and Argon2id parameters. Targeted brute-force against a specific user’s passphrase is possible if the passphrase is weak, slowed by Argon2id memory-hardness (19-64 MiB, device-adaptive).

Class 4 — Nation-state / quantum adversary. The 10-30 year threat horizon. This adversary captures everything today and waits for quantum computing capability.

• Captured encrypted volume → must break hybrid PQ (ML-KEM-768 + X25519) to decrypt. ML-KEM-768 is NIST-standardised specifically to resist this.
• Captured network traffic → must break hybrid PQ transport. Same resistance.
• Captured Ring 1 blobs (after defeating Rings 2 and 3) → must break XChaCha20-Poly1305 (128-bit effective under Grover’s). Computationally infeasible even for quantum.

This adversary faces three sequential quantum-resistant barriers. Two are hybrid PQ by design. One is inherently quantum-resistant by the properties of symmetric cryptography. There is no single cryptographic break that unravels the stack.

Recovery Flow

The blind replica enables a complete disaster recovery path without seed phrases, cloud accounts, or recovery emails.

Scenario: All devices lost.

1. User acquires a new desktop.
2. User installs VardKista.
3. User enters their passphrase (the only thing they need to remember).
4. VardKista connects to the blind replica and initiates a recovery pairing.
5. The blind replica serves the complete encrypted blob history for all sync groups.
6. The desktop decrypts locally using GroupSecrets derived from the passphrase via Argon2id.
7. The desktop rebuilds its local SQLite databases from the decrypted blobs.
8. The desktop resumes operation as the vault.
9. User installs individual apps on new phones, pairs each from the desktop via QR.

On the free tier, each phone receives only its own drawer’s data — compartmentalisation preserved during recovery. For sync subscribers, cross-app sync repopulates all tables in each app after the desktop vault is restored.

Scenario: Desktop lost, phones intact.

1. User acquires a new desktop.
2. User pairs the new desktop with the blind replica (passphrase).
3. Desktop pulls complete archive, decrypts, rebuilds.
4. User re-pairs phones from new desktop (QR for each app).
5. Phones continue operating normally during this process — they sync through the ephemeral relay independently.

Scenario: Phone lost.

1. User installs the specific app on a new phone.
2. User scans QR from the desktop vault.
3. New phone pulls that drawer’s data through normal sync.
4. No blind replica involvement required.

Operational Considerations

Blind replica hosting. The blind replica should be hosted on infrastructure geographically separated from the user’s primary devices. The blind replica runs as a standard sync-relay Docker container with modified TTL configuration — no special software required.

Passphrase as single point of recovery. The user’s passphrase is the only secret required to recover from total device loss. This is simultaneously the system’s greatest UX strength (nothing to write down, nothing to store separately) and its critical vulnerability. If the passphrase is forgotten, data on the blind replica is irrecoverable by design. Users should be clearly informed of this during onboarding.

OPRF as future enhancement. The OPRF research (opaque-ke crate, RFC 9807, WhatsApp-proven) can optionally harden passphrase-based recovery against offline brute-force by requiring relay cooperation for each guess attempt. This adds a trust dependency on the relay but eliminates offline dictionary attacks. Recommended as an optional enterprise-tier enhancement, not a replacement for the default Argon2id-only flow.

Monitoring and alerting. The blind replica should emit metrics on blob ingestion rate, storage growth, and connection patterns. Anomalous activity (sudden spike in connections, unexpected pull requests, connection from new IP ranges) should trigger alerts. The blind replica sees only metadata, so monitoring does not compromise zero-knowledge properties.

Remaining Pre-GA Security Work

Ordered by impact on blind replica security:

1. Integrate clatter (Ring 2). Done. The hybrid PQ transport (ML-KEM-768 + X25519 via clatter) is implemented, protecting the blind replica against harvest-now-decrypt-later attacks on long-term stored data. Audit finding F-002 resolved.

2. Implement Ring 3 volume encryption. SQLCipher with hybrid-derived key for the blind replica’s SQLite database. This protects against physical seizure and hosting provider compulsion. Not yet implemented.

3. Wire global rate limiter (SR-001). The rate limiter is implemented and tested but not connected to the request path. A DDoS against the blind replica could cause availability loss during a recovery attempt.

4. Implement device revocation (CL-001). A compromised device that retains membership in a sync group can continue pulling data from the blind replica indefinitely. Revocation is a policy gap, not a cryptographic one, but matters for the blind replica’s long-term exposure.

5. Extend Zeroize coverage (XC-001). Root secret types (GroupSecret, GroupKey, NoiseKeypair) are zeroized on drop. Remaining gaps: derived per-blob content keys, NoiseSession CipherState, and FFI-crossing copies. Local risk, not a blind replica risk, but affects the overall chain of custody.

Future Ring: Confidential Computing (TEE)

A fourth ring using hardware-encrypted memory (AMD SEV-SNP, Intel TDX, or ARM CCA) would protect the blind replica’s runtime memory from hypervisor-level attacks. The relay process would run in a Trusted Execution Environment where even the hosting provider’s infrastructure administrators cannot inspect process memory.

This ring is architecturally ready — the blind replica’s zero-dependency design means it runs identically inside or outside a TEE. Current TEE limitations (memory constraints, attestation complexity, limited availability on commodity hosting) make this impractical today. The model is designed so Ring 4 slots in around Rings 1-3 without modification when hardware matures.

Summary

The blind replica defence-in-depth model provides three independent cryptographic barriers protecting the highest-value component in the VardKista ecosystem. Ring 1 (application-layer E2E) is implemented and audited. Ring 2 (hybrid PQ transport) and Ring 3 (hybrid PQ volume encryption) are specified and use production-ready Rust crates. All three rings are quantum-resistant — two by hybrid PQ design, one by the inherent properties of symmetric cryptography.

No single point of failure — cryptographic, infrastructural, or operational — can expose plaintext data. This is not defence-in-depth by policy. It is defence-in-depth by architecture.