Read this first
Go 1.27 (August 2026) adds crypto/mldsa, a standard-library implementation of the ML-DSA post-quantum signature scheme (FIPS 204), with the MLDSA44, MLDSA65, and MLDSA87 parameter sets. crypto/x509 now handles ML-DSA keys, public keys, and signatures, and crypto/tls now offers ML-DSA signature schemes in TLS 1.3. It follows crypto/mlkem, which landed the ML-KEM key exchange in Go 1.24. For a Go service, adding post-quantum authentication is now closer to a version bump than a project.
For most of the post-quantum transition, using the new algorithms meant reaching for a third-party library: a crate, a fork, a wrapper around a reference implementation, often unmaintained, rarely audited, and always one more dependency to justify. That is exactly the friction that keeps migrations on the whiteboard. Go 1.27 removes a large piece of it for one ecosystem. The signature side of post-quantum cryptography is now in the standard library.
What actually shipped
- crypto/mldsa: a new package implementing ML-DSA (FIPS 204), the lattice-based signature standard, with all three parameter sets, MLDSA44, MLDSA65, and MLDSA87, trading signature and key size for security level.
- crypto/x509: support for ML-DSA private keys, public keys, and signatures, so certificates can carry post-quantum signatures.
- crypto/tls: ML-DSA signature schemes in TLS 1.3 (MLDSA44, MLDSA65, MLDSA87), so a handshake can be authenticated with a post-quantum signature, not just protected by a post-quantum key exchange.
This is the second half of the pair. Go 1.24 already added crypto/mlkem for ML-KEM (FIPS 203), the key-establishment side that protects a session against harvest-now-decrypt-later. ML-DSA is the authentication side: proving who you are with a signature a quantum computer cannot forge. With both in the standard library, a Go service can run a fully post-quantum TLS 1.3 handshake, key exchange and authentication, without leaving the platform.
Why it matters more than one release note
Defaults decide migrations. When a post-quantum primitive lives in a niche library, adopting it is a decision someone has to make, defend, and maintain. When it lives in the standard library of a language that runs a large share of the internet's infrastructure, adopting it becomes the path of least resistance, and the reviewers stop asking why you added a dependency. This is the same movement we wrote about on the wire, where ML-KEM became the browser default: the algorithms are leaving the specialist ghetto and becoming ambient. Signatures were the laggard, because the migration story for authentication (certificates, chains, roots) is harder than for key exchange. Putting ML-DSA in crypto/x509 and crypto/tls is how that starts to move.
The point
Post-quantum signatures just became a standard-library import for one of the internet's busiest server languages. The barrier to post-quantum authentication in Go dropped from find-and-vet-a-library to upgrade-and-configure. That is the kind of change that turns a migration from a project into a default.
If you run Go services, the practical read: on 1.27 you can begin testing ML-DSA in TLS and issuing certificates with post-quantum signatures, and you should inventory where your authentication still rests on RSA or ECDSA, the algorithms NIST plans to disallow after 2035. The tools are now in the box. What remains is knowing where the old signatures live, which is a cryptographic inventory problem.
References
- Go 1.27 release notes (go.dev) - crypto/mldsa, and the crypto/x509 and crypto/tls ML-DSA additions.
- crypto/mldsa proposal, golang/go#77626 (github.com) - the package design and parameter sets.
- FIPS 204, ML-DSA (csrc.nist.gov) - the standard the package implements.
- quantakrypto: build a CBOM with qScan - finding where your signatures live.