With the publication of the NIST PQ drafts FIPS 203, FIPS 204, and FIPS 205 and the beginnings of industry adoption of said algorithms (i.e. https://blog.cloudflare.com/post-quantum-for-all/, https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html, etc), we are starting to look at what post-quantum support will look like in Go.

This issue is not going to propose any specific APIs, and is instead meant to lay out the way we intend to approach decisions about what algorithms we will adopt, and the manner in which we will adopt them.

Generally, we are quite conservative about what cryptographic algorithms we choose to support. In part this is because we have a significant maintenance burden once we adopt an algorithm, but also because we want algorithms that are stable (i.e. unlikely to significantly change in the future), and are already being actively used in the wider ecosystem. There are many PQ algorithms which are still experimental, or have found no wider industry adoption as of yet, which do not meet the bar to be included in the standard library, and make more sense being implemented in third-party modules.

When thinking about what PQ algorithms we want to provide support for, the first hurdle is whether that algorithm will actually be used in the standard library itself. What I mean by this is that, at least to begin with, we don't want to introduce support for algorithms which we will not be using ourselves. This means that our choices of initial algorithms are extremely likely to be driven by the adoption decisions made for the TLS protocol (and by extension the X509 web PKI).

Additionally our initial implementations are likely to only be available internally, at least to begin with (i.e. they will not be implemented in public facing libraries which users can directly use). This gives us the opportunity to gain experience with these new algorithms before we commit ourselves to an API design that we'll likely be stuck with for a significant amount of time. Once we are confident that we fully understand the ways users are expected to handle (and mishandle) these APIs we'll propose public APIs.

What's First

The first step in our PQ implementation plan is adding support to the now widely implemented hybrid X25519/Kyber (X25519Kyber768) KEM for TLS, or a successor version, hopefully in Go 1.23. This will provide TLS client/server interoperability with the other public implementations, and provide deployment experience with this new KEM.

This feature will be transparent to users, providing no public Kyber API, and likely will be gated behind a GODEBUG option.

cc @FiloSottile