Hybrid key establishment and authenticated encryption. Defense in depth: classical X25519 and post-quantum ML-KEM-1024 both contribute to the shared secret.
| Layer | Algorithm | Standard | Purpose |
|---|---|---|---|
| Key establishment | X25519 ECDH | RFC 7748 | Classical ECDH component of hybrid KEM |
| Key establishment | ML-KEM-1024 | FIPS 203 (Category 5) | Post-quantum KEM component — 256-bit quantum security |
| Symmetric encryption | AES-256-GCM | NIST SP 800-38D | Authenticated data plane, 96-bit nonces |
| Key derivation | HKDF-SHA-512 | RFC 5869 | Derive session and data-plane keys from KEM output |
| Signatures | ML-DSA-65 | FIPS 204 | Provenance record signing |
The hybrid KEM combines a classical X25519 ECDH exchange with ML-KEM-1024 encapsulation. Both contribute to the shared secret — the system retains security as long as either component holds.
ML-KEM-1024 is FIPS 203 Category 5: 256-bit quantum security. Key sizes:
ML-KEM-1024 sizes (bytes): encapsulation key: 1568 decapsulation key: 3168 ciphertext: 1568 shared secret: 32
Each API response carries "key_exchange": "X25519+ML-KEM-1024" so clients can audit which KEM was used for their draw.
Authenticated encryption is performed with AES-256-GCM, 96-bit nonces. Per-session keys are derived from the KEM shared secret via HKDF-SHA-512 with a domain-separated info string.
Replay protection is provided by a monotonically increasing nonce counter maintained client-side; the server enforces strict ordering on nonces within a session.
Every provenance record is signed with ML-DSA-65 (FIPS 204). The signed payload includes the entropy bytes (hashed), the provenance_id, the issued_at timestamp, the source_id, the entropy_score, and a hash-chained link to the previous record.
Signature verification is available via POST /v1/verify on the Verified and Enterprise tiers.
All algorithms are referenced through a module registry, not hard-coded at call sites. Algorithm substitution (for example, swapping ML-KEM-1024 for a future Category-5 KEM) requires no client rewrite — the change is server-side and announced via the response's key_exchange field.
This is defense-in-depth for the cryptographic stack itself: a future break of either classical or post-quantum primitives does not require a customer migration.
Cryptographic issues should be reported via our coordinated disclosure process. See Security Disclosure or /.well-known/security.txt for contact details and safe harbor policy.
How the cryptography layer fits into the full 6-Layer Quantum Assurance Pyramid.