Security & Privacy Disclosures

1. Server-Managed Vault (Not End-to-End Encrypted / Not Zero-Knowledge)

In an End-to-End Encrypted (E2EE) or Zero-Knowledge architecture, only the client device holds decryption keys, and the server never encounters plaintext under any condition.

CipherQ is different: To enable streaming file transfers, text extraction, FTS5 keyword indexing, and local on-device AI document question answering without forcing the user's browser to execute heavyweight LLMs, the CipherQ backend must decrypt authorized document content into volatile server RAM. Therefore, CipherQ operates as a Server-Managed Encrypted Vault:

• Each file is encrypted with an independent 256-bit Data Encryption Key (DEK).
• The server holds the Master Key Encryption Key (KEK) at keys/.vault_master.key (file permissions enforced to 0600 on POSIX).
• Authorized users request file operations through the authenticated API; the server loads the master key, unwraps the file's DEK, and streams or decrypts content into volatile memory.
• Anyone with physical hardware access or root privileges on the server host can theoretically inspect memory or read key files. CipherQ protects against external network eavesdropping and cross-user leaks, not host OS compromise.

2. Cryptographic Algorithms & Key Management

CipherQ adheres strictly to standard, peer-reviewed cryptographic primitives and avoids proprietary or unverified encryption schemes:

• File Content Encryption: Streaming authenticated encryption using libsodium's crypto_secretstream_xchacha20poly1305 (PyNaCl) in 64 KB blocks. Provides mathematical guarantees against bit-flipping, ciphertext modification, chunk reordering, and truncation attacks.
• Key Wrapping (Envelope Encryption): The 256-bit per-file DEK is wrapped under the server's 256-bit Master KEK using AES-256-GCM with a fresh 12-byte cryptographic nonce and authenticated associated data.
• Key Storage: The master key resides on the local filesystem at keys/.vault_master.key. The application verifies file permissions at startup and executes an in-memory AEAD self-test before accepting requests.
• Key Backup: Master key backups are encrypted into an authenticated container using AES-256-GCM with keys derived via Argon2id (time_cost=3, memory_cost=65536, parallelism=4).
• Integrity Checksums: SHA-256 checksums are calculated during streaming upload and recorded in the database, allowing end-to-end integrity verification upon download.

3. Plaintext Memory & Flash Storage Erasure Limits

We explicitly do not promise 100% forensic data erasure:

• Volatile Memory (RAM): During file download streaming, file contents pass through 64 KB memory buffers. During document indexing, extracted text chunks are parsed in memory. While file handles are closed and dereferenced promptly, in high-level managed runtimes (Python), memory garbage collection and OS paging mean memory fragments cannot be forensically zeroed without OS-level mlock controls.
• Flash Storage (eMMC): File deletion invokes filesystem unlinking (os.remove). Because NAND flash memory uses a Flash Translation Layer (FTL) with wear-leveling algorithms, physically erased sectors may retain traces of ciphertext until overwritten by subsequent operations. Full physical protection against chip removal requires OS-level Full Disk Encryption (such as Linux LUKS).

4. User Authentication & Multi-Tenant Isolation

Account security is enforced by modern cryptographic standards and database-level tenancy controls:

• Password Hashing: Passwords are hashed with Argon2id using recommended parameters (64 MB memory cost, 3 iterations, 4 parallel threads, 32-byte salt). Plaintext passwords are never logged or stored. Constant-time verification prevents timing attacks.
• Session Security: Sessions use 256-bit cryptographically secure random tokens. The database stores only SHA-256 hashes of session tokens, preventing session hijack if database backups are inspected. Sessions expire after 24 hours.
• Rate Limiting: In-memory sliding window rate limiters restrict authentication endpoints (5 login attempts / minute; 3 registration attempts / minute per IP) to mitigate brute-force attacks.
• Tenant Isolation: Multi-tenant isolation is enforced at the database query layer. Every file, chunk, embedding, and search index query requires an explicit WHERE user_id = :user_id filter. Users cannot read, search, or delete another user's documents.

5. Local AI Inference & Zero Cloud API Transmission

All search and AI processing occurs strictly on the local computing environment:

• Keyword Search: Performed directly inside the host SQLite database using the FTS5 full-text engine with BM25 ranking.
• Vector Embeddings: Generated locally using LocalEmbeddingEngine with subword feature hashing or local ONNX models. External library telemetry is explicitly disabled (HF_HUB_OFFLINE=1, ONNXRUNTIME_TELEMETRY_DISABLED=1).
• Model Inference: Handled by a local quantized Gemma service running on the host machine loopback interface (http://127.0.0.1:8081). The backend strictly validates that model URLs resolve only to loopback addresses (127.0.0.1, localhost, ::1) on port 8081; non-loopback destinations are programmatically rejected.
• Grounded Citations: Retrieved document excerpts are passed directly to the model as untrusted data context with strict system instructions prohibiting fabrication. If insufficient evidence exists, the system returns an explicit notice.

6. Network Transport, Logs & Metadata Exposure

Operators and users must understand the boundaries of network communication and metadata logging:

• LAN Plain HTTP Risk: Running CipherQ over plain HTTP on a local network (e.g. http://192.168.1.50:8000) provides zero transport encryption. Eavesdroppers on the same Wi-Fi or Ethernet network could intercept session cookies and file streams. Deployments accessible outside localhost must configure TLS/HTTPS (e.g., via Nginx reverse proxy with valid certificates or private VPNs like Tailscale).
• Stored Metadata: While file contents are encrypted, metadata (original filenames, file sizes, MIME types, and upload timestamps) is stored in plaintext in the SQLite database to support file management and quota enforcement.
• Application Logging: Server logs record HTTP request paths, HTTP response status codes, client IP addresses, and error stack traces. Document content, plaintext keys, and passwords are never logged.

7. Threat Assumptions & Explicit Out-of-Scope Risks

Security engineering requires defining explicit threat assumptions: