Turing Award Highlights Quantum Threat: How Go’s New Post‑Quantum Crypto Plans Guard Against the Coming Collapse

Hello, I’m Tony Bai. Yesterday (March 18, 2026) the ACM A.M. Turing Award was announced, honoring Charles H. Bennett and Gilles Brassard for their pioneering work in quantum cryptography and quantum information science.

Your data is being stored by hackers for later decryption

To understand the Go team's actions, we first need to see why post‑quantum cryptography (PQC) is required. Today most HTTPS traffic, JWT authentication, and Git commit signatures rely on RSA or ECC algorithms, whose security assumes the hardness of integer factorisation and discrete logarithms.

In 1994 Peter Shor proved that a sufficiently large quantum computer can break RSA and ECC exponentially faster.

While quantum computers are not yet commercially available, elite hackers and nation‑state APT groups are already employing a “Store Now, Decrypt Later” (SNDL) strategy: they capture RSA/ECC‑encrypted data now and plan to decrypt it once quantum computers mature.

In response, NIST has urgently released a draft FIPS standard for PQC, and Go, as a core language for cloud‑native infrastructure, is positioned at the front line of this defense.

Go team’s quantum‑resistant strategy

Go’s core team has long defined a strategy for introducing new cryptographic algorithms. In the Go issue crypto: post-quantum support roadmap (Issue #64537), security lead Roland Shoemaker and cryptography expert Filippo Valsorda outlined three iron‑clad rules:

Never be a guinea‑pig: the standard library only implements algorithms that are stable and widely vetted in production (e.g., WebPKI, TLS). Experimental half‑finished schemes are rejected.

Introduce “on‑demand”: PQC algorithms are split into key‑encapsulation mechanisms (KEM) and digital signatures, and are added only when needed.

Internal testing before public release: new PQC code runs for several versions in the internal package to iron out misuse pitfalls before becoming a public API.

Following this philosophy, Go 1.24 merged proposals #70122 and #69985, quietly adding a hybrid key‑exchange that combines ML‑KEM (Kyber) with X25519 in the networking stack (ML‑KEM was experimental since Go 1.23). This means HTTPS services built with the latest Go already have built‑in resistance to future quantum eavesdropping.

The next step is the digital‑signature side. In Go issue crypto/mldsa: new package (Issue #77626), Filippo proposed exposing the ML‑DSA (NIST FIPS 204) API in Go 1.27.

Minimal parameter set isolation

ML‑DSA defines three security levels, each represented by a simple function returning a Parameters object:

func MLDSA44() Parameters // security ≈ AES‑128
func MLDSA65() Parameters // security ≈ AES‑192
func MLDSA87() Parameters // security ≈ AES‑256

Developers only need to call the appropriate function, no complex parameter handling.

Avoiding semi‑expanded keys

When creating a private key, the API requires only a short seed byte array, not the larger “semi‑expanded keys” used elsewhere.

“Semi‑expanded keys are a terrible format: larger, slower to load, and more dangerous. We only support seed‑derived keys.” – Filippo

This reflects Go’s consistent security philosophy: if a format can be misused by developers, the API eliminates it.

Handling the external‑μ pre‑hash challenge

Traditional signatures hash the message first (e.g., SHA‑256) then sign. ML‑DSA requires a more complex construction: H(H(pubkey) || 0x00 || context || message). Rather than breaking the existing crypto.Signer interface, Go introduced a virtual placeholder constant crypto.MLDSAMu of type Hash. It cannot be instantiated; calling New() on it panics. Instead, it is passed to SignerOpts as a signal, preserving backward compatibility.

Why ML‑DSA is not yet in X.509 certificates

Developers ask why the API is ready but TLS still does not accept ML‑DSA certificates. Filippo explains the physical bottleneck: a TLS handshake with ML‑DSA‑87 would increase the handshake size to about 19 KB, compared to a few hundred bytes for RSA and a few dozen for ECC. This would cause massive overhead on weak networks, potentially leading to large‑scale packet loss and latency spikes.

“If we shove ML‑DSA‑87 into TLS, the handshake packet balloons to 19 KB!” – Filippo

Thus, the Go team prefers to wait for better protocols (e.g., Merkle‑Tree certificates) rather than force a “fat” signature into the existing lightweight TLS tunnel.

Conclusion: Embracing sound engineering in an uncertain future

The Turing Award to quantum cryptography underscores a global shift. Go’s roadmap first tackles the SNDL threat with ML‑KEM, then introduces a carefully designed crypto/mldsa package, while deliberately avoiding premature integration of large signatures into TLS. This demonstrates Go’s deep control over engineering efficiency, security, and network physical constraints.