Composite Interoperability Without Guesswork: X25519 + ML-KEM on QNSI

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 serious PQC deployment guide tells you to pair ML-KEM with X25519 in a hybrid handshake. Your board tells you to be quantum-safe. And CNSA 2.0 tells national-security systems the end state is pure post-quantum. Teams read those three signals as a contradiction and do the one thing that is actually wrong: nothing - while harvest-now-decrypt-later adversaries record their traffic today to decrypt it the day a quantum computer arrives.

There is no contradiction. Composite interoperability is an explicit boundary, while QNSI's primary target remains PQC-native. Production transport negotiation, complete policy enforcement, dual-control effects, and audit ingestion remain NOT VERIFIED.

Hybrid key exchange in 90 seconds

A hybrid key exchange runs a classical exchange (X25519) and a post-quantum one (ML-KEM-768, FIPS 203) in parallel, then feeds both shared secrets through a key-derivation function. The session key depends on both inputs, so an attacker has to break both algorithms to read the session. The construction stays secure as long as either one holds.

That single 'OR' covers both transition failure modes. A future quantum computer breaks X25519 - the ML-KEM leg stands. A flaw surfaces in the young lattice code - the twenty-five-year-tested X25519 leg stands, exactly the scenario the SIKE break of 2022 taught the industry to respect. Worst case, you fall back to precisely the security you run today; every other case, you gain quantum resistance for roughly a kilobyte more handshake.

And this is not exotic. X25519MLKEM768 is what major browsers and CDNs already negotiate at internet scale, NIST permits hybrid key establishment, and CNSA 2.0 points national-security systems at eventual pure PQC. Hybrid now, pure PQC on your schedule - the debate is settled; what remains is execution.

The hard part is the years in between

The math is settled; the migration is not. You will run a mixed estate for years: some clients negotiate hybrid, some cannot yet; some data carries a 25-year confidentiality horizon and deserves the strongest posture now; and your regulator wants proof of the posture at every step, not a slide about intentions.

That makes composite interoperability a governance problem. QNSI source defines transport, policy, and evidence contracts; production negotiation, complete enforcement, and evidence ingestion remain NOT VERIFIED.

Production composite negotiation is NOT VERIFIED

QNSI's primary mode is PQC-native. X25519MLKEM768 is permitted only as an explicitly selected composite-interop boundary with separate labelling, audit, and metering; it is never an automatic fallback. Production negotiation on the public edge is NOT VERIFIED. The command below is an unexecuted verification procedure, not proof.

# Verification procedure only; no successful negotiation is asserted
echo | openssl s_client -connect api.qnsi.heossi.com:443 \
  -servername api.qnsi.heossi.com -groups X25519MLKEM768 2>&1 | grep 'group:'

PQC-native policy with explicit composite interoperability

Underneath the channel, QNSI governs which algorithms may exist at all. Crypto policy is set per tenant across four tiers - default, strict, maximum, government - and enforced at the point of key generation and on every subsequent operation. The default tier opens the full catalogue: 87 PQC algorithms, 24 KEMs and 63 signatures across 13 families.

When a workload is ready for a stricter post-quantum posture, policy narrows the allowed algorithms. A government-tier HSM requirement fails closed unless a live-qualified custody path is active; selecting the tier alone does not prove hardware routing.

import { QnsiClient } from "@heossihq/qnsi";

const qnsi = new QnsiClient({ apiKey: process.env.QNSI_API_KEY! });

// Key generation is policy-governed per tenant. On maximum/government
// tiers, anything weaker than these is rejected at this call:
const kem = await qnsi.kms.createKey({ algorithm: "kyber-1024", purpose: "kem" }); // ML-KEM-1024
const sig = await qnsi.kms.createKey({ algorithm: "dilithium-5", purpose: "signing" }); // ML-DSA-87

Source defines maker-checker and ML-DSA audit contracts for policy changes. Complete requester/approver separation, change application, audit ingestion, and independent reconstruction remain NOT VERIFIED.

Don't trust one implementation either

Hybrid protects you from an algorithm failing. QNSI applies the same logic to the code: the platform's 87 algorithms run on liboqs, with @noble/post-quantum as an independent second implementation cross-verifying the 18 overlapping FIPS algorithms on the higher policy tiers. A bug in one library is caught at runtime by the other - the SIKE lesson, applied one layer down.

Find your classical stragglers first

You cannot sequence hybrid-to-pure without knowing where classical-only key exchange and signing still live. QNSI's CBOM source defines 11 cloud-vendor connector families and 36 inventory source types, readiness scoring, and CycloneDX export. Complete connector execution and observed estate coverage remain deployment-specific.

Start now

Create a Free Forever tenant at https://cloud.qnsi.heossi.com/auth?mode=signup - production edge negotiation is NOT VERIFIED, and you can mint ML-KEM and ML-DSA keys in minutes with the SDKs (npm @heossihq/qnsi, PyPI qnsi, Go, Rust, JVM) or the CLI. Developer plans start at $149/month; policy tiers, dual-control, and HSM roots come with enterprise plans.

Running a regulated estate and need the hybrid-to-pure timeline mapped against your mandates? Talk to an architect at /contact.