ML-KEM-1024 + HQC-256 Dual-KEM — NIST Security Level 5
Dual-KEM: your message is independently encrypted under two separate NIST Level 5 post-quantum algorithms — ML-KEM-1024 (lattice-based) and HQC-256 (code-based). An attacker must break both simultaneously. The two algorithms are based on entirely different hard mathematical problems, so a breakthrough against one leaves the other unaffected.
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. Different hard mathematical problems — a quantum breakthrough against lattices leaves HQC completely unaffected. Both must be broken simultaneously to read your message. Dual-KEM means the attacker must break two unrelated mathematical problems at once — a requirement so extreme that it 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 v3: dual-KEM + HKDF sub-keys). Envelope v3 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 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: dual-KEM cross-verification, 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.