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

ML-DSA-65 is the module-lattice signature scheme NIST standardized as FIPS 204 in August 2024, and it's 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, meaning 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. That's 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. First, immediate compatibility with classical-only verifiers: they ignore sig_dsa and check sig_classical. Second, 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