ML-DSA on QNSI: Signature Contracts and Evidence Boundaries

Everything you sign is on a clock

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.

Your code-signing roots, TLS certificate chains, JWTs, and audit logs all rest on RSA, ECDSA, or EdDSA - and Shor's algorithm breaks all of them outright on a cryptographically-relevant quantum computer. Signatures are the nastier half of the quantum problem: unlike harvest-now-decrypt-later, forgery needs no recorded traffic. The day the machine exists, an attacker holding only your public key can mint valid signatures for firmware, releases, and tokens you have not shipped yet. Anything that must still be trusted in 2030 - signing roots, update chains, archival logs - is a today problem, and CNSA 2.0 already requires new national-security systems on post-quantum algorithms from January 2027.

The standardized replacement is ML-DSA (FIPS 204). The 60-second explanation below is followed by QNSI source contracts; complete KMS signing, cross-verification, audit ingestion, and deployment behavior remain NOT VERIFIED.

The 60-second concept: ML-DSA (FIPS 204)

ML-DSA - formerly CRYSTALS-Dilithium, finalized by NIST in August 2024 - is the primary post-quantum digital signature standard. It is lattice-based (Module-LWE and Module-SIS), so its security does not rest on the factoring and discrete-log problems Shor demolishes. Where its sibling ML-KEM (FIPS 203) protects confidentiality - nobody can read it - ML-DSA protects authenticity and integrity: the right party produced this, and it has not changed. A quantum-safe stack needs both.

FIPS 204 defines three parameter sets; the sizes are fixed by the standard:

ML-DSA-44 - NIST security level 2, ~2,420-byte signatures. The compact choice for high-volume token and JWT signing.
ML-DSA-65 - level 3, ~3,309-byte signatures. The balanced production default.
ML-DSA-87 - level 5, ~4,627-byte signatures. The CNSA 2.0 selection for national-security and government-grade workloads.

Rule of thumb: if the risk is someone reading your data, you need a KEM (ML-KEM). If the risk is someone forging or tampering with it, you need a signature (ML-DSA). A migration that stops at key exchange is half a migration.

Source-linked KMS signing contract

This unexecuted snippet illustrates source-linked key-creation, signing, and verification call shapes. Route reachability, primitive execution, and deployment behavior remain NOT VERIFIED:

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

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

// Create a quantum-safe signing key - ML-DSA-65 (FIPS 204)
const key = await client.kms.createKey({ purpose: "signing", algorithm: "dilithium-3" });

// Sign a release artifact
const payload = new TextEncoder().encode("sha256:9f2c1a… release-2026.07");
const signature = await client.kms.sign(key.keyId, payload);

// Verify - true only for the byte-identical payload
const valid = await client.kms.verify(key.keyId, payload, signature);

QNSI source defines liboqs and noble provider contracts, audit ingestion, rotation, BYOK, and 8 capability-gated BYOHSM connectors. Runtime cross-verification, audit effects, complete governance, and deployment behavior remain NOT VERIFIED. The current escrow route is not threshold recovery and is not presented as available; no customer HSM is live-qualified.

Related call shapes appear across SDK source surfaces, the CLI, and MCP packages. Route alignment and equivalent deployment behavior across those surfaces remain NOT VERIFIED.

Conformance is published, not asserted: QNSI's NIST ACVP results for FIPS 203/204/205 are live and re-runnable at qnsi.heossi.com/verify/conformance.

Where teams evaluate ML-DSA first

Code and firmware signing - the longest-lived trust anchors migrate first, because a future forgery attacks artifacts you signed years earlier.
TLS certificate chains - QNSI's required design pairs PQC key establishment with PQC signatures; deployment execution remains NOT VERIFIED.
JWTs and auth tokens - ML-DSA-44 is a compact parameter-set candidate; QNSI token-path execution remains NOT VERIFIED.
Audit trails - source defines ML-DSA root-signing; complete ingestion, publication, and reconstruction remain NOT VERIFIED.
Compliance evidence - source defines framework mappings and signed-artifact contracts; generation, signing, provenance, and independent verification remain NOT VERIFIED.

Parameter choice is a policy, not a code review

QNSI policy source defines permitted signature sets by tier and maker-checker contracts for policy changes and key revocation. Complete enforcement and deployment-specific approval behavior remain NOT VERIFIED.

Diversity is there when you want a hedge: alongside ML-DSA, QNSI ships SLH-DSA (FIPS 205), the conservative hash-based option for roots you cannot afford to re-key, inside a catalog of 63 signature algorithms across 13 families - with FN-DSA tracked for adoption when FIPS 206 finalizes. Swapping later is a policy change, not a re-integration.

Start signing quantum-safe today

Use the workspace to inspect ML-DSA call surfaces, but treat successful responses as insufficient proof of primitive execution. Complete KMS signing behavior remains NOT VERIFIED.

Migrating a signing hierarchy - code signing, PKI, token issuance - is a design conversation worth having early. Talk to a QNSI architect at /contact.