Post-Quantum Encryption

A cryptographically relevant quantum computer does not yet exist. But data encrypted today under classical public-key algorithms — RSA, ECC, ECDH — may still be sensitive when such a computer becomes available. Adversaries capable of long-term interception and storage are already operating under the assumption that today's intercepted ciphertext will be decryptable on a future date. This is the harvest-now-decrypt-later threat model.

Lattix takes the position that long-lived data should be wrappable today under algorithms that remain secure against a future quantum adversary. The platform supports the standardized post-quantum primitives, integrates them into the hierarchical key model, and provides the lifecycle tooling to manage the transition.

What the platform supports

The platform uses NIST-standardized post-quantum primitives:

• Module-Lattice-based Key Encapsulation Mechanism (ML-KEM) for key establishment. ML-KEM is used where classical ECDH or RSA-OAEP would be used — for example, in wrapping keys that pass between services, or in bootstrapping session secrets.
• Module-Lattice-based Digital Signature Algorithm (ML-DSA) for signing. ML-DSA is used where ECDSA or RSA signatures were used — decision signatures, assertion signatures, and envelope manifest signing.

The platform does not invent variants or parameter sets. It tracks the standards as they stabilize and integrates them through the same key management abstraction used for classical algorithms.

Key lifecycles

Each tenant-held key — classical or post-quantum — moves through a lifecycle:

• Active. Generated, published in the tenant's key set, available for wrapping and unwrapping.
• Deprecated. Still valid for unwrapping existing objects, but new wrappings use a successor key. This is the window during which you accept the cost of retaining the old key but stop creating new dependencies on it.
• Retired. No longer available. Objects wrapped under a retired key can no longer be unwrapped through the platform.

Overlap windows between active and deprecated states are configurable. For a large dataset with slow-moving consumers, the overlap can be months; for a tight compliance environment, it can be measured in hours.

Hybrid protocols

Most organizations cannot cut over to post-quantum primitives in a single day. The platform supports hybrid operation during the transition: a wrapping operation can produce a ciphertext that is secure under both a classical primitive and a post-quantum primitive, so that a consumer running either can unwrap it, but an adversary needs to break both to compromise the ciphertext.

Hybrid operation has a cost — larger envelopes, slightly slower unwraps — but it lets an organization migrate data to post-quantum primitives before every consumer has been updated to the post-quantum-only stack.

Rewrapping without redistribution

A major advantage of the envelope model is that upgrading the algorithm used to wrap an object's data encryption key does not require re-encrypting or redistributing the object's payload. The payload is encrypted under the DEK; the DEK is wrapped under the KEK. To migrate an object to a stronger wrap algorithm, the KEK is replaced (or a new KEK is introduced at a new epoch), and existing wrapped DEKs are re-wrapped under the new KEK.

For large archives — which are exactly the data most at risk from harvest-now-decrypt-later — this is the difference between a migration that is operationally feasible and one that is not.

Tenant-level algorithm selection

The choice of wrap algorithm is a tenant-scoped policy decision. An administrator can:

• Require post-quantum wrapping for new objects above a specified classification.
• Run hybrid for a defined transition period, then flip to post-quantum-only.
• Retain classical-only for specific short-lived workloads where the post-quantum transition is not warranted.

These controls are exposed under Configuration → Encryption Profiles.

Relationship to other concepts

• Post-quantum keys plug into the existing Hierarchical Key Model. No separate key store is required.
• Signed decisions and assertions use ML-DSA where the tenant has configured it; the policy evaluation flow is unchanged.
• All key-generation, rotation, and retirement events are recorded on the Immutable Ledger.