An attacker does not have to read your data today to put its future privacy at risk.
A recording of a vulnerable encrypted exchange can be kept for years. If a sufficiently capable quantum computer eventually breaks its key exchange, information you considered private could become readable long after the conversation ended. Medical histories, defence designs, financial records and the private context held by an AI assistant can remain sensitive for decades.
A future security upgrade cannot recall a copy that has already been stolen.
That is the urgency behind harvest now, decrypt later. The collection can happen now. The consequences can arrive later, when replacing a protocol or changing a provider can no longer protect that captured copy.
8DB gives teams that control an application's data path a way to act: protect the data in their own nodes and seal messages with post-quantum cryptography before handing them to the network. Participating 8DB nodes establish that inner protection themselves. A network provider's PQC rollout does not have to come first.
Put protection where you have control
Open the comparison diagram at full size.
An infrastructure migration can involve application teams, database vendors, certificate providers, gateways, devices and partners. Their schedules will differ. Owning the data does not mean controlling every service through which it travels.
For an application team, 8DB offers a defined place to intervene: the database nodes that store and exchange the information. The message receives its own post-quantum protection at the sending endpoint and is opened by the authorized receiving endpoint. Forwarding services can carry it without receiving its payload decryption keys.1
In the reviewed 8DB path, breaking an outer classical transport connection would still leave the attacker with the inner PQC-protected message. Its confidentiality depends on the message's cryptography and endpoint keys, rather than solely on the outer connection. A change of route does not remove that inner protection.1
Ordinary routers can already carry these encrypted bytes. The deployment work belongs at the participating endpoints and any adapters needed to carry the protocol. You can keep compatible transport security as an additional layer.
Put protection in the data systems you control, without waiting for network upgrades.
The pressure is increasing
AI is changing the speed and economics of cyber operations. The UK's National Cyber Security Centre reports that advanced models can assist vulnerability discovery and other attack steps, and that attackers are already using AI to support their operations. The same capabilities also help defenders find and fix weaknesses.2
AI is contributing to quantum engineering too. Google researchers have demonstrated machine-learning improvements to quantum error correction and processor control. These are real advances; they do not establish a date when a machine will break today's public-key cryptography.3
The uncertainty makes the lifetime of your information the useful planning measure. If a record must remain private for twenty years, its protection needs to account for what an attacker might be able to do during those twenty years. The decision cannot rest entirely on what an attacker can decrypt this morning.
NIST warns that deploying new cryptography across products and services takes years. Waiting for the arrival of a cryptographically relevant quantum computer would leave too little time to complete that transition.4
Start with the sensitive information you can protect now.
Category 5 algorithms inside a native database mesh
8DB is an embeddable, multimodal database with native mesh capabilities. Its reviewed protected-node composition uses ML-KEM-1024 to establish the message secret, AES-256-GCM to encrypt the payload, and ML-DSA-87 to authenticate the sender and message context. ML-KEM-1024 and ML-DSA-87 are NIST Category 5 parameter sets and the pair selected for those roles in NSA's CNSA 2.0 suite.15
The receiver checks the message and relevant authority, then stores the information under its own local encryption keys. The message is bound to its recipient, session, channel and sequence. Storage roots are not sent to the peer through this path.1
The reviewed profile gives evaluators a concrete starting point: it currently accepts only canonical lexical records, with a defined admission boundary and published recovery evidence. Bringing chat or other application data into this composition means integrating and qualifying its data schema. Teams can use that starting point to define an evaluation for their own workload.1
This is the combination we are building into 8DB: protected local storage, post-quantum node exchange and governance in one embeddable engine. The reviewed composition operates in software without a required HSM or cloud key-service call. Teams still provision trusted identities and protect the secrets held by their endpoints.
The distinction matters after delivery too. Information persists in records, indexes, replicas and backups. An engine that owns those operations can expose how protection changes during migration, what authority applies after recovery and which copies remain. Those behaviors belong in the acceptance tests alongside the cryptography.
Published ACVP demonstration-service results and interoperability checks let an evaluator inspect algorithm behavior now. Integrated release qualification is underway; formal CAVP validation, FIPS module validation and product-wide CNSA conformance require their own evidence.6
A protection boundary you can examine
For a relay without the inner keys, captured payloads remain ciphertext. Ending an outer connection does not hand that relay the contents of the protected message.
That is meaningful control over exposure. It also has a clear boundary: authorized endpoints can read the data, and their software, updates, identity configuration and key custody matter. Observers may still see traffic timing, size and routing information. A customer-owned cloud compute node is still an endpoint whose host must be trusted.1
PQC addresses the future decryption of vulnerable cryptography. Patching, access controls and secure recovery address other ways an attacker can reach information. Building the protections together makes the system worth evaluating; each guarantee needs its own evidence.
Other paths to PQC exist, including database connection upgrades and network tunnels. Oracle and Cloudflare document such options.78 The reason to evaluate 8DB is the integrated requirement: an application needs protected storage and native node exchange, together with control over the data's lifecycle.
Demand evidence for protection and cost
A useful evaluation should show which keys each component holds, what a relay can capture, whether unauthorized or replayed messages are rejected, and what survives a crash, a migration or a restored copy.
It should also measure the costs. In our published same-cipher fixture, a 115-byte record occupies 131 bytes under either classical or post-quantum key establishment. That is zero additional bytes in that record representation. Key envelopes, signatures and processing still have costs. The native message path performs fresh encapsulation and signing for each frame, so it needs its own matched network and latency measurements.16
The public evidence retains limitations and negative results. Those results identify where to strengthen the implementation and what an independent evaluator should try to reproduce.
Begin with the information that must stay private
A provider's future roadmap cannot recover confidentiality for vulnerable traffic an attacker has already captured. Taking control starts with identifying the data that has to remain private, the endpoints allowed to read it and the actual protection between them.
For teams that control their application's data path, that is a concrete evaluation they can begin while the wider infrastructure migration continues.
Tell us about one long-lived dataset and the endpoints you control. We can define an evaluation that makes the protection, the costs and the remaining work visible.
Footnotes
-
Protected-node architecture and source scope and dated qualification matrix, September 16, 2026. Describes RequiredMeshNode at source
fa491158, with the full identifier and supported storage profile in the matrix. The matrix separates source review, historical experiments and pending release qualification. The architecture figure does not claim every constructor, modality or transport is qualified. No per-message ratchet has been demonstrated against later compromise of the recipient's retained decapsulation key. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 -
NCSC: Why cyber defenders need to be ready for frontier AI, March 30, 2026. Describes observed progress and use in cyber operations, with limits; PQC is not a general cure for AI-assisted intrusion. ↩
-
Google Research: Towards a quantum computer that learns from its errors, July 22, 2026. Reports specific quantum-control and error-correction results, not a forecast of cryptographic break capability. ↩
-
NIST: Quantum computers may put internet traffic at risk, July 30, 2026. Explains the yearslong migration and the need to act before cryptographically relevant machines exist. ↩
-
NIST FIPS 203 and FIPS 204; NSA CNSA 2.0 FAQ, version 2.1, December 2024, directly checked September 16, 2026. Algorithm parameter choices, protocol profiles and product/module validation are distinct. ↩
-
8DB stored-data evidence and public evidence repository. Exact source/profile-bound results must accompany promoted claims; an earlier build's tests do not qualify successor fixes. ↩ ↩2
Published and discussed
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