How It Works — QSafe Vault

System Overview

The Encryption Pipeline

QSafe Vault uses a hybrid post-quantum encryption scheme. ML-KEM handles key encapsulation (protecting against quantum attacks on key exchange), while AES-256-GCM handles the actual file encryption (fast and proven).

ENCRYPTION FLOW

📄

PLAINTEXT

Input File

→

🔑
ML-KEM KEM
Key Encapsulation

→

🔗

HKDF-SHA3

Key Derivation

→

⚡
AES-256-GCM
Symmetric Enc

→

✍️

ML-DSA SIG

Sign Output

→

🔒

CIPHERTEXT

.qvenc File

Step by Step

Encryption Deep Dive

Key Pair Generation

The system samples a random secret vector s from the ring R_q = Z_q[X]/(X^n + 1), where n=256 and q=3329 for Kyber. A random error vector e is drawn from a centered binomial distribution. The public key is computed as A·s + e where A is a publicly known matrix derived from a seed. This is the Module Learning With Errors (MLWE) problem — believed to be hard for quantum computers.

Ring: R_q = Z_3329[X]/(X^256+1) Secret: s ← CBD(η) Public: pk = (A, A·s+e)

KEM Encapsulation

To encrypt a file, a fresh random session key is sampled. The KEM encapsulation algorithm takes the recipient's public key and this session key as input, producing a ciphertext c and a shared secret K. The ciphertext is stored alongside the encrypted file — the shared secret K is ephemeral and never stored. Only the holder of the secret key can recover K from c.

            // KEM Encapsulation

            const { ciphertext, sharedSecret } = ML_KEM.Encaps(publicKey);

            // sharedSecret K is ephemeral — never stored

            // ciphertext c stored with encrypted file

AES Key Derivation

The 32-byte shared secret K from the KEM is passed through HKDF-SHA3-512 to derive the AES-256 encryption key. HKDF (HMAC-based Key Derivation Function) provides key separation and stretching, ensuring the AES key has strong statistical properties even if the KEM output has any bias.

            // Key derivation via HKDF

            const aesKey = HKDF(

              hash: "SHA3-512",

              ikm: sharedSecret,

              salt: randomSalt,

              info: "QSafeVault-AES256",

              length: 32 // 256 bits

            );

AES-256-GCM Encryption

The file bytes are encrypted using AES-256-GCM with a random 96-bit IV (Initialization Vector). GCM mode provides both confidentiality (via CTR mode encryption) and integrity (via GHASH authentication tag). The 128-bit tag ensures any tampering with the ciphertext is detected during decryption. The browser's native Web Crypto API is used, enabling hardware AES acceleration.

Key: 256-bit AES IV: 96-bit random Auth Tag: 128-bit

ML-DSA Signature (Optional)

After encryption, the ciphertext can be signed using ML-DSA-65 (CRYSTALS-Dilithium). Dilithium is a lattice-based scheme where signing produces a signature by sampling a masking vector, computing a commitment, deriving a challenge, and outputting a response. The signature (3293 bytes for ML-DSA-65) binds the ciphertext to the signer's identity, enabling non-repudiation that survives quantum attacks.

            // Sign the ciphertext

            const hash = SHA256(ciphertext);

            const signature = ML_DSA.Sign(signingKey, hash);

            // Outputs 3293 bytes for ML-DSA-65

Security Analysis

Threat Model

What QSafe Vault protects against — and what it doesn't.

✓ PROTECTED AGAINST

✓ Classical computer brute-force attacks on keys

✓ Quantum computer attacks (Shor's algorithm) on key exchange

✓ Grover's algorithm reducing AES-256 to 128-bit (still safe)

✓ "Harvest now, decrypt later" attacks on intercepted files

✓ Ciphertext tampering (AES-GCM authentication tag)

✓ Forged signatures (ML-DSA lattice hardness)

✓ Server-side data breaches (no server contact)

⚠ OUT OF SCOPE

⚠ Compromised device / malware on your machine

⚠ Secret key theft after generation

⚠ Browser memory attacks (mitigated by tab close)

⚠ Social engineering / phishing

⚠ Side-channel attacks on the underlying hardware

⚠ Key loss (no recovery mechanism — by design)

Privacy Architecture

Zero Server Trust

🌐

CLIENT-SIDE ONLY

Every cryptographic operation — key generation, encryption, decryption, signing, verification — runs entirely within your browser using the Web Crypto API. Nothing is sent to any server.

🧠

IN-MEMORY KEYS

Private keys exist only in browser memory during your session. When you close the tab, all key material is immediately garbage collected. No persistence, no leakage.

🔍

AUDITABLE CODE

The entire application is a static HTML/JS/CSS bundle. You can inspect every line of code via browser DevTools. No obfuscation, no hidden network calls, no tracking.

How QSafe Vault Works