What ML-KEM Does - and How QNSI Runs It for You Today

Evidence boundary: any present-tense QNSI product wording below describes source-declared contracts, architecture targets, or vendor-run artifacts-not independently observed production behavior. Conformance artifacts prove only their stated algorithm scope. End-to-end production execution is NOT VERIFIED.

Every TLS handshake your systems completed today over classical key exchange can be recorded now and decrypted the day a cryptographically-relevant quantum computer arrives - 'harvest now, decrypt later' is a storage cost, not a physics problem. Regulators have already responded: US Executive Order 14412 (June 2026) puts PQC key establishment on federal High-Value Assets by 2030, and NSA's CNSA 2.0 requires ML-KEM-1024 for new national-security systems from January 2027. The named replacement for the key exchange you run today is ML-KEM, standardised as FIPS 203 in August 2024.

The 60-second explanation below is followed by QNSI source contracts and conformance artifacts. An SDK call or ACVP result does not prove end-to-end deployment execution, which remains NOT VERIFIED.

ML-KEM in 60 seconds

A KEM is not a cipher. It is how two parties agree on a shared secret over an untrusted channel; the secret then keys a fast symmetric cipher (AES-256-GCM) that encrypts the actual data. ML-KEM's shared secret is always exactly 32 bytes - precisely an AES-256 key. Three operations, that is the whole interface:

KeyGen() → (publicKey, secretKey). Generate a keypair; share the public key, guard the secret key.
Encapsulate(publicKey) → (ciphertext, sharedSecret). Anyone with the public key mints a fresh shared secret plus a ciphertext encoding it.
Decapsulate(secretKey, ciphertext) → sharedSecret. Only the secret-key holder recovers the same 32 bytes. Both sides now share a secret that never crossed the wire.

Security rests on Module Learning With Errors - a lattice problem believed hard for classical and quantum computers alike, which is the entire point of post-quantum cryptography. You need ML-KEM running correctly, at scale, with independent proof. QNSI defines a platform target for that requirement; end-to-end deployment execution remains NOT VERIFIED.

Three parameter sets - and how QNSI's crypto policy picks for you

FIPS 203 ships three parameter sets; the trade is security margin versus bytes on the wire:

ML-KEM-512 (NIST level 1, AES-128-equivalent) - 800-byte public key, 768-byte ciphertext. Development and testing.
ML-KEM-768 (NIST level 3, AES-192-equivalent) - 1,184-byte public key, 1,088-byte ciphertext. The production default, including hybrid TLS.
ML-KEM-1024 (NIST level 5, AES-256-equivalent) - 1,568-byte public key and ciphertext. Highest assurance, and the CNSA 2.0 requirement.

QNSI policy source defines allowed KEM sets per tier and maker-checker contracts for policy changes. Complete enforcement across every operation and deployment-specific approval behavior remain NOT VERIFIED.

Where QNSI source targets ML-KEM

The following are source contracts or architecture targets, not independent deployment proof:

Transport target - QNSI is PQC-native; X25519MLKEM768 is explicit composite interoperability only. Public-edge negotiation remains NOT VERIFIED.
KMS target - source defines ML-KEM operations and a 87-algorithm catalog (24 KEMs + 63 signatures across 13 families). Complete wrapping execution remains NOT VERIFIED.
Vault target - versioned secrets and dynamic credentials require genuine ML-KEM envelopes. End-to-end execution remains NOT VERIFIED.
Storage target - SSE-X and encrypted vector search require genuine ML-KEM-established or wrapped keys. End-to-end execution remains NOT VERIFIED.

Store your first ML-KEM-protected secret in five lines

The snippet shows a source-linked Python SDK call shape. Route reachability, envelope execution, and equivalent behavior across other SDKs remain NOT VERIFIED:

# pip install qnsi
import base64, os
from qnsi import QnsiClient

with QnsiClient(api_key=os.environ["QNSI_API_KEY"]) as qnsi:
    secret = qnsi.vault.create_secret(
        name="payments-hmac-key",
        payload_b64=base64.b64encode(b"...").decode(),
        algorithm="ml-kem-768",  # FIPS 203 envelope
    )

Proof, not promises: 240/240 ACVP on two independent implementations

NIST publishes ACVP vectors for checking implementation outputs. QNSI's published artifact records its stated ML-KEM vector results for liboqs and noble; that artifact does not prove runtime provider selection, cross-verification, or deployment behavior, which remain NOT VERIFIED.

The evidence is public and re-runnable, not a badge: live ACVP conformance results with an integrity digest at qnsi.heossi.com/verify/conformance, per-algorithm detail at /algorithms/ml-kem.

The rest of the finalised family is one API call away in the same KMS: ML-DSA (FIPS 204) for signatures on the same Module-LWE foundation, SLH-DSA (FIPS 205) hash-based for the most conservative security assumption, and FN-DSA (draft pending) tracked for the day it lands.

Start now

A workspace can be used to inspect the KMS and Vault surfaces at https://cloud.qnsi.heossi.com/auth?mode=signup. A successful call does not independently prove ML-KEM envelope execution or deployment-wide coverage.

Migrating an estate rather than an app? Talk to a QNSI architect at /contact - we will map your key-exchange inventory to a policy tier and a timeline.