Stop Buying Quantum-Proof AES. It Is the Part of Your Database That Was Never Broken.

The meeting goes like this.

The vendor opens with the year 2035, a diagram of a qubit, and the phrase "harvest now, decrypt later." Slide four says your data at rest is exposed. Slide five says their product encrypts it with something quantum-proof. Slide six has the price.

Somewhere between slides four and five, a fact went missing. Your data at rest is encrypted with AES-256. AES-256 is not what a quantum computer breaks. You are being sold a replacement for the one part of the system that does not need one.

What Shor breaks, and what Grover does not

Two quantum algorithms matter here, and they are not the same size.

Shor's algorithm, on a large enough fault-tolerant machine, factors integers and solves discrete logarithms efficiently. That is the end of RSA, of elliptic-curve key agreement and signatures, and of finite-field Diffie-Hellman. These are the algorithms NIST deprecates in 2030 and disallows in 2035.¹ They are also the algorithms doing the interesting work in your system: agreeing keys, wrapping keys, signing things.

Grover's algorithm speeds up brute-force search by a square root. Against AES-256 that leaves roughly 128 bits of security, which is the level the entire industry called comfortable for AES-128 before anyone had heard of a qubit. Grover's search also parallelises badly, so even that figure flatters the attacker.² NIST keeps AES-128, AES-192 and AES-256 approved. It keeps SHA-2 and SHA-3. The NSA's CNSA 2.0 asks for AES-256 and stops there.³

So the bulk cipher protecting your pages, rows and blobs is fine. It was fine before the pitch and it is fine after it. Anyone selling you quantum-proof AES is selling you the part that was never broken.

What actually breaks in a database

Follow one record from the moment it is written.

Its bytes are encrypted with a data key. Fine. But that data key came from somewhere and is protected by something, and those somethings are where the asymmetric algorithms live.

• The data key was wrapped with an RSA key in a key service, or exchanged over an elliptic-curve handshake to a client that encrypts before it writes. Harvest the wrapped key and the ciphertext today, unwrap the key in 2035, read the record.
• The record's batch, its backup manifest, its audit log and its integrity certificate were signed with ECDSA or RSA. Forge the signature later, and the evidence that the record was never altered fails on exactly the day someone needs it.
• The session that carried the record to the database, and the one that carried its key from the key service, were keyed with a classical exchange. Captured today, readable later.
• The certificates that authenticated all of the above chain up to classical roots.

That is the envelope. The bytes inside it never needed help. The envelope is where the exposure is, and the envelope is where the work is.

The work is not cryptographic

Here is the part the pitch never reaches. Suppose you replace every asymmetric algorithm in the envelope with ML-KEM and ML-DSA tomorrow morning. You have protected the records you write tomorrow afternoon. You have done nothing for the records you wrote yesterday, and yesterday is thirty years deep.

Every record already stored carries the envelope of the day it was written. Changing that envelope is not a cryptographic problem. It is a database operation. You need to know which records depend on which algorithm, change the protection while the system keeps serving reads, prove per record that it happened, list the exceptions, and make sure the snapshot from 2019 does not quietly restore the RSA wrap you just retired. That is where the budget goes. That is where the risk is. And it is the one thing quantum-proof AES cannot touch, because AES was never the problem.

Three questions that end the pitch

Ask these in order and watch slide five change colour.

1. Which asymmetric algorithm establishes or wraps the key that protects this record, and where is that wrap stored? If the answer involves RSA or an elliptic curve anywhere between the key service and the disk, including client-side envelopes and keys shared with a partner, that is your exposure, and the vendor's AES story has nothing to say about it.
2. Which signatures over my stored objects will still need to verify after 2035? Backup manifests, audit logs, integrity certificates, code. If they are classical, they are the forgeable half of your evidence.
3. When one of those algorithms retires, what happens to the records I already hold? If the answer is a re-encryption project, a datafile rewrite, or a pause, the product fills one cell of the grid and the migration is still yours.⁴

A vendor who can answer all three has a product for the actual problem. A vendor who cannot is selling you the padlock and calling it the vault.

Where we stand, since you will ask

8DB encrypts every record with AES-256 in an authenticated mode, and we will never sell you a replacement for it.⁵ What we changed is the envelope and the operation.

The data key for every record is established by ML-KEM-1024 in a hybrid with X25519 and is never stored. It is derived at use from a root secret and the record's governance state, so there is no wrapped key for anyone to harvest. Batch integrity is one ML-DSA-87 signature over a SHA-384 Merkle root with a per-record inclusion proof, so the evidence outlives the classical algorithms and costs 0.054 percent of storage instead of a signature on every row.⁶ Every ciphertext carries its algorithm version, so "which records depend on the retiring algorithm" is a query, and replacing the algorithm on records you already hold is a sweep inside the engine that serves reads while it runs.⁷ On release builds across four hosts, a 115-byte record encrypts to 131 bytes whether its key came from a classical derivation or from ML-KEM, with per-record times within one percent.⁸ The post-quantum cost is paid once per key and once per batch. The AES core is untouched, because it was never broken.

If you are being pitched this month

Write to hello@8braid.com with the subject line "Slide five." Send the deck, with the vendor's name removed if you prefer. We will mark which slides describe the part that was never broken, which describe the envelope, and which describe the migration, and we will give you the three questions in the vendor's own vocabulary for the next meeting. The reply will be an engineer, not a deck.

Sources and further reading

• NIST IR 8547: Transition to Post-Quantum Cryptography Standards ↗
• NIST Post-Quantum Cryptography FAQs ↗
• NSA: Commercial National Security Algorithm Suite 2.0 ↗
• 8DB: Your Post-Quantum Migration Has 21 Questions. The Algorithm Answers One.
• 8DB: The Category 5 Bill Is Paid Once or Paid Per Record
• 8DB: Category 5 Keys in Software, on the Hardware You Already Have
• 8DB: Post-Quantum Cryptography for Stored Data

Footnotes

1. NIST IR 8547, Transition to Post-Quantum Cryptography Standards (initial public draft, November 2024): quantum-vulnerable algorithms at 112 bits of security are deprecated after 2030, and all quantum-vulnerable public-key algorithms are disallowed after 2035. AES, SHA-2 and SHA-3 are unaffected. ↩

2. Grover's algorithm requires on the order of 2^128 sequential quantum operations against AES-256, and splitting the search across k machines yields only a factor of the square root of k. NIST's post-quantum FAQ makes the same point; it is why NIST did not change its guidance on AES key lengths. ↩

3. CNSA 2.0 (NSA, September 2022, with later advisories) specifies AES-256, SHA-384 and SHA-512, ML-KEM-1024, ML-DSA-87, and the stateful hash-based signatures LMS and XMSS for firmware. ↩

4. The grid is laid out in Your Post-Quantum Migration Has 21 Questions. The Algorithm Answers One.: seven surfaces by three tenses, with the cells the shortlist fills and the seams it leaves. ↩

5. The default authenticated mode is AES-256-GCM-SIV (RFC 8452), chosen for nonce-misuse resistance; the approved-mode deployment profile uses AES-256-GCM through aws-lc-rs. Both are AES-256. The mode is a deployment profile, not a code change. AES-GCM is the mode NIST specifies in SP 800-38D; GCM-SIV is specified in RFC 8452 and is not in the SP 800-38 series, which is the whole reason the approved-mode profile exists. ↩

6. The Category 5 Bill Is Paid Once or Paid Per Record. Fixture: 100,000 records of 115 bytes, release build. Batch-signed integrity added 0.054 percent to encrypted storage, 13.1 MB in total, against 579.4 MB for the same records with a 4,627-byte signature repeated per row in a conventional database. Host and date are stated with the harness in that article. ↩

7. The sweep and its evidence page: per-record completion, concurrent reads throughout, restart and resume, snapshot inventory by version. Detailed in Your Post-Quantum Migration Has 21 Questions. The Algorithm Answers One., note 6. ↩

8. Release builds on four hosts: Windows on a Ryzen 7 7800X3D (2026-07-19), Linux x86_64 on a Xeon (2026-09-11), Windows on a Ryzen 9 9950X3D (2026-09-11, host not quiesced), Linux aarch64 on a Graviton3 (2026-09-12, host not quiesced); 200 operations per arm after warm-up; a 115-byte record encrypts to 131 bytes in both arms and median per-record times agree within one percent on all four. Harness: Post-Quantum Cryptography for Stored Data and the evidence folder README. ↩

Continue the technical conversation

Where could this help your work?

Bring a research question, a database workload or an application you want to build. Let’s connect the ideas in this article to an evaluation that matters to your team.

Discuss this work