"Post-quantum" gets used as a catch-all scare word, which makes it easy to assume every kind of encryption needs replacing before quantum computers arrive. That's not quite right. Post-quantum file encryption is really about one specific weak point — how two parties agree on a secret key in the first place — not about the cipher that scrambles your file bytes. Here's the actual distinction, why it matters today rather than someday, and how FileX applies it.
The attack that matters today: harvest now, decrypt later
No quantum computer today can break modern encryption. The risk isn't that your files are readable now — it's that an adversary can copy encrypted data today and simply hold onto it, betting that a future quantum computer will be able to unlock it. CISA, the NSA, and NIST jointly warned about exactly this in their Quantum-Readiness fact sheet: adversaries are already collecting encrypted data with the intent to decrypt it once a sufficiently powerful quantum computer exists. This is why "does your data need post-quantum protection yet?" is the wrong question if the data needs to stay confidential for years. The attack against it may already be underway; only the decryption is scheduled for later.
AES-256 doesn't need a fix
Start with what's not the problem. FileX encrypts your file bytes with AES-256-GCM — a symmetric cipher, meaning the same key both locks and unlocks the data. The best-known quantum attack against a symmetric cipher is Grover's algorithm, which speeds up brute-force key search quadratically, not exponentially. Against a 256-bit AES key, that leaves roughly 128 bits of effective security against a quantum attacker — still astronomically out of reach. AES-256 does not need a post-quantum replacement. If you see a product claiming to have "quantum-proofed" its symmetric cipher, be skeptical of what problem it's actually solving.
The real threat: asymmetric key exchange
The threat is to asymmetric cryptography — the algorithms that let two parties who've never met establish a shared secret over an open channel, like X25519 (Elliptic Curve Diffie-Hellman, RFC 7748) or RSA. Their security rests on math problems — the elliptic-curve discrete-log problem, integer factorization — that a sufficiently large quantum computer running Shor's algorithm could solve outright, not just weaken. That's a full break, not a strength cut in half. Any file encrypted today to a recipient using only classical key exchange is exactly the kind of data a "harvest now, decrypt later" adversary would want copied and shelved.
Hybrid encryption: secure if either half holds
The practical defense NIST settled on isn't to abandon classical key exchange — it's to combine it with a quantum-resistant algorithm, so the combined result stays secure as long as at least one of the two remains unbroken. In August 2024 NIST finalized the first Federal Information Processing Standards for this: FIPS 203 standardizes ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism, derived from CRYSTALS-Kyber) for key exchange, and FIPS 204 standardizes ML-DSA (derived from CRYSTALS-Dilithium) for digital signatures. Both are believed secure even against an adversary holding a large-scale quantum computer.
How FileX applies this: the FileX ID
When you create a FileX ID, FileX generates a hybrid keypair entirely in your browser: an X25519 keypair alongside an ML-KEM-768 keypair, plus an ML-DSA-65 keypair for signing. The private keys never leave your device. When someone encrypts a file to your FileX ID, FileX's hybrid.js module runs both key agreements and combines the results rather than picking one:
ss_ec = X25519(ephemeral_priv, your_x25519_pub)
ss_pq = ML-KEM-768.Encapsulate(your_mlkem_pub)
KEK = HKDF-SHA-256(ss_ec || ss_pq, info = transcript-binding context)
The file's actual encryption key is then wrapped under that combined KEK with AES-256-GCM. Because the key-encapsulation key is derived from both shared secrets concatenated together, an attacker has to break both X25519 and ML-KEM-768 to recover it — breaking only one gets them nothing. That's the concrete meaning of "quantum-safe" here: it isn't that AES got upgraded, it's that the key delivered to AES can no longer be exposed by breaking just the classical half.
Signatures follow the same logic in one layer, not two: when you tick "sign" while encrypting, FileX signs with ML-DSA-65 so the recipient can verify the file came from your FileX ID and wasn't altered — the same post-quantum signature standard also signs FileX's erasure certificates, independent of file encryption.
Does your data need this yet?
If a file only needs to stay confidential for a few days or weeks, the classical-only risk window is small. But for anything with a long confidentiality shelf life — legal records, medical data, source code, anything embarrassing or regulated for years to come — "harvest now, decrypt later" means the exposure window opened the moment it was encrypted with classical-only key exchange, not the moment a quantum computer arrives. Password-based encryption (FileX's FXQ1 container, derived with Argon2id) is a separate case: it isn't vulnerable to Shor's algorithm at all, since there's no asymmetric key exchange to attack — a strong, unique password remains the deciding factor there.
The recipient-encryption case is where the asymmetric key-exchange question actually applies, and it's where hybrid key exchange earns its keep.
Takeaway
- Post-quantum protection is about asymmetric key exchange, not about swapping out AES — AES-256 already resists quantum attacks with a comfortable margin.
- The real-world risk today is "harvest now, decrypt later": encrypted data copied now to be decrypted once quantum computers are strong enough.
- FileX's FileX ID combines classical X25519 with post-quantum ML-KEM-768 via HKDF, so security holds even if one algorithm is later broken.
- Encrypt a file to a FileX ID to try it — nothing is uploaded, and only the recipient's private key, never generated or seen by any server, can open it.
Top comments (0)