ML-KEM
DSA-65
QUANTASEAL
ML-KEM-768AES-256-GCMML-DSA-65
Initializing Quantum Vault
QUANTASEAL
QuantaSeal is designed so that a breach of any single layer — database, KMS, application code, or QuantaSeal staff — cannot expose customer vault contents. This document describes every control and the threat it neutralises.
Verify explicitly
Every request is authenticated with JWT (HS256) validated against issuer, audience, and token version. All sensitive operations additionally require RBAC permission checks. No 'trusted network' exceptions.
Least-privilege access
Four RBAC roles (viewer / editor / admin / owner) with per-endpoint permission gates. Quanta Copilot can read vault metadata but cannot unseal. MPC custody keys are held by customers, not QuantaSeal.
Assume breach
Every control is designed assuming an attacker already has database access, KMS access, or application code access. MPC split custody, Nitro Enclaves, and tamper-evident audit chains ensure breach of any single layer yields nothing useful.
| Actor | Operation |
|---|---|
| Customer | POST /vault/sealX-Vault-Enable-MPC: true |
| QuantaSeal | hmac_secret = secrets.token_bytes(64) |
| QuantaSeal | qs_share, customer_mask = XOR_split(hmac_secret) |
| QuantaSeal | custody_key = os.urandom(32) |
| QuantaSeal | mpc_shard = AES-GCM(HKDF(custody_key), customer_mask) |
| QuantaSeal | hmac_wrapped = KMS.wrap(qs_share) |
| Customer | ← { entry_id, custody_key_hex } |
| Customer | POST /vault/unseal/{id}X-Vault-Custody-Key: <hex> |
| QuantaSeal | qs_share = KMS.unwrap(hmac_wrapped) |
| QuantaSeal | customer_mask = AES-GCM-decrypt(shard, HKDF(custody_key)) |
| QuantaSeal | hmac_secret = XOR(qs_share, customer_mask) |
| QuantaSeal | verify_and_decrypt(envelope, hmac_secret) |
Security invariant: QuantaSeal holds KMS.wrap(qs_share). Customer holds custody_key. Neither alone can reconstruct hmac_secret. A wrong custody key produces wrong hmac_secret → ML-DSA-65 + HMAC-SHA-512 verification fails → decryption blocked.
On Enterprise plans, vault unseal operations run inside AWS Nitro Enclaves — isolated VM environments with no persistent storage, no network access, and cryptographic attestation via AWS KMS. The enclave performs ML-KEM-768 decapsulation and AES-256-GCM decryption atomically. Plaintext never leaves the enclave boundary — not even the host application code sees it.
No persistent storage
Enclave memory is destroyed on shutdown
No network access
Enclave cannot exfiltrate data externally
KMS attestation
AWS KMS verifies enclave identity before granting key access
QuantaSeal undergoes an annual external penetration test by an independent security firm targeting the API, authentication flows, PQC implementation, multi-tenancy isolation, and MPC split-key custody. The executive summary is available to Enterprise customers under NDA.
Pentest report executive summary available to Enterprise customers under NDA.
Request Pentest ReportEvery audit event includes a current_hash = SHA3-256(prev_hash ‖ event_data) and is ML-DSA-65 signed. Any modification, deletion, or reordering of events is cryptographically detectable by verifying the chain. Logs are replicated to S3 with WORM (Object Lock) enabled.
Hash algorithm
SHA3-256
Quantum-resistant
Entry signature
ML-DSA-65
FIPS 204 post-quantum
Backup
S3 WORM
Object Lock + Versioning
SIEM push
Real-time
Splunk / Datadog / Elastic
Last updated May 2026. Architecture subject to change — see changelog for updates. Questions? security@quantaseal.io