Your data should remain useful and under your control as systems change, people lose access and cryptography evolves. That is the ambition behind 8DB: to make protection and change part of the database foundation, so application teams have less security machinery to assemble themselves.
The recent scrutiny of candidates in China’s NGCC cryptography program shows why this matters. Researchers reported predictable key generation and broken ciphertext rejection: failures that could undermine the promised security before an attacker needed to defeat the underlying mathematics.
The LinkedIn discussion around those findings raised the right question. How much protection does a strong algorithm deliver if the implementation, key management or surrounding system gets something wrong?
For a database, the answer reaches into every operation that stores, shares, retrieves or restores information. It also reaches into the next cryptographic upgrade.
The failures behind the headline
Two reported failures make the problem concrete.
In the submitted HEP-QC implementation, the key-generation wrapper failed to initialize its random-number generator correctly. Fresh processes produced the same keys. A related problem made the first encapsulation predictable. The underlying cryptographic design could not compensate for secrets generated from predictable state. [1]
In Aigis-Enc+, modifying a ciphertext frequently left the original shared secret unchanged. The intended rejection logic wrote to the wrong buffer. A security property promised by the scheme was lost in its implementation. [2]
Public cryptanalysis is supposed to expose these weaknesses. A finding in candidate reference code is not automatically a finding in a deployed product, and an implementation defect needs a different remedy from a weakness in the algorithm itself.
For buyers, the lesson is practical: ask what the product actually does when assumptions fail.
Start with evidence at the point of failure
8DB’s recorded cryptographic checks address several of those questions directly.
Our offline suite passed 35 known-answer checks covering ML-KEM, ML-DSA and supporting cryptographic operations. Those checks compare implementation outputs against specified inputs and expected results. Production randomness is a separate requirement: correct test-vector output does not establish the quality of a deployment’s entropy source. [3]
The recorded Windows interoperability run with OpenSSL goes further into behavior. The two implementations exchanged keys and signatures successfully. Modified signatures were rejected. A signature bound to a particular context failed when that context was omitted. A modified KEM ciphertext produced a different shared secret, exercising the rejection behavior relevant to the failure described above. [4]
These are concrete questions a buyer can inspect: does the implementation produce the expected result, work with another implementation and respond correctly to the tested invalid inputs?
The same discipline extends to hardware, timing and key custody. Each needs evidence appropriate to the actual deployment. Our evidence library keeps the tested configurations, results and remaining qualification visible. [5]
Make protection hold when the database is used
An application needs more than a successful cryptographic exchange. It needs the right person to receive the right information under the rules that apply now.
Imagine an employee reading a sensitive record. The application caches it to make the next read faster. The employee then loses access. Should the cache still return the record?
In our recorded Linux test, the reader first retrieved the exact entity and then received a genuine cache hit. After the owner revoked the grant, the same read interface returned NO_GRANT before consulting the cache or storage backend. The owner could still read the entity. [6]
That is a useful security property at the point where an application depends on it: a performance optimization does not become a second source of permission.
We have also tested interrupted publication. Across five writer-process termination points in the bounded prototype, readers obtained the expected prior state, new state or refusal. The tests check what happens when data publication and authority state do not agree. [6]
These recorded cases give substance to the larger 8DB direction: bring cryptography, current permissions and recovery into a shared foundation for the operations applications perform.
Your data will outlive today’s cryptography
Finding a weakness creates an immediate operational question: how do you move away from it?
A faulty implementation may need a patch and new keys. A weakened algorithm may need replacing. Standards, customer requirements and threat models will also change. A database holding valuable records for years needs a repeatable way to evolve its protection.
Updating new writes is one step. Existing records, archives and recovery paths still have to be accounted for.
This is where 8DB’s approach to cryptographic agility becomes particularly valuable. Its protected-data lifecycle connects a declared protection change with registered retained copies and the authority used during recovery.
In our recorded lifecycle scenario, key derivation changed from HKDF-SHA256 to HKDF-SHA384 while the data cipher remained AES-256-GCM-SIV. A registered archive using the old profile kept migration completion open. Recovery checked the required current protection and permissions, including access for the owner and refusal for a revoked reader. [7]
The operator gets a meaningful answer: what changed, what still needs attention and who can use the restored information.
That is the direction we are building toward for cryptographic change across the database. A migration should have a finish line that accounts for the data your organization retains. The broader goal is to make the next transition a supported product capability instead of another bespoke integration project.
A foundation for useful, controlled AI
AI makes this challenge more urgent because information takes on more forms.
A confidential document can become searchable passages, graph relationships, retrieved context and a stored answer. Each representation makes the information more useful. Each also creates another place where its protection and access rules matter.
8DB is an omnimodal database. We are building its native data operations around a shared protection foundation so applications can connect information without rebuilding the control model at every step.
Consider an engineering assistant connecting a requirement to a design decision, several repositories and the code that implements it. The value comes from understanding those relationships. The security requirement is to preserve control as that context becomes useful.
Our vision is powerful AI grounded in connected information that remains under its owner’s control. Cryptographic agility belongs in that vision: the protection must be able to evolve along with the information and the applications using it.
What customers should gain
For a software vendor, an embedded protection foundation offers a way to make security and migration capabilities part of its own product.
For an integrator, it offers the opportunity to reduce the custom work joining storage, permissions, cryptography and recovery.
For an organization retaining sensitive data, it offers a clearer way to account for change: which protection applies, which retained copies remain outstanding and whose authority governs a restore.
Established databases and security services provide valuable mechanisms. The choice is how much work your team must own to make those mechanisms deliver the complete behavior your application needs.
8DB’s proposition is to bring more of that work into a coherent data foundation. The value lies in the combination: useful native operations, protection, current authority and a lifecycle designed for change.
The NGCC findings give buyers a reason to look past an algorithm name. Our invitation is to follow that question all the way into the database.
Bring us one workflow and one requirement that matters: rejecting modified input, enforcing a permission change, recovering after interruption or changing protection on retained data. We can map it to the relevant 8DB evidence and define the next evaluation around your decision.
Build for the useful life of your data, including the changes you cannot predict today.
Evidence and further reading
[1] HEP-QC: reported key-generation and encapsulation failures.
[2] Aigis-Enc+: reported implicit-rejection failure.
[3] 8DB: recorded offline known-answer checks.
[4] 8DB/OpenSSL: exact recorded Windows interoperability results.
[5] Evidence review guide: configuration, timing, custody and qualification context.
[6] 8DB: scoped Linux access and interrupted-publication results.
[7] 8DB: recorded key-derivation, retained-copy and recovery scenario.
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