8DB lets participating nodes send protected content through infrastructure that doesn't hold the payload keys. For an application team, that means the company carrying a message needn't become another company trusted to read it.
The reviewed native node profile brings that recipient protection together with protected local storage and authorized database operations. Its integrated scope is specific: fixed peers exchanging canonical lexical records, such as dictionary entries. That is a concrete starting point for evaluating the architecture. 8DB's protection boundary.
So where does the cryptography come from, and what did we build?
Public algorithms, explicit responsibilities
The native exchange profile uses ML-KEM-1024 to establish a shared secret, ML-DSA-87 to authenticate signed messages and AES-256 to protect their contents. These algorithms have different jobs.
ML-KEM is the key-encapsulation mechanism specified in NIST FIPS 203. It gives two parties a way to establish secret key material over a public channel. ML-DSA, specified in FIPS 204, supplies digital signatures. An application still needs to know which public key belongs to an authorized participant.
8DB's engineering includes the message construction, the context bound to keys and signatures, identity admission, protected storage and the lifecycle connecting them. Those choices carry security responsibilities of their own. A list of respected algorithms cannot answer whether the right person received the right data under the right authority.
This distinction is familiar in established cryptographic engineering. HPKE, described in RFC 9180, combines key encapsulation, key derivation and authenticated encryption, while explicitly leaving some properties to the surrounding application. Its specification discusses replay, negotiation and other boundaries separately. HPKE is an example of this separation of responsibilities; this article does not claim that 8DB's native message protocol implements HPKE.
Standards make the underlying tools inspectable. A system design must also make their use inspectable.
Who can open it along the way?
Connection protection and recipient content protection answer different questions. Explore where the content becomes readable.
The intermediary can open the content.
In this example, TLS protects each network connection. The intermediary terminates the first connection, processes plaintext, then sends it over a second protected connection.
- 01 · SourceCreates the content
Prepares plaintext, then sends it over TLS.
- 02 · IntermediaryOpens the content
Terminates TLS and processes plaintext before forwarding.
- 03 · RecipientUses the content
An authorized endpoint opens and processes plaintext.
| Participant | In this example |
|---|---|
| Source | Yes, it creates the plaintext |
| Intermediary | Yes, at TLS termination |
| Recipient | Yes, at the authorized endpoint |
Choose this boundary when the intermediary needs to inspect or transform the content and is trusted to do so.
The intermediary forwards a sealed envelope.
The source protects the content for the intended recipient. The intermediary forwards that envelope without a key to open it. The authorized recipient opens it at the destination.
- 01 · SourceCreates the content
Prepares plaintext, then seals it for the recipient.
- 02 · IntermediaryRoutes sealed content
Forwards the protected envelope without a recipient key.
- 03 · RecipientUses the content
An authorized endpoint opens and processes plaintext.
| Participant | In this example |
|---|---|
| Source | Yes, it creates the plaintext |
| Intermediary | No, without a recipient key |
| Recipient | Yes, at the authorized endpoint |
Choose this boundary when an intermediary should deliver the content without being able to read it. Content inspection or transformation needs an authorized endpoint.
Read both boundaries without switching views
Connection protection
In this example, TLS protects each network connection. The intermediary terminates the first connection, processes plaintext, then sends it over a second protected connection.
Intermediary access: Yes, at TLS termination. Choose this boundary when the intermediary needs to inspect or transform the content and is trusted to do so.
Recipient content protection
The source protects the content for the intended recipient. The intermediary forwards that envelope without a key to open it. The authorized recipient opens it at the destination.
Intermediary access: No, without a recipient key. Choose this boundary when an intermediary should deliver the content without being able to read it. Content inspection or transformation needs an authorized endpoint.
Choose the reader independently of the carrier
Consider a restricted reference catalog shared between two authorized sites. The network route may pass through a hosted gateway. The gateway's job is delivery. Giving it access to the catalog creates an additional trust relationship the application may have no reason to accept.
In the reviewed 8DB node path, the sender protects a message for the recipient before handing it to the transport. The recipient verifies and opens the message, then protects its local records under its own storage keys. The sender's storage root can remain at the sender. The documented node journey.
TLS continues to have a useful role. It protects traffic between the endpoints of a connection. If that connection terminates at a gateway, the gateway is one of those endpoints. Additional protection inside the connection can keep the payload encrypted beyond that termination point. TLS 1.3.
The valuable choice is therefore who receives decryption authority. Outer transport security and recipient content protection can work together. Removing TLS would not, by itself, improve privacy.
The receiving application must be able to read the information it is authorized to use. Endpoint security and key custody remain essential. A relay can also observe information such as routing, timing and message size, or interrupt delivery. Content confidentiality addresses a particular exposure; it doesn't make the whole interaction invisible.
Make the database own more of the handoffs
The opportunity becomes more interesting when protected delivery meets useful local work.
An application can assemble an encrypted database, a message protocol, an identity service and a recovery procedure. Mature components can be excellent choices. The application still owns the agreement between them: whether an accepted message may become a local record, which permissions govern its use, and what happens when a restored copy is older than the current access policy.
In 8DB's reviewed protected indexed-record path, source changes and their lexical-index updates share a commit. Recovery stages and verifies the data before current authority permits activation. That gives developers concrete behavior to reuse: keep search aligned with its source, and check today's permissions before making a restored copy usable. Protection and lifecycle overview.
Bringing these responsibilities into an embeddable, omnimodal database can reduce the separate consistency and recovery machinery an application team must build. The amount of work removed depends on its chosen operations and deployment.
This is also why the exact profile matters. A storage component, a hybrid cryptographic construction and an integrated node protocol are different things to evaluate. Evidence for one cannot automatically qualify another. The lexical node path described here does not establish protected exchange for every graph, vector, document or spatial operation in 8DB's broader modality set.
The ambition is valuable: more useful operations sharing a coherent protection lifecycle. Each supported combination has to earn that description.
Ask for the evidence between the algorithms
A buyer should be able to follow the design from an enrolled identity to a recovered, usable record. That means examining how the selected build handles wrong recipients, altered messages, obsolete permissions and interrupted work, alongside the successful path.
Algorithm test results, protocol review, operational tests and cryptographic module validation answer different questions. NIST's Cryptographic Module Validation Program evaluates modules against defined requirements. Naming a NIST algorithm is not a claim that an entire product has that validation. An integrated design deserves scrutiny at its integration points.
For 8DB, the worthwhile decision is whether a supported configuration gives your application the protection and useful operations it needs, with less separate security machinery to assemble and maintain. Performance belongs in that same evaluation, including setup, storage, delivery and recovery costs.
Bring one non-sensitive data journey: who creates the information, who should read it, which intermediary should carry it without reading it, and what must remain possible after an interruption. We can map that journey to the relevant 8DB profile and evidence, then identify the remaining work. That is a practical way to evaluate an architectural difference.
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