crypto: post-quantum support roadmap

[rolandshoemaker]

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

[gopherbot]

Change https://go.dev/cl/547895 mentions this issue: crypto/internal/mlkem768: new package

[gopherbot]

Change https://go.dev/cl/547357 mentions this issue: crypto/internal/mlkem768: new package

[gopherbot]

Change https://go.dev/cl/550215 mentions this issue: crypto/internal/mlkem768: new package

[3052]

call me naive, but is this really something that needs to be in the standard library? I know Filippo and others are really passionate about crypto, I get and respect that. but one thing I DON'T want to see with Go is that is become the next Python, with a giant standard library (if its not already that). we have to draw the line somewhere, and in this case the proposed package(s) seem clearly on the "do not add" side (to me).

I invite counter arguments, I dont mind being proven wrong here, but I DON'T think it should just be assumed that this needs to be in the standard library. post-quantum crypto is in its infancy as I understand it.

[FiloSottile]

@3052 post-quantum key exchanges are necessary as soon as possible to prevent collect-now-decrypt-later attacks. There is a concerted industry-wide push to migrate to PQ, and we believe it's important for Go applications to enable that.

We are starting with internal packages, and initially probably only ML-KEM actually, probably until the final NIST specifications are published.

If you want to know more about how the implementation is following the Cryptography Principles, you might find https://words.filippo.io/mlkem768/ interesting.

[DemiMarie]

@FiloSottile What about the Streamlined NTRU Prime algorithm used by OpenSSH?

[UladzimirTrehubenka]

Wondering why only crypto/internal/mlkem768 has been added, what is the reason to skip mlkem512 and mlkem1024 described in FIPS 203? Don't think that this "partial" implementation which leads to use third party libraries instead built-in is a good idea.

[thequailman]

Also, when will the mlkem768 implementation be ready for use/be exposed outside of internal?

[crrodriguez]

In contrast, I strongly encourage to continue been opinionated and implement whatever you think it is the best/faster/safer now and not everything under the sun. And make hard choices of sane defaults, never let that to the application.

[UladzimirTrehubenka]

not everything under the sun

Don't you think that implement for example only AES-192 w/o AES-128 and AES-256 is a good idea? And this is the same: implement mlkem768 w/o mlkem512 and mlkem1024.

the best/faster/safer

BTW I have another conversation regarding fast sha3/mlkem/mldsa implementation - see the issue.

[ctgowrie]

Thanks for work on this @FiloSottile. Appears the first standards were recently finalized 🙌

[maddin200]

Go could be helpful see: https://eprint.iacr.org/2022/337

[torntrousers]

@FiloSottile What about the Streamlined NTRU Prime algorithm used by OpenSSH?

Curious about this too?

[FiloSottile]

We have no plans to implement any other PQ KEM than ML-KEM. Note that OpenSSH 9.9 added a ML-KEM hybrid, and we plan to support that in x/crypto/ssh soon.

[torntrousers]

We have no plans to implement any other PQ KEM than ML-KEM. Note that OpenSSH 9.9 added a ML-KEM hybrid, and we plan to support that in x/crypto/ssh soon.

@FiloSottile , by "soon" would that likely be Go1.24 which i suppose is around Feb 25?