Protect sensitive data at the source.
Put post-quantum message protection and local encrypted storage in the application you control. Start at your endpoints, then follow the evidence for protection, recovery and cost.
The copy captured today can outlast today’s encryption.
Some information needs to stay private for decades. An attacker can retain a vulnerable encrypted exchange and wait for a future capability to break its key exchange. Upgrading later cannot recall that copy.
NIST’s harvest-now, decrypt-later guidance explains why migration needs to begin before a cryptographically relevant quantum computer arrives. Start with the sensitive data and endpoints you control.
Protect the message across either pipe.
Participating 8DB nodes can establish their own inner post-quantum protection. The reviewed path uses ML-KEM-1024 for the message secret, AES-256-GCM for the payload and ML-DSA-87 to authenticate the sender and message context. The receiving node verifies and opens the message, then stores the content under its own local keys.
That gives an application team a place to act while the broader network migration continues. The intermediary can forward the protected frame without its payload keys; compatible outer transport security can remain an additional layer.
The reviewed Required profile currently accepts canonical lexical records. Additional application schemas require integration and qualification. Endpoints, identity enrollment and key custody remain part of the deployment boundary. Inspect the exact path and current qualification ↗
Protection is part of the data system.
8DB brings cryptographic protection and governance into the database. Data owners set the access and sharing policy, while people, applications and AI operate within their authorized views. Keeping the database local or under the owner’s chosen deployment is part of that control.
Encrypted data is released through the authorized decryption path.
Signed boundaries and integrity structures make changes inspectable.
Give a participant the permitted working view, with access governed at the data boundary.
Choose the applications and AI callers that are authorized to work with the information.
Category 5 cryptography and CNSA 2.0 algorithm choices
The cryptographic profile uses ML-KEM-1024 for key establishment and ML-DSA-87 for signatures, with AES-256 and the applicable SHA-384/SHA-512 roles. The algorithm choices follow the NSA’s published CNSA 2.0 suite.
8DB uses the ML-KEM-1024 and ML-DSA-87 parameter sets listed in CNSA 2.0. Complete profile qualification, product validation and deployment approval have their own requirements. The measured page-crypto example below uses AES-256-GCM-SIV; the governed AES-256-GCM profile has separate qualification.
Establish keys. Encrypt records. Sign batches.
Post-quantum establishment
ML-KEM-1024 with X25519 establishes key material. This work is paid at the key boundary.
Symmetric encryption
AES-256 protects each record. Derived keys connect the protection path to its governance context.
Post-quantum signatures
ML-DSA-87 authenticates a shared data boundary. The selected integrity profile defines how records link to the signed boundary, including its digest and proof structures.
This stored-record design puts large asymmetric objects at shared boundaries. The node-message path above performs its own fresh encapsulation and signing per frame, so its network costs must be accounted for separately.
Connect the cipher to the complete data lifecycle.
The shared foundation we are building brings physical protection, access decisions and consistent recovery into one architecture. Each step has a distinct responsibility, from establishing a key to deciding whether recovered information can be used.
Establish keys
Separate key establishment and custody from the fast symmetric operations that protect stored data.
Protect stored structures
Bind protected frames to an authenticated map and root, so the system can identify the exact stored state it is opening.
Enforce access
Apply current authority before returning governed information, including information already present in a cache.
Publish consistent state
Coordinate protected data and authority at the publication boundary. An incomplete transition must have a defined outcome.
Recover safely
Re-establish the trusted state before making data visible. Refuse incompatible state rather than silently treating it as valid.
The September 29 experiments examine specific boundaries in this foundation: a warm entity cache after revocation, writer-process interruption and startup file handling.
The measurements below retain their original record-cipher and key-establishment scope. They do not measure the total cost of this broader foundation.
The post-quantum path adds zero bytes to this encrypted record.
Controlled page-encryption benchmark: the same 115-byte input and AES-256-GCM-SIV cipher, with two different key-establishment paths. These figures describe the ciphertext, before database framing and metadata.
Classical KDF → AES-256
131 B115 bytes of payload + a 16-byte authentication tag.
ML-KEM-established key → AES-256
131 BThe same payload size and authentication tag.
That is the architectural distinction: post-quantum key establishment changes how the key is established while the per-record cipher remains the same. Records do not each carry another large post-quantum key-establishment object.
The same per-record encryption path, measured.
| Host and run date | Classical key | ML-KEM key | Raw log |
|---|---|---|---|
| Ryzen 7 7800X3D · Windows19 July 2026 | 500 ns | 500 ns | Read log ↗ |
| Intel Xeon · Linux x86_6411 September 2026 | 733 ns | 737 ns | Read log ↗ |
| Ryzen 9 9950X3D · Windows11 September 2026 | 500 ns | 500 ns | Read log ↗ |
| AWS Graviton3 · Linux aarch6412 September 2026 | 1,176 ns | 1,175 ns | Read log ↗ |
Median encryption time, 200 operations per arm after warm-up, 115-byte input, same AEAD in both arms. Measurements were made by 8Braid; this page was assembled from the existing logs. The September shared-host runs record their load. These are page-crypto measurements, not an end-to-end benchmark of every governed write profile.
The costs at each boundary remain visible.
| Boundary | What is accounted for |
|---|---|
| Every encrypted record | The tested AEAD adds a 16-byte tag in both key paths. The incremental PQC ciphertext payload is 0 bytes. |
| Every established key | The published benchmark counts 1,568 B of KEM ciphertext plus a 48 B wrapped key. The complete declared transport fields also include a 32 B ephemeral public key, 12 B nonce and 16 B sender ID: at least 1,676 B before serialization framing. |
| Every signed batch | The signature itself is 4,627 B. The M1 boundary benchmark emits a 7,332 B signature object including its verifying key. The batch also has its applicable digest and integrity structures. |
| Database framing and policy | Version headers, governance context and other record structures are accounted separately. The CAM benchmark adds a 5 B version header to the 131 B ciphertext, producing 136 B in that profile. |
The record-size and timing claims apply to the named benchmark. Key-establishment latency, signing, verification, metadata and policy processing still have costs. The governed GCM profile has its own qualification and performance record. Per-frame encapsulation, signatures, network framing and delivery also belong in an end-to-end measurement.