Your database encrypts its records with AES-256. That is useful information. The next question is just as important: what would someone need to recover the key?
The answer can change your post-quantum plan. A strong payload cipher can sit behind a vulnerable key-establishment mechanism. A newly protected connection can deliver records into storage whose older backups still depend on yesterday's keys. Each part has a different job, and each needs its own evidence.
This is where database design matters. In 8DB, our omnimodal database, we bring key protection and the lifecycle of stored records into the engine's design. The practical aim is to make the protection chain easier to reason about, operate and verify as cryptography changes.
AES and public-key cryptography have different jobs
AES encrypts data with a shared secret key. Public-key mechanisms can help establish that secret or protect its delivery. Digital signatures perform another job: checking the origin and integrity of a message or artifact.
Those distinctions matter for quantum risk. Shor's algorithm threatens widely used public-key systems, including RSA and elliptic-curve cryptography, on a sufficiently capable quantum computer. Grover's algorithm offers a different kind of search advantage against symmetric keys. Its practical cost and limited parallel advantage matter; reducing the discussion to a key-length slogan misses those conditions.
NIST's post-quantum FAQ says current applications can continue using AES with 128-, 192- or 256-bit keys. That guidance supports a focused migration: inspect the exposed public-key dependencies and the systems around them, while retaining suitable symmetric encryption. Implementation and deployment security still require their own assessment. NIST post-quantum FAQ
NIST's ML-KEM standard illustrates the division of labor. A key-encapsulation mechanism establishes a shared secret that can then be used with symmetric cryptography. It complements the payload cipher. FIPS 203
Follow the protection chain
Imagine an archive of encrypted customer records. The records use AES-256. Their data keys may be wrapped by other keys, derived from a protected root, or supplied through a key-management service. The relevant question is which dependencies let an authorized system recover those keys.
If a public-key mechanism protects that recovery path, its quantum exposure belongs in the assessment. If a wrapping layer uses symmetric encryption, evaluate that actual design instead. “Encrypted at rest” alone does not tell you which arrangement you have.
Start with one representative record and trace the chain: its cipher and mode, the keys or root secrets needed to open it, the mechanism protecting those secrets, and the permissions governing their use. Include replicas and backups. That map turns a broad security label into something an engineer can inspect.
One encrypted record. Three jobs to understand.
Select a responsibility to see the question it should answer.
Which cipher, mode and operating limits apply?
Inspect the implementation and its nonce, key and usage requirements.
Bring old records into the plan
Changing today's key-establishment mechanism does not automatically update every copy of yesterday's data. Depending on the architecture and threat model, a migration may require rewrapping keys, re-encrypting records, replacing signatures, or changing how roots are protected and recovered.
Consider a backup restored after the live database has migrated. Which keys does it need? Can the restored system identify its cryptographic version? Does recovery preserve the intended access controls? These are useful acceptance tests for the plan.
NIST's crypto-agility guidance treats cryptographic change as a system capability involving architecture and operations. Inventory, dependencies and a workable transition belong alongside algorithm selection. Considerations for Achieving Crypto Agility, updated June 2026
Put each responsibility where you can inspect it
8DB's implementation separates authenticated payload encryption, key derivation from a protected root, and protection of that root. Its root-envelope implementation combines ML-KEM-1024 with X25519. That describes a component in the protection chain; root custody, deployment configuration and recovery still have their own responsibilities.
The payload implementation uses AES-256-GCM-SIV, an authenticated-encryption mode with nonce-misuse resistance. A mode's properties come with operating limits and implementation requirements, which remain part of a deployment review. RFC 8452
Keeping these responsibilities explicit gives an evaluator a more useful conversation with us. You can ask how a stored record is protected, what opens its root envelope, and how older copies move through a cryptographic change. Our database migration guide follows that lifecycle in more detail.
An implemented component, a configured deployment and an independently validated security claim are different milestones. Ask us for the applicable implementation evidence and review status for the configuration you intend to use. That keeps the decision attached to the system you will actually operate.
Ask three questions before choosing the plan
- What protects the keys? Identify the key-establishment, wrapping, derivation and custody mechanisms that matter for your records.
- What else depends on public-key cryptography? Include signatures, certificates and the connections through which keys or sensitive data travel.
- What happens to existing copies? Require a migration and recovery path for live records, replicas and backups, with a clear way to verify completion.
AES-256 is one important part of the answer. A useful database plan connects that cipher to protected keys, manageable change and recoverable records.
If you are assessing that plan, talk to us about 8DB. Bring a description of the data you retain, how long it must remain protected and how you need to recover it. Those requirements are a concrete starting point for evaluating the whole chain.
Evidence scope Primary standards · Implementation review · Conceptual protection map. Explore the evidence.
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