Nested Dual-KEM — HQC-256(ML-KEM-1024), NIST Security Level 5
Nested dual-KEM: your message is encrypted under ML-KEM-1024 (lattice-based), and that ciphertext is encrypted again under HQC-256 (code-based) — two separate NIST Level 5 post-quantum algorithms, one wrapped around the other. Breaking one layer yields only more ciphertext. The two algorithms are based on entirely different hard mathematical problems, so a breakthrough against one leaves the other layer intact.
5
NIST
Level
Level
Algorithm
FIPS Standard
Role
Security Level
Quantum Threat
ML-KEM-1024
FIPS 203
Key Encapsulation (lattice)
Level 5
Resistant ✓
HQC-256
NIST 2025
Key Encapsulation (code-based)
Level 5
Resistant ✓
ML-DSA-87
FIPS 204
Envelope Authenticity (API response signing)
Level 5
Resistant ✓
SLH-DSA-SHA2-256s
FIPS 205
Envelope Authenticity, Hash-Based (API response signing)
Level 5
Resistant ✓
AES-256-GCM
FIPS 197
Private Key Wrap (URL only)
256-bit
Halved by Grover*
* AES-256-GCM is used solely to transport the ML-KEM private key inside the URL fragment. It is never used to encrypt your message. Grover's algorithm halves AES-256 key search space to 128-bit equivalent — still computationally infeasible.
Why dual-KEM?
“Algorithmic monocultures fail catastrophically; diversity fails gracefully.”
Dual-KEM Algorithm Diversity
ML-KEM-1024 is lattice-based. HQC-256 is code-based. Your message is sealed inside the lattice layer, and the whole thing is sealed again inside the code-based layer — nested, not side-by-side. A quantum breakthrough against lattices hands the attacker nothing but HQC ciphertext; breaking HQC reveals only ML-KEM ciphertext. Both unrelated mathematical problems must fall to read one message — a requirement that exceeds any known quantum or classical attack model. No other encrypted message tool does this.
Split Zero-Knowledge
Both ML-KEM-1024 and HQC-256 private keys are AES-256-GCM wrapped and stored server-side. The single 32-byte wrap key lives only in your URL fragment — never transmitted to any server. Without the URL, neither server operators nor attackers can decrypt your message.
Length-Hiding Padding
Your plaintext is padded to a fixed 4 KB block boundary before encryption. A 10-character note and a 3,000-character letter produce identically-sized ciphertext — so ciphertext size reveals nothing about your message.
Tamper-Evident Metadata
Expiry time, burn-after-reading flag, and envelope version are signed with HMAC-SHA-256 derived from your wrap key. The signature travels in your URL — any server-side tampering with message metadata is detected before decryption begins.
Versioned Envelope
Every encrypted message is wrapped in a versioned envelope (currently v4: nested dual-KEM + HKDF sub-keys). The envelope protocol uses HKDF-derived sub-keys for wrap, metadata integrity, and destroy-auth, eliminating cross-use leakage between operations. If the encryption format is upgraded in the future, older links can still be decrypted correctly — no broken links from algorithm migrations.
Short Shareable Links
Every encrypted message gets a compact short link (e.g.
pqcrypta.com/share/?s=Ab3Xk9) in addition to the full UUID URL. The short code is only a server-side lookup — the decryption key fragment never appears in the short code and is never sent to the server.
Harvest-Now-Decrypt-Later Safe
Nation-state actors are already capturing today's TLS traffic to decrypt once quantum computers arrive. This message is safe even against that threat model.
No Plaintext Stored
Ciphertext auto-deletes on expiry. No accounts, no logs. Burn-after-reading available for single-use links.
Passphrase Layer
Optional AES-256-GCM(PBKDF2, 200k iterations) encryption applied to the plaintext before it enters the nested dual-KEM envelope. URL theft alone cannot decrypt the message — the passphrase is required. Share it out-of-band alongside the link.
Integrity Badge
Every verification layer is displayed after decryption: nested dual-KEM layer verification (cross-verification on legacy links), HMAC metadata signature, padding integrity, envelope version, passphrase status, and preview hash match. Green means every check passed. Red means decryption was aborted.
Preview Hash Fingerprint
SHA-256 of the plaintext (first 8 hex chars) computed before encryption and embedded in the URL. On decrypt, the browser recomputes it and flags any mismatch — detecting a server returning a different message than the one the sender encrypted.
Link Health Check
Immediately after encryption, the browser performs a full in-memory decrypt roundtrip — no extra server call, no burn risk. Confirms the link decrypts correctly before it is shared, catching URL encoding errors or API regressions at the source.
Self-Audit Mode
A toggle on the decrypt view surfaces the full cryptographic configuration: envelope version, KEM names, HKDF context strings, padding block size, passphrase status, and truncated HMAC signature. For developers and security-conscious users who want to verify the exact parameters without reading source code.