Information Security · Applied Cryptography
Preparing Enterprise Data Assets for Post-Quantum Cryptography and Tenant Sovereignty
Architectural Urgency: Employment records, statutory audit trails, medical histories, and sovereign infrastructure plans must remain confidential for `10 to 30 years`. Under a “Harvest Now, Decrypt Later” (HNDL) threat model, encrypted traffic captured in transit today can be decrypted retroactively once cryptanalytically relevant quantum computers mature. Upgrading key exchange protocols cannot wait until the hardware arrives.
Contents
- Understanding “Harvest Now, Decrypt Later” (HNDL) for long-lived records
- Hybrid Key Encapsulation: Pairing X25519 with ML-KEM (FIPS 203)
- Per-tenant envelope encryption and cryptographic blast-radius reduction
- Designing for cryptographic agility in database schemas
- Customer-controlled key revocation and jurisdictional residency
1. Understanding “Harvest Now, Decrypt Later” (HNDL) for long-lived records
Symmetric encryption algorithms with 256-bit keys (such as `AES-GCM-256`) remain resilient against known quantum algorithms; Grover’s algorithm provides at most a quadratic speedup, leaving `AES-256` with an effective security level of `128 bits`, which remains computationally infeasible to brute-force.
Public-key cryptography, however, faces a completely different mathematical reality. Classical key exchange and digital signature schemes (`RSA-2048`, `ECDH P-256`, `X25519`) rely on the hardness of integer factorisation or the discrete logarithm problem — both of which are solvable in polynomial time by Shor’s algorithm on a sufficiently large fault-tolerant quantum computer. If an adversary records TLS session handshakes or encrypted backup replication streams today, they can store the ciphertext cheaply and decrypt the session keys years later when quantum hardware scales.
2. Hybrid Key Encapsulation: Pairing X25519 with ML-KEM (FIPS 203)
Following NIST’s standardization of lattice-based post-quantum cryptography (`FIPS 203 / ML-KEM`, formerly CRYSTALS-Kyber), TICNES AI adopts a hybrid key encapsulation strategy for long-lived transport links and archive key wrapping.
Rather than replacing battle-tested elliptic-curve cryptography (`X25519`) with a standalone post-quantum primitive, hybrid key exchange concatenates the shared secrets of both `X25519` and `ML-KEM-768` inside a single Key Derivation Function (`HKDF-SHA384`):
// Conceptual Hybrid Shared Secret Derivation // Security holds as long as AT LEAST ONE of X25519 or ML-KEM-768 remains unbroken. shared_secret_classical = X25519(ephemeral_priv_ecc, peer_pub_ecc) shared_secret_pqc = ML_KEM_768_Decapsulate(ephemeral_priv_kem, ciphertext_kem) master_session_key = HKDF_SHA384( ikm: concat(shared_secret_classical, shared_secret_pqc), salt: transcript_hash, info: "TICNES-AI-HYBRID-KEM-V1" )
This hybrid construction provides a mathematical two-way guarantee: even if a subtle implementation flaw is discovered in a newer lattice primitive, the channel remains at least as secure as classical `X25519`; and when quantum hardware renders `X25519` obsolete, `ML-KEM-768` protects the session against retroactive decryption.
3. Per-tenant envelope encryption and cryptographic blast-radius reduction
In many multi-tenant cloud platforms, all customer rows sit in a single database table encrypted at the disk volume level with one shared cloud key. While volume encryption satisfies basic compliance checkboxes (`"encrypted at rest"`), it offers zero protection against application-layer SQL injection, ORM misconfigurations, or compromised database snapshots.
At TICNES AI, sensitive enterprise payloads (such as uploaded employment contracts, proprietary RAG document chunks, and audit logs) are protected using a three-tier Envelope Encryption hierarchy:
| Key Tier | Scope | Algorithm | Rotation & Storage |
|---|---|---|---|
| 1. Data Encryption Key (DEK) | Single document or record batch | `AES-GCM-256` (unique 96-bit nonce + AAD) | Generated per write; stored wrapped alongside ciphertext |
| 2. Tenant Key Encryption Key (T-KEK) | Single client organisation (`tenant_id`) | `AES-KW-256` / Hybrid KEM | Rotated on schedule; strictly isolated per tenant |
| 3. Root Master Key (RMK) | Jurisdictional KMS / HSM boundary | Hardware-backed KMS root | Never leaves hardware security module |
Crucially, when encrypting each record with `AES-GCM-256`, we bind the `tenant_id` and `record_id` into the Additional Authenticated Data (AAD) parameter of the cipher. Even if an application bug copies a ciphertext blob from Tenant A’s row into Tenant B’s row, decryption fails deterministically with an authentication tag mismatch because the `tenant_id` in the AAD does not match.
4. Designing for cryptographic agility in database schemas
Hardcoding a single cipher or key size into application logic makes future migrations painful. Every encrypted field in our schemas is prefixed with a compact binary version header (`alg_id`, `key_version`, `nonce`, `ciphertext`, `auth_tag`). When a tenant rotates their `T-KEK` or upgrades an algorithm identifier, background re-wrapping workers update the wrapped DEK headers without requiring downtime or full-payload re-encryption.
5. Customer-controlled key revocation and jurisdictional residency
True data sovereignty means the client holds the kill switch. For enterprise deployments where the client supplies their own Key Management Service (BYOK / Customer-Managed Keys), revoking TICNES AI’s grant on the `T-KEK` renders every stored document and vector embedding across our infrastructure cryptographically unreadable within seconds. That guarantee — verified in code rather than promised in a slide deck — is the foundation of our security posture.