Quantum-Safe Cryptography for AI Commerce: ML-DSA-65 + Hybrid Signatures

The problem

The cryptography securing nearly all digital commerce today — RSA, ECDSA, HMAC — faces an existential threat. Not in some distant future. The threat is active right now, even before a single cryptographically relevant quantum computer exists. The attack is called “harvest now, decrypt later” (HNDL). Adversaries intercept and archive encrypted communications today, store the ciphertext, and decrypt years later once quantum computing reaches sufficient capability. The U.S. Department of Homeland Security, the UK NCSC, ENISA, and the Australian Cyber Security Centre all base their post-quantum guidance on the premise that this is happening now. Market consensus puts the probability that quantum computers break RSA-2048 before 2030 at 39%.

AI commerce is uniquely vulnerable. Classical e-commerce uses ephemeral session keys that last minutes. AI agent credentials persist for months or years. An AP2 Intent Mandate cryptographically authorizes an agent to spend real money on behalf of a user — if the signature is forged, real money moves. Audit trails must remain tamper-evident for SOC 2, GDPR, and PCI DSS compliance over multi-year retention. Agent-to-agent trust chains are only as strong as their weakest signature. The 144:1 NHI-to-human ratio means there is a target-rich environment for HNDL, and every credential signed with classical-only signatures today is a hostage in cold storage.

NIST published FIPS 204 (ML-DSA-65) on August 13, 2024 as the post-quantum digital signature standard. The hybrid model — every signature carries both a classical algorithm (the protocol partner requires it) and ML-DSA-65 (future-state security requires it) — is the architecture that survives the next decade. This walks through the implementation: the HNDL attack model, ML-DSA-65 key generation and signing, the hybrid verification logic for AP2 and ACP, and the 4-phase migration from classical-only to hybrid.

What most people get wrong

Mistake one: “we will migrate when quantum computers actually arrive.” The math is asymmetric. Cost of adding quantum-safe signatures to a system with zero deployed clients: days. Cost of migrating a deployed system with millions of issued credentials: engineering years. An AI agent credential issued in 2026 with a 3-year validity expires in 2029. The optimistic threshold for cryptographically relevant quantum computers is 2030. Margin of safety: 1 year or less. The HNDL attacker who captured the credential issuance traffic in 2026 may be able to reconstruct the signing key in 2030 and mint counterfeit credentials before yours have expired.

The fix is to start hybrid from day one. The cost is trivial. The cost of not is enormous. NIST has set concrete deadlines: RSA, ECDSA, EdDSA, and Diffie-Hellman deprecated by 2030, completely disallowed by 2035. The EU mandates transition by end of 2026 for critical systems and full enforcement by 2031.

Mistake two: using OR logic instead of AND logic in the verification. A naïve hybrid model verifies “classical OR quantum-safe” — accept if either passes. That sounds safer but is strictly weaker than classical-only. An attacker who breaks ML-DSA-65 can forge signatures that have valid quantum-safe proofs and trivial classical proofs, and the verifier accepts. The correct logic is conjunction: both must verify, every time. The classical signature satisfies the protocol partner’s spec (Google AP2 requires ECDSA, Stripe ACP requires HMAC, JWT requires RS256/ES256). The ML-DSA-65 signature future-proofs the same operation. Either failure rejects the operation:

async verifyHybrid(payload: string, sig: HybridSignature): Promise<void> {
  const classicalOk = await verifyClassical(payload, sig.classical, sig.protocol);
  const quantumOk = await verifyMLDSA65(payload, sig.quantum, sig.quantumPublicKey);

  // AND, not OR — both must verify
  if (!classicalOk || !quantumOk) {
    throw new SignatureError({
      classical: classicalOk,
      quantum: quantumOk,
      reason: 'hybrid_verification_failed'
    });
  }
}

A working approach

Four parts: pick the right NIST standard, generate the keys, sign with hybrid, verify with conjunction.

1. ML-DSA-65 is the signature standard. NIST published three post-quantum standards on August 13, 2024:

• FIPS 204 (ML-DSA-65) — Module-Lattice digital signatures. Security level 3 (~128-bit equivalent). 1.3KB public key, 2.5KB secret key, 3,309-byte signature. Roughly 3ms sign/verify. This is what you use for agent credentials, mandates, and webhook signatures.
• FIPS 203 (ML-KEM) — Key encapsulation, replaces RSA/ECDH for key exchange. Not used directly for signatures.
• FIPS 205 (SLH-DSA) — Stateless hash-based signatures. Conservative fallback if lattice assumptions break. Larger signatures (~7.8KB), slower, but no lattice assumption.

ML-DSA-65 survived 8 years of public cryptanalysis. It is the primary algorithm.

2. Key generation runs ML-DSA-65 alongside the classical algorithm:

import { ed25519 } from '@noble/curves/ed25519';
import { ml_dsa65 } from '@noble/post-quantum/ml-dsa';
import { p256 } from '@noble/curves/p256';

interface HybridKeyPair {
  classical: { publicKey: Uint8Array; secretKey: Uint8Array };
  quantum: { publicKey: Uint8Array; secretKey: Uint8Array };
  classicalAlgorithm: 'Ed25519' | 'ECDSA-P256' | 'HMAC-SHA256';
}

async function generateHybridKeys(
  classicalAlgorithm: 'Ed25519' | 'ECDSA-P256'
): Promise<HybridKeyPair> {
  const seed = crypto.getRandomValues(new Uint8Array(32));

  const classical = classicalAlgorithm === 'Ed25519'
    ? { secretKey: seed, publicKey: ed25519.getPublicKey(seed) }
    : { secretKey: seed, publicKey: p256.getPublicKey(seed) };

  const { publicKey: pqPk, secretKey: pqSk } = ml_dsa65.keygen(seed);

  return {
    classical,
    quantum: { publicKey: pqPk, secretKey: pqSk },
    classicalAlgorithm
  };
}

3. Hybrid signing. The shared CryptoService is protocol-agnostic; the classical algorithm is parameterized by protocol (ECDSA for AP2, HMAC for ACP, Ed25519 for Visa TAP / DIDs):

async sign(
  data: object,
  protocol: 'ap2' | 'acp' | 'tap',
  keys: HybridKeyPair
): Promise<HybridSignature> {
  const payload = canonicalSerialize(data);

  const classical = protocol === 'ap2'
    ? await signECDSA(payload, keys.classical.secretKey)
    : protocol === 'acp'
      ? await signHMAC(payload, this.secrets.stripeWebhook)
      : await signEd25519(payload, keys.classical.secretKey);

  const quantum = await signMLDSA65(payload, keys.quantum.secretKey);

  return {
    classical,
    quantum,
    protocol,
    classicalAlgorithm: keys.classicalAlgorithm,
    quantumAlgorithm: 'ML-DSA-65'
  };
}

4. Database storage keeps both signatures alongside the algorithm declaration:

CREATE TABLE unified_intent_mandates (
  id UUID PRIMARY KEY,
  -- ...
  classical_signature TEXT NOT NULL,
  classical_algorithm TEXT NOT NULL,  -- 'ECDSA-P256' | 'HMAC-SHA256' | 'Ed25519'
  quantum_signature TEXT NOT NULL,
  quantum_algorithm TEXT NOT NULL DEFAULT 'ML-DSA-65',
  signed_at TIMESTAMPTZ DEFAULT NOW()
);

Verification re-checks both against the stored algorithms. The performance overhead is roughly 2ms per operation — invisible at 50–200ms API latencies, but the credential is signed once and verified many times, so amortized cost is even smaller.

The protocol mapping that ships in the book:

Layer	Protocol	Classical	Post-quantum
Identity	Visa TAP / DID	Ed25519	ML-DSA-65
Authorization	Google AP2	ECDSA P-256	ML-DSA-65
Execution	Stripe ACP webhooks	HMAC-SHA256	ML-DSA-65
JWT	Standard	RS256 / ES256	ML-DSA-65

Every layer uses the same CryptoService interface. Adding a new protocol means adding a signClassical branch and one row to the algorithm registry. Zero changes elsewhere.

Where this scales

The walkthrough above is the implementation spine. The full book covers six more dimensions:

• HNDL attack analysis — concrete intelligence-agency confirmations, target prioritization, the timeline math for credentials issued today vs. the NIST 2030/2035 deadlines.
• NIST standards in depth — ML-DSA parameter sets (44, 65, 87), security levels, the journey from 69 submissions (2016) to 3 finalized standards (2024), and why ML-DSA-65 specifically.
• Hybrid verification for both protocols — AP2 mandate signing flow (ECDSA + ML-DSA-65), ACP webhook verification (HMAC + ML-DSA-65), the signature_algorithms column that lets verifiers handle multiple versions.
• 4-phase brownfield migration — Inventory & Assessment (weeks 1–4), Dual-Issue (months 1–3), Mandatory Hybrid (months 3–6), Classical Sunset (months 6–12). Signature versioning and backward compatibility throughout.
• Crypto agility — algorithm-agnostic CryptoConfig, pluggable Algorithm Registry, the upgrade path that lets you swap ML-DSA-65 for ML-DSA-87 or SLH-DSA without touching core logic.
• The compliance regulatory timeline — EU mandate (transition by end of 2026, full enforcement 2031), NIST deprecation (2030) and disallowance (2035), the regulator-by-regulator forecast.

Every code example has been built against @noble/post-quantum and runs inside the Cloudflare Workers V8 isolate. The 2ms overhead, the 3,309-byte signature size, the protocol mapping — these are measured numbers from a production system.

Included with the book

• fips-204-compliance-checklist.md — the FIPS 204 compliance checklist used to verify ML-DSA-65 deployments. Parameter set verification, NIST test-vector pass criteria, canonicalization rules, and the dual-signature audit. Drop in as the basis for the deployment review.

Get the full picture

Readers of this also chose

Questions readers ask

Why ML-DSA-65 instead of ML-DSA-44 or ML-DSA-87?

ML-DSA-65 is Security Level 3 (roughly equivalent to AES-128 in classical terms). ML-DSA-44 (Level 2) is faster and smaller but the security margin is thinner. ML-DSA-87 (Level 5) is more conservative but the signature is larger and slower. Level 3 is the NIST-recommended baseline for new deployments. For credentials with a 10+ year validity, ML-DSA-87 is justifiable; for typical agent credentials with a 1–3 year validity, ML-DSA-65 is the right point on the curve.

What about Falcon (FN-DSA)?

NIST is standardizing Falcon as FN-DSA (FIPS 206 expected 2026). It produces smaller signatures (~666 bytes vs 3,309 for ML-DSA-65) but requires floating-point arithmetic with strict precision, which makes constant-time implementation hard. ML-DSA-65 is the safer choice today; Falcon may become the right pick for size-constrained deployments once a constant-time implementation hardens.

Does the size increase break my system?

A 3,309-byte signature is roughly 51x larger than a 64-byte ECDSA signature. The practical implications: API payloads grow ~4.5KB Base64, database columns must be TEXT (not VARCHAR(128)), and JWT-style headers become substantially larger. The book covers the deployment changes (column migrations, header strategy, alternative storage formats). For typical API operations, the impact is invisible.

Should I worry about signature OR verification (not AND)?

Yes. The OR pattern is strictly weaker than classical-only, because an attacker can sign with whichever algorithm is easier to break. Always AND. The book includes the verification code and the test vectors that catch OR-logic bugs.

What's the refund policy?

Lemon Squeezy's standard refund window applies. The refund link is in the receipt email.