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

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?

Waitlist (Founding Pass: 100 GB free for 6 months, limited seats): https://secvault.rakshachakra.com/?utm_source=devto&utm_medium=post&utm_campaign=tech-post