Why I chose a hybrid post-quantum design (ML-KEM-768 + X25519) for encrypted cloud storage

Deemanth — Thu, 12 Nov 2026 13:34:33 +0000

I'm building SecVault, a zero-knowledge encrypted cloud storage service. Files are encrypted on your device before upload, so the server never sees plaintext. Here's why I picked a hybrid post-quantum design, and what it does and doesn't give you.

The threat: harvest now, decrypt later

Cloud files live for years. An attacker who records encrypted data today could decrypt it later if a quantum computer breaks classical key exchange. For storage, that matters more than for short-lived messages.

Why hybrid

ML-KEM is the NIST-standardised post-quantum key encapsulation mechanism, but it's new. X25519 is battle-tested but not quantum-resistant. A hybrid combines both, so an attacker has to break both. I use X-Wing (ML-KEM-768 + X25519) for key exchange, and hybrid signatures with ML-DSA-65 + Ed25519.

The rest of the stack

AES-256-GCM for file encryption, done on the device
Argon2id for turning your password into keys
Sharing you can revoke
Files stored in Amsterdam, EU

What this does not mean

There's no independent audit yet
It's not open source yet
It's waitlist-only and in testing
Choosing algorithms is the easy part. Implementation bugs are where real systems fail, which is why outside review matters more than the algorithm list

Question for you

If you were reviewing this, what would you want published first: the protocol spec, the client code, or test vectors?