The threat is a timing trick, not a magic decryption ray
An attacker who can't read your encrypted files today copies them anyway and waits. When a large enough quantum computer arrives, they run it against the ciphertext they grabbed years earlier. That's "harvest now, decrypt later" (HNDL), and it bites cloud storage harder than almost anything else: a file you upload in 2026 might still need to stay secret in 2036, long after the encryption that protects its key stops being safe. A one-off chat message has a short secrecy window. A tax archive or a decade of client work does not, and that long confidentiality lifetime is exactly what the attacker is betting on.
Why did the quantum timeline suddenly get shorter in 2026?
Because the cost of the attack collapsed on paper. In 2019, Google's Craig Gidney estimated that factoring a 2048-bit RSA key would take roughly 20 million qubits and about eight hours. In May 2025 he published a follow-up, "How to factor 2048 bit RSA integers with less than a million noisy qubits," that cut the qubit requirement by 20x, to under 1 million, by trading a longer runtime (under a week) for far fewer qubits. An approximate-arithmetic technique in that work shaved the Toffoli-gate count by over 100x. Later architecture papers pushed the hypothetical estimates lower still.
Nobody has built a machine within two orders of magnitude of that scale. The rough consensus puts "Q-Day," a quantum computer that can break RSA-2048, around 2030, give or take three years. The exact date isn't the point. The point is that the resource estimates are dropping faster than the hardware is improving, and your stored data has to outlast both. If a file needs to remain confidential past roughly 2035, the honest planning assumption is that today's asymmetric encryption won't protect it for its whole life.
What actually breaks — and what doesn't
This is where most HNDL coverage gets sloppy. Not all encryption is equally exposed, and blurring the two is how vendors sell panic. Two different algorithms run when you store a file with a zero-knowledge provider, and only one of them is in real trouble.
| Layer | What it protects | beebeeb uses | Quantum attack | Real exposure |
|---|---|---|---|---|
| Symmetric | File contents | AES-256-GCM | Grover's algorithm (quadratic speedup) | Drops to ~128-bit security. Still infeasible to brute force. |
| Asymmetric | The keys (wrapping, sharing, sealing) | X25519 | Shor's algorithm | Broken outright on a large quantum computer. This is the HNDL hole. |
So the realistic HNDL scenario against a zero-knowledge store is not "they decrypt your AES-256 files." It's "they harvest the wrapped keys and the public-key handshakes, break the X25519 layer with a future quantum computer, recover the file keys, and then read the AES-256 content." The asymmetric layer is the door; the symmetric layer is the safe behind it. You have to replace the door, not the safe.
What does an honest migration look like, and where does beebeeb stand?
The destination is already standardised. In August 2024, NIST finalised ML-KEM (FIPS 203), a lattice-based key-encapsulation mechanism built to resist Shor's algorithm. The industry isn't ripping out the old math to trust the new math alone. The consensus is to run both side by side: a hybrid such as X25519 + ML-KEM-768, where the shared secret stays safe unless an attacker breaks both the classical curve and the post-quantum scheme. A flaw in the young lattice math can't leave you worse off than today, and the proven curve keeps doing its job until quantum hardware actually shows up.
Here is the honest part, stated before a critic would. Beebeeb is not post-quantum yet. Today the key-wrapping and sealed-file-request layers use X25519, which means files stored now carry the same standard HNDL risk every X25519- or RSA-based service carries: Proton, Tresorit, iCloud's Advanced Data Protection, all of them. "Post-quantum" is not a box any mainstream consumer cloud can truthfully tick in 2026. Anyone claiming otherwise is selling.
What we can claim is structural. Beebeeb's crypto lives in one shared Rust core that every client compiles from: the web app, the CLI, and the native apps that are coming. Swapping the asymmetric layer to a hybrid scheme is a change in one place, not a re-implementation per platform, and the content cipher (AES-256-GCM) doesn't move at all. That migration, hybrid key encapsulation for the wrapping layer, is tracked on our public roadmap, on a timeline driven by mature library support rather than a press release. We'll publish what changed and when. No "quantum-safe" badge.
What you should actually do about it now
If your data's secret-by date is next year, HNDL isn't your problem. Ordinary breach protection is, and zero-knowledge already covers it: a provider holding only AES-256-GCM ciphertext leaks unreadable blobs even today. If your data has to survive into the 2030s, treat post-quantum migration as a provider-selection question, not a feature you bolt on later. Ask any cloud three things: which layer is symmetric, which is asymmetric, and what's the hybrid-KEM plan for the asymmetric one. A vendor who can't answer that cleanly hasn't thought about HNDL at all.
Beebeeb's security model is documented down to the primitive (AES-256-GCM, Argon2id, X25519, OPAQUE, BIP39 recovery, keys zeroized after use) precisely so you can audit the claim instead of trusting it. The quantum decryption that worries you is years out. The choice of where your long-lived files sit is today's.