Post-quantum protection, without per-record PQC bloat.
The key-establishment and signing costs are paid at shared boundaries. Here is the mechanism, the measured per-record result and the accounting behind it.
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.
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.
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 moves the large asymmetric objects to shared boundaries. Encryption, signatures, integrity and access policy can then be considered together when designing the application.
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 final governed GCM write profile has separate qualification and performance work.