AUTONOMY DIRECTORATE

🏠 Main

🧪 Interactive Apps

📰 News

🛡️ PQ Crypta Proxy

👤 Account

⟨ QUANTUM ERROR PORTAL ⟩

Navigate the Error Dimensions

PQ Crypta Logo

Encrypt & Share

⚛️ ML-KEM-1024 + ML-DSA-87 + SLH-DSA-SHA2-256s
🧬 HQC-256 dual-KEM
🔒 AES-256-GCM key wrap
We cannot read your message. Ever.
0 / 10,000
Burn after reading
⚛️

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
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 Digital Signature Level 5 Resistant ✓
SLH-DSA-SHA2-256s FIPS 205 Hash-Based Signature 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.
🧬
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. 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 v2 for dual-KEM). 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.