Why use ML-DSA-87, and why KXCO's is the one to use

Use ML-DSA-87. For every new signing key, it is the best choice. It is the strongest parameter set in FIPS 204, NIST's post-quantum signature standard. It is the only ML-DSA set listed in the NSA's CNSA 2.0, where it covers every classification level. Australia's ASD prefers it and stops approving ML-DSA-65 beyond 2030. A signature is about 40 per cent larger than ML-DSA-65's and takes about half a millisecond more to make.

KXCO ships ML-DSA-87 at every layer an institution needs. That means an Apache-2.0 library on npm with signed build provenance, keys generated inside hardware security modules, and a network that accepts ML-DSA-87 signed writes. It also means a public chain that has verified ML-DSA-87 in consensus since block 4,951,111 on 6 October 2026, per the chain's public record. Anyone can check a KXCO signature without an account, a licence key or a call to us. To deploy it in your institution, request a briefing.

What ML-DSA-87 is

ML-DSA stands for Module-Lattice-Based Digital Signature Algorithm. NIST published it as FIPS 204 on 13 August 2024. It came out of a public process that NIST opened in 2016, to which 82 candidate algorithms were submitted. After three rounds NIST selected four, and ML-DSA is derived from one of them, CRYSTALS-Dilithium.

NIST states what it is for. In the words of FIPS 204, ML-DSA "is intended to protect sensitive U.S. Government information well into the foreseeable future, including after the advent of cryptographically relevant quantum computers". The standard also says "ML-DSA is believed to be secure, even against adversaries in possession of a large-scale quantum computer". It can replace the signature schemes in FIPS 186-5, the standard behind RSA and ECDSA signatures.

FIPS 204 defines three parameter sets. The number in each name comes from the dimensions of the matrix at the heart of the scheme: ML-DSA-87 works over an 8 by 7 matrix of polynomials, ML-DSA-65 over 6 by 5, and ML-DSA-44 over 4 by 4. Larger dimensions mean a harder lattice problem for an attacker, and larger keys and signatures for everyone else.

What category 5 means

NIST does not express post-quantum security as a single number of bits. It defines five categories, each tied to a reference attack on a well-understood primitive. Per NIST's evaluation criteria, category 5 means "any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 256-bit key". NIST's example is AES-256. Category 3 is pegged to a 192-bit key. Category 5 is the top of the scale, and ML-DSA-87 is the only ML-DSA set that reaches it.

FIPS 204 is candid about the nature of the claim. Each parameter set "is claimed to be at least as secure as a generic block cipher with a prescribed key size", with the resources estimated "using any realistic model of computation". It adds: "Different models of computation can be more or less realistic and, accordingly, lead to more or less accurate estimates of security strength." Security levels for lattice schemes are estimates made by careful people. Category 5 is the widest margin the standard offers against an estimate that turns out optimistic.

ML-DSA is not the same as Dilithium

Ask for FIPS 204 by name. FIPS 204 Appendix D lists where ML-DSA departs from the Dilithium submission, so a library labelled Dilithium is not necessarily producing ML-DSA signatures. The NSA's CNSA 2.0 FAQ is blunt about it: "any algorithm that is called CRYSTALS-Kyber or CRYSTALS-Dilithium but does not adhere to FIPS 203 or 204 is not CNSA 2.0 compliant."

Why signatures need to be quantum-resistant now

FIPS 204 sets out the threat in its opening section. If large-scale quantum computers are built, the security of many commonly used public-key cryptosystems "will be at risk". NIST names the signature schemes in that group: those built on factoring and on discrete logarithms, over finite fields and over elliptic curves. That covers RSA, ECDSA and EdDSA, which sign almost everything institutions rely on today.

For encryption, the familiar risk is harvest now, decrypt later: traffic recorded today is read once a quantum computer exists. Signatures fail differently. A cryptographically relevant quantum computer lets an attacker recover the private key from any public key, then sign anything under it: a payment instruction, a title transfer, a software update, a contract dated last year. Every verification key still trusted on that day is exposed, however long ago it was issued.

So the deadline for signatures is not the day such a machine is switched on. It is the day the last classical key you rely on stops being trusted, and keys live a long time.

Some keys cannot be changed once they ship

The NSA explains why it puts firmware first. Its CNSA 2.0 FAQ says: "In many firmware-signing cases the validation algorithm is not easily updated. Thus, firmware-signing algorithms are frequently locked in for the life of a system." It goes on: "a quantum-resistant root of trust may be required in the firmware years before the rest of the system upgrades to quantum-resistance."

The same logic applies well beyond firmware. A certificate authority's root key is pinned in trust stores that take years to update. A title registry, a share register or a court record is relied on for decades. A credential issued to a counterparty sits in their systems until they choose to replace it. Any key that is expensive to change should be post-quantum when it is created.

Records have to stay provable

A deed signed in 2026 may be produced in evidence in 2056. Its value rests on the signature still meaning something then. When the signature is ML-DSA-87, it rests on a standard built to survive large-scale quantum computers. When the signed record is also anchored in a public ledger at the time of signing, there is a second, independent record that it existed on that date in that form.

Why category 5 rather than category 3

ML-DSA-87 is always the best choice. NIST approves the smaller sets too, so the case rests on who will accept your signatures, for how long, and what it costs to change your mind later.

It is the level the strictest buyers name

The governments that have published the most specific guidance converge on ML-DSA-87.

• United States, national security systems. The CNSA 2.0 FAQ lists ML-DSA as the "asymmetric algorithm for digital signatures in any use case, including signing firmware and software", with the parameter instruction "ML-DSA-87 for all classification levels". No other ML-DSA set appears.
• Australia. The Australian Signals Directorate's Information Security Manual, March 2026, control ISM-1991: "When using ML-DSA for digital signatures, ML-DSA-65 or ML-DSA-87 is used, preferably ML-DSA-87." It states that "for interoperability and maintainability reasons, ML-DSA-65 will not be approved beyond 2030", and control ISM-1917 requires new cryptographic equipment, applications and libraries to support "ML-DSA-87, ML-KEM-1024, SHA-384, SHA-512 and AES-256 by no later than 2030".
• United Kingdom. The NCSC's Next steps in preparing for post-quantum cryptography says all three parameter sets "provide an acceptable level of security for personal, enterprise and OFFICIAL-tier government information". It also says the highest security level "may also be useful for digital signatures where the keys have a particularly long lifetime, such as in a root of trust".
• United States, federal standards. NIST approves all three sets. Its draft transition plan, NIST IR 8547, lists ML-DSA-87 at category 5 and 256 bits.

Read together, one level satisfies every one of them. An ML-DSA-87 key is the set CNSA 2.0 lists, the set ASD prefers and keeps approving after 2030, and the set the NCSC points to for long-lived keys and roots of trust. An ML-DSA-65 key is not the set CNSA 2.0 lists, and Australia stops approving it beyond 2030. An institution that sells to governments, or holds records governments will rely on, should sign at the level the strictest of them names.

Margin is the point for long-lived keys

The NCSC frames the trade-off well: "The level of security required can vary according to the sensitivity and the lifetime of the data being protected, the key being used, or the validity period of a digital signature." The keys institutions care about most are the ones with the longest validity: roots of trust, registry keys, keys that sign records relied on in court. For those keys, the extra margin of category 5 is cheap insurance against the estimate in FIPS 204 turning out to be optimistic.

One level is cheaper to run than two

An estate that signs at ML-DSA-65 for some uses and ML-DSA-87 for others carries two key types, two policies, two sets of size limits and a question at every verifier about which level it should accept. Standardising on ML-DSA-87 removes the question. KXCO binds the level inside every signature, as the level is inside the signature explains below, but the simplest estate to audit has one level.

Re-keying costs more than bytes

Moving a root of trust means re-provisioning devices, re-issuing certificates and persuading every counterparty to trust a new key. An institution that adopts ML-DSA-65 now for a key that must outlive 2030, and moves to ML-DSA-87 when Australia's approval of ML-DSA-65 ends, pays for that migration twice. Paying once, now, costs about 1.3 kilobytes per signature.

Existing ML-DSA-65 keys keep working

An institution that has already deployed ML-DSA-65 does not lose anything by moving. KXCO's chain verifies ML-DSA-65 at its own address, so signatures made before the move keep verifying. Every new key should be ML-DSA-87.

What category 5 costs

The cost of ML-DSA-87 is mostly size. Compute costs about the same as ML-DSA-65.

Size

The private key need not be stored at full size. FIPS 204 notes that "one can store only the 32-byte seed", which "is sufficient to generate the other parts of the private key". KXCO's library goes one step further and derives each key from a master secret under a label, so the master stays in the key store and the label versions the key.

Time

We measured both sets on 7 October 2026 on an Intel Core i7-7700K desktop processor, through kxco-post-quantum 1.8.0 on OpenSSL 3.5.6 under Node.js 26.1. The two sets ran interleaved so that any drift in the machine hit both equally: 3,000 signatures and 3,000 verifications each, repeated three times. The scripts and raw output are in the measurement record.

A category 5 signature cost about half a millisecond more to make and about 0.3 ms more to check. FIPS 204 explains why the gap is small. ML-DSA signing repeats its main loop until the result passes a check, and Table 1 gives the expected number of repetitions: 3.85 for ML-DSA-87 against 5.1 for ML-DSA-65. The larger matrix costs more per pass, and ML-DSA-87 needs fewer passes.

For almost every institutional workload, a few milliseconds per signature is invisible next to the network round trip that carries it.

On chain

On 6 October 2026 the first ML-DSA-87 institution registration on KXCO's chain carried 7,460 bytes of signed calldata and used 353,166 gas. The first ML-DSA-87 anchor used 387,954 gas. Both figures come from the transaction receipts on chain. KXCO pays the gas. Institutions never hold a token or run a node.

What to check before the first key arrives

Size is where migrations break. Check every place a key or a signature has to pass through:

• Encodings. Per FIPS 204, an ML-DSA-87 signature is 4,627 bytes: 9,254 characters in hex and 6,172 in base64. A public key is 5,184 characters in hex.
• Fixed-width fields. Database columns, message formats and file headers sized for a 64-byte ECDSA signature will truncate silently or reject.
• Headers and tokens. HTTP headers, cookies and bearer tokens carrying a signature need their size limits checked at every proxy on the path.
• Certificates and chains. A certificate chain with several ML-DSA-87 signatures grows by kilobytes per link.
• Constrained devices. Smart cards, secure elements and embedded verifiers need the memory for a public key of 2,592 bytes, per FIPS 204.

Where to use ML-DSA-87 first

Start with an inventory. The NCSC's migration timelines ask organisations to complete discovery by 2028 and to identify any "requirement to migrate any long-lived hardware roots of trust". ASD control ISM-2073 requires that "a post-quantum cryptography transition plan is developed, implemented and maintained". KXCO's kxco-pq-scan finds quantum-vulnerable cryptography in a JavaScript dependency tree and emits a CycloneDX 1.6 cryptographic bill of materials.

Then move keys in order of how long they live and how hard they are to change.

1. Roots of trust and certificate authorities. Every key below them inherits their exposure, and they are the hardest to replace.
2. Software and firmware release signing. The NSA wants software and firmware signing to "begin transitioning immediately" and to "exclusively use CNSA 2.0 by 2030". For some firmware the NSA prefers the stateful hash-based schemes LMS and XMSS. It also says "validated ML-DSA is approved for all signing use cases". It calls ML-DSA reasonable where signing needs "more signatures than can be reasonably used with a single LMS or XMSS key, or in software development environments with a distributed signing system".
3. Records with legal weight. Contracts, deeds, registers, board resolutions and regulatory filings, where the signature has to hold for as long as the record does.
4. Institutional identity between organisations. Keys that counterparties, regulators and auditors hold in their own systems.
5. Payment and settlement instructions. A forged instruction under a broken key is final once the money moves.
6. Audit evidence and machine actions. Logs, attestations and the actions of automated systems and AI agents, where the signature is the only proof of who did what.

Why KXCO's ML-DSA-87

Most post-quantum offerings are a library, or a promise on a roadmap. KXCO ships ML-DSA-87 at every layer an institution needs, it runs on KXCO's own estate, and every claim in this section can be checked from outside without asking us.

Anyone can check it on a public chain

KXCO's chain has a verification function built into the chain itself, known as a precompiled contract, at 0x4b58434f00000000000000000000000000000087. The first four bytes spell KXCO in ASCII and the last byte names the parameter set. Send it the public key, the signature and the message, and it answers 01 for a valid ML-DSA-87 signature and 00 for anything else. No account, no licence key, no SDK. A call costs nothing and changes nothing.

We ran it again for this article on 7 October 2026, at block 5,005,334, with a key and signature made a moment earlier by the published npm package. The script and its output are in the measurement record.

valid ML-DSA-87 signature                0x...0001
same signature, one bit of message changed  0x...0000
the same input sent to the ML-DSA-65 precompile  0x...0000

One bit changed and the verdict went to 00. The ML-DSA-65 precompile at 0x0b refused an ML-DSA-87 input, so the two levels never cross. The developer note prints the full code.

An auditor, a regulator or a counterparty can therefore verify a KXCO signature without trusting KXCO's servers to tell the truth about it. The kxco-verify package does the same in a browser, "with no KXCO server in the trust path", per its npm page.

Live in consensus, on every validator

The ML-DSA-87 precompiled contract went live at block 4,951,111, at 08:37:11 UTC on 6 October 2026, per the chain's public record. The chain itself runs the check. Every transaction that verifies an ML-DSA-87 signature runs the precompiled contract, and each of the four validators re-executes it before the block is final. The first ML-DSA-87 identity registered in block 4,951,125 and anchored its first attestation in block 4,951,127.

The relay that accepts institutional writes publishes the levels it accepts. On 7 October 2026 it answered:

$ curl -s https://relay.kxco.ai/intents/v2/params
{"ok":true,"verifyingRelay":"0x941217082350AC45Ab9AA035687ce16c6822b657","chainId":1111111,"legacyRelay":"0x0000000000000000000000000000000000000000","algorithms":["ML-DSA-65","ML-DSA-87"]}

The level is inside the signature

A downgrade attack tries to pass a weaker signature off as a stronger one. KXCO closes it twice.

• The level is signed. An ML-DSA-87 write signs the verifying contract, the chain, the operation, the key id, a sequential nonce and one more word, keccak256("ML-DSA-87"), before the operation's arguments. Change any element and the signature stops verifying.
• The contract reads the level from the key. It decides the parameter set from the length of the key you send, 1,952 bytes for ML-DSA-65 and 2,592 bytes for ML-DSA-87, "never from a field you set", per the published client documentation. The relay checks the declared level against the key and refuses a mismatch before any gas is spent.

Registration carries proof of possession: the new key signs its own registration, so nobody can register a key they do not hold. A key rotation is signed by the old key and the new key over one message.

Keys stay in hardware

kxco-pq-hsm generates ML-DSA-87 keys on the PKCS#11 hardware security module an institution already runs. On a token that generates ML-DSA keys, the pair is created on the token with the parameter set recorded as CKP_ML_DSA_87, and the private object is marked CKA_EXTRACTABLE=false and CKA_SENSITIVE=true. Signing happens on the token through C_Sign, so the private key never enters host memory. A stored key whose size belongs to the other parameter set is refused rather than used.

It signs the way ASD asks

FIPS 204 allows ML-DSA signing to be hedged, mixing fresh randomness into each signature, or deterministic. ASD control ISM-1992 says "the hedged variant is used whenever possible", because it "provides effective protection from certain side-channel attacks which apply to the deterministic variant". KXCO's library, kxco-post-quantum, signs hedged. Sign the same message twice with the same key and the two signatures differ, which we checked on 7 October 2026.

Open source, with provenance you can verify

The libraries are Apache-2.0 and the source is public on GitHub. Every package carries SLSA build provenance on npm, which ties the published package to the public source and the build that produced it. On 5 and 6 October 2026 KXCO released 13 npm packages carrying the category 5 level, each with that provenance. An institution can confirm the chain from source to package with npm audit signatures before anything reaches production.

Independent scoring agrees. The OpenSSF Scorecard for kxco-post-quantum read 9.2 out of 10 on 12 October 2026, and the project holds the OpenSSF Best Practices passing badge.

Graded by NIST's own test server

In September 2026 NIST's Algorithm Validation Test System demonstration server generated test vectors that nobody had seen and graded kxco-post-quantum's answers. It graded 2,130 test cases across ML-KEM, ML-DSA and SLH-DSA in every parameter set NIST offers, with zero failures, and issued demo certificate A11025. KXCO's full account sets out what a demo certificate proves.

We run it on ourselves

KXCO moved its own signing keys before asking anyone else to move theirs. KXCO's published key list at kxco.ai/.well-known/pq-keys.json names seven ML-DSA-87 signing keys across its products and its evidence root. The ML-DSA-65 keys they replaced stay listed and marked superseded, under a published rule: "Superseded kids remain listed so historical signatures stay verifiable." A signature made last month under the old key still verifies today, and so does one made today under the new key.

Each key id is the first 16 hex characters of the SHA-256 of the public key, so anyone can confirm that the key in a signature header is the key in the list. On chain, the registry reports whether an institution's key id is live, rotated or unknown.

Built and rolled out without stopping

The chain upgrade was briefed on 5 October 2026 and live in consensus on the morning of 6 October. The cryptography changed underneath a running estate: libraries, hardware keys, the network service, the contract and the chain's nodes. The nodes moved one at a time while the chain kept producing blocks. Before any validator moved, an observer node ran the new software against 6,915 live blocks, including 47 real verification transactions, and found no difference in state, according to KXCO's rollout log. Product signing keys followed on 7 October.

Ahead of the field

Ethereum's proposal for an ML-DSA verification precompile, EIP-8051, is a draft created on 15 October 2025. Its text says it "only covers NIST level II, corresponding to 128 bits of security", which is ML-DSA-44. KXCO's chain verifies ML-DSA-87 and ML-DSA-65 in consensus today, on a live network.

The matching encryption level is in the same library

CNSA 2.0 pairs ML-DSA-87 with ML-KEM-1024 for key establishment, "for all classification levels", and ASD requires support for both by 2030. The kxco-post-quantum library ships ML-KEM-1024 beside ML-DSA-87, under the same API and the same provenance. Signatures and encryption can sit at one level.

How to judge any ML-DSA-87 supplier

Use these questions on any supplier, including us. A good answer is one you can check yourself.

The dates that matter

Every major regime has now put dates on the move. The table below quotes each one from its primary source.

The nearest hard date for most institutions selling to the US government is 1 January 2027. KXCO's chain went live with ML-DSA-87 87 days before it.

Frequently asked questions

What is ML-DSA-87?

ML-DSA-87 is the strongest of the three parameter sets in FIPS 204, the Module-Lattice-Based Digital Signature Standard that NIST published on 13 August 2024. It is in security category 5, the highest NIST defines, with a 2,592-byte public key and a 4,627-byte signature per FIPS 204 Table 2. It is derived from CRYSTALS-Dilithium and is designed to stay secure against large-scale quantum computers.

NIST states in FIPS 204 that "ML-DSA is believed to be secure, even against adversaries in possession of a large-scale quantum computer". ML-DSA-87 is the parameter set with the widest margin, benchmarked against key search on a block cipher with a 256-bit key such as AES-256.

What is the difference between ML-DSA-87 and ML-DSA-65?

ML-DSA-87 is security category 5 and ML-DSA-65 is category 3. Per FIPS 204 Table 2, ML-DSA-87 has a public key of 2,592 bytes against 1,952, and a signature of 4,627 bytes against 3,309. CNSA 2.0 lists only ML-DSA-87, and Australia's ASD prefers ML-DSA-87 and stops approving ML-DSA-65 beyond 2030. Signing and verifying take a fraction of a millisecond longer. KXCO recommends ML-DSA-87 for every new key.

Does CNSA 2.0 require ML-DSA-87?

The NSA's CNSA 2.0 lists ML-DSA as the algorithm for digital signatures "in any use case, including signing firmware and software", with the instruction "ML-DSA-87 for all classification levels". No other ML-DSA parameter set is listed. For US national security systems, new acquisitions from 1 January 2027 are required to be CNSA 2.0 compliant unless otherwise noted.

Is KXCO CNSA 2.0 compliant?

KXCO ships ML-DSA-87 and ML-KEM-1024, the signature and key establishment sets CNSA 2.0 specifies, and its chain verifies ML-DSA-87 in consensus. Compliance for a national security system is established for the accredited system: the NSA expects quantum-resistant algorithms in NIAP-validated products, typically with modules validated by NIST's CMVP. KXCO's published key list states that KXCO does not claim CNSA 2.0 compliance.

Is ML-DSA the same as Dilithium?

ML-DSA is the NIST standard derived from CRYSTALS-Dilithium, and FIPS 204 Appendix D lists where the two differ. The NSA states that an algorithm "called CRYSTALS-Kyber or CRYSTALS-Dilithium but does not adhere to FIPS 203 or 204 is not CNSA 2.0 compliant". Specify FIPS 204 ML-DSA by name.

How big is an ML-DSA-87 signature?

4,627 bytes, per FIPS 204 Table 2. That is 9,254 characters in hex or 6,172 in base64. The public key is 2,592 bytes and the private key 4,896 bytes, or a 32-byte seed from which the rest can be regenerated.

Is ML-DSA-87 slow?

No. On an Intel Core i7-7700K through OpenSSL 3.5.6, KXCO measured a median of 2.1 to 2.5 ms to sign and 1.1 to 1.3 ms to verify, against 1.7 to 2.0 ms and 0.84 to 0.97 ms for ML-DSA-65. ML-DSA-87's signing loop needs fewer expected repetitions, 3.85 against 5.1, which offsets most of its larger matrix.

Should we use a hybrid signature?

National guidance differs. Australia's ASD says hybrid schemes are "not recommended, however, it is not prohibited", noting that against a quantum computer their security reduces to the post-quantum part. The UK NCSC notes "there is not yet guidance or a consensus" on secure hybrid authentication and prefers "a single migration to a fully post-quantum PKI". KXCO signs with ML-DSA alone.

Why ML-DSA rather than FN-DSA (Falcon) or SLH-DSA?

The NSA says "ML-DSA is preferred, as FN-DSA seems more susceptible to implementation errors that may affect security", and does not anticipate adding FN-DSA to CNSA 2.0. SLH-DSA, the hash-based standard in FIPS 205, "is not part of CNSA and is not approved for any use in NSS", per the CNSA 2.0 FAQ. ML-DSA is the general-purpose post-quantum signature that the strictest regimes accept.

Can a blockchain check ML-DSA-87 signatures?

Yes. KXCO's chain has checked ML-DSA-87 signatures in consensus since block 4,951,111 on 6 October 2026, per the chain's public record. The check runs in a precompiled contract at 0x4b58434f00000000000000000000000000000087. Anyone can call it through the public endpoint at no cost, using the standard eth_call method. Ethereum's proposal, EIP-8051, is a draft that covers only NIST level II, which is ML-DSA-44.

How does an institution start with KXCO?

Developers can start today with the packages on npm and the developer note. For an institutional deployment, covering keys in your HSM, registration of your institution on the chain and verified writes with gas paid by KXCO, request a briefing and we will scope it with your team.

Start with a briefing

KXCO builds post-quantum trust infrastructure: signing, key custody, verification and a public chain for anchoring evidence. It runs at ML-DSA-87 today, on KXCO's own estate, and every claim on this page can be checked from outside.

If your institution has keys that must outlive 2030, records that must stay provable for decades, or a government customer that will ask which parameter set you sign with, talk to us. We will map your signing keys to the levels your regulators name and show you the verification working on your own data.

Put ML-DSA-87 to work in your institution

Keys in your HSM, your institution registered on the chain, signatures anyone can check. We scope it with your team.