ML-DSA-65 in production: post-quantum signatures for regulated AI

ML-DSA-65 — the module-lattice signature scheme NIST standardized as FIPS 204 in August 2024 — is the post-quantum primitive that anchors every Hive receipt. This page is the production reference: parameters, performance, key management, and migration patterns.

What ML-DSA-65 is

ML-DSA stands for Module-Lattice-based Digital Signature Algorithm. It is one of three signature schemes NIST selected for standardization in its post-quantum cryptography project. The 65-parameter set targets Category 3 security — roughly equivalent to AES-192 against a quantum adversary using Grover's algorithm and a classical adversary using best-known cryptanalysis.

It is descended from CRYSTALS-Dilithium, the algorithm submitted to NIST's PQC competition. The standardized FIPS 204 version differs in some parameter choices and the inclusion of the deterministic-signing option. For Hive receipts we use deterministic signing — every signature on the same message is identical — to make signature replay attacks easier to detect.

Parameters and security level

Performance benchmarks

Measured on a single core of an AMD EPYC 7763 (3.5 GHz, AVX2):

For comparison: Ed25519 sign is ~0.05 ms and verify is ~0.10 ms. ML-DSA-65 is roughly 8× slower for signing and 2× slower for verification — manageable overhead for receipt issuance but worth budgeting for in high-throughput workloads.

Key management

The 4032-byte secret key is too large to fit in most HSM key slots designed for ECDSA keys, and many existing HSMs do not yet support ML-DSA at all. Hive's production deployments use one of three patterns:

• Software-only HSM — secret key wrapped under an HSM-resident KEK; signing happens in a hardened user-space process. Acceptable for most regulated workloads when paired with attestation.
• Native PQ-HSM — vendors with native FIPS 204 support: AWS KMS PQC preview, Thales Luna PQC firmware, Entrust nShield with PQC module. Recommended for sovereign-grade deployments.
• SE/TPM-bound — secret key bound to a hardware Secure Element on validator nodes. Used in MAPET validator infrastructure.

Why dual-signature with Ed25519

Every Hive PQ-tier receipt carries both an Ed25519 signature and an ML-DSA-65 signature. This is deliberate. Ed25519 is universally supported today, has a 30-year deployment track record, and is fast enough to verify in any environment. ML-DSA-65 is the post-quantum future but its software ecosystem is still maturing.

Dual-signature buys us two things: (1) immediate compatibility with classical-only verifiers — they ignore sig_dsa and check sig_classical; (2) defense-in-depth — an adversary must break both schemes to forge a receipt, and the schemes are based on different hard problems (elliptic-curve discrete log vs. module learning-with-errors).

Migration patterns

Most teams migrating to post-quantum receipts move through three phases:

1. Shadow phase. Issue both classical and post-quantum signatures; verifiers still check classical. Run for 30 days to confirm no operational regressions.
2. Verify phase. Verifiers check both signatures. Any receipt that fails post-quantum verification is logged for investigation but does not block the transaction.
3. Enforce phase. Verifiers reject receipts that fail post-quantum verification. Classical signature is retained for legacy interop only.

The SDK ships with a profile flag that toggles between phases without code changes.

Production libraries