The terms on this page
- ML-DSAModule-Lattice-based Digital Signature Algorithm
- the standardised post-quantum replacement for RSA and ECDSA signatures, published as FIPS 204
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab) are defined in the glossary.
Read this first
Go 1.27, released on 19 August 2026, moved ML-DSA signing into the standard library. Its X.509 package can parse and create ML-DSA keys and signatures, and its TLS package can negotiate ML-DSA-44, ML-DSA-65, or ML-DSA-87 signatures in TLS 1.3. That removes a library gap for Go teams. It does not remove the certificate, interoperability, conformance, or deployment work.
What Go 1.27 actually added
The new crypto/mldsa package implements the three parameter sets defined by FIPS 204: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The release also connects those primitives to the formats and protocols where application teams need them.
| Go package | New capability | What a team can test |
|---|---|---|
| crypto/mldsa | Key generation, signing, and verification for all three FIPS 204 parameter sets | Application signatures and verification behavior |
| crypto/x509 | Parsing, marshaling, and verification of ML-DSA keys and signatures | Certificate requests, chains, and trust-store compatibility |
| crypto/tls | ML-DSA-44, ML-DSA-65, and ML-DSA-87 signature schemes in TLS 1.3 | Handshake behavior between controlled clients and servers |
The package documentation makes the size change concrete. An ML-DSA-44 public key is 1,312 bytes and its signature is 2,420 bytes. Those values are not a footnote for a protocol team. They affect certificates, handshake messages, buffers, logs, and any system that assumed a compact classical signature.
Who is affected
This release matters first to Go teams that own both sides of a connection or can run a controlled compatibility trial. Internal service meshes, device fleets, private certificate authorities, and test environments can now prototype ML-DSA without maintaining a separate signing implementation. Teams evaluating a broader post-quantum migration also have a standard library target for inventory and performance work.
It matters less immediately to public web services. A server cannot unilaterally make an ML-DSA certificate useful. Issuing systems, client trust stores, middleboxes, monitoring tools, and every verifier in the path must understand the certificate and signature scheme. Go adding the code is an important implementation milestone, not ecosystem-wide readiness.
A standard library is not a certificate ecosystem
The safest way to read the change is as a new testable dependency boundary. Go now supplies the primitive and protocol wiring. Your organization still owns certificate policy, key custody, trust distribution, fallback behavior, and evidence that the complete system behaves as intended. The distinction is the same one described in our guide to ML-DSA: an approved algorithm is necessary, but the implementation and operating context determine whether a deployment is sound.
There is also a specific compliance caveat. The crypto/mldsa documentation says ML-DSA is unavailable with version 1.0.0 of the Go Cryptographic Module and becomes available with module version 1.26.0 or later. Teams with a FIPS boundary should verify which module their build actually uses before treating the package as available. The FIPS 140-3 boundary and the FIPS 204 algorithm standard answer different questions.
What to test before enabling it
- Confirm which ML-DSA parameter set matches the security level and size budget of the system.
- Generate keys through the intended production custody path, not only in a developer process.
- Issue a test certificate chain and verify every certificate, trust-store, and serialization boundary.
- Measure TLS 1.3 handshakes with real certificate chains, network limits, and observability tooling.
- Test unsupported peers and failure paths explicitly. A clean refusal is safer than an accidental downgrade.
- Record known-answer, negative, and interoperability results as part of PQC conformance testing.
Start with a bounded lab or internal service, then expand only when the evidence follows. An independent cryptographic audit can check how keys, certificates, and negotiation rules cross the application boundary. If the system will make compliance claims, align the test record with the intended certification path before production rollout.
What this changes for a migration plan
For Go estates, ML-DSA is no longer only a roadmap item or third-party experiment. Teams can attach real measurements to the decision: certificate size, handshake behavior, verifier coverage, operational failure modes, and module compatibility. That is enough to move from general awareness to a controlled engineering workstream.
Do not confuse that progress with a mandate to replace every signature today. Inventory where signatures live, identify systems that can run an end-to-end trial, and keep the rollout reversible. Our comparison of ML-DSA and SLH-DSA can help frame algorithm choices, but the first useful Go milestone is simpler: prove one complete path with the certificate chain and peers you actually operate.
References
- Go 1.27 is released, Go Blog, 19 August 2026.
- Go 1.27 release notes, including crypto/mldsa, crypto/x509, and crypto/tls changes.
- crypto/mldsa package documentation, Go standard library.
- FIPS 204: Module-Lattice-Based Digital Signature Standard, NIST.