From d5013cb3e7d18c3eeb4b5bfb52e669cb0f170f16 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Fri, 30 May 2025 13:32:06 +0200 Subject: [PATCH 01/12] blog post in post quantum crypto in k8s Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 192 ++++++++++++++++++ 1 file changed, 192 insertions(+) create mode 100644 content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md new file mode 100644 index 000000000..31d1d9bad --- /dev/null +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -0,0 +1,192 @@ +--- +layout: blog +title: "Post-Quantum Cryptography in Kubernetes" +slug: pqc-in-k8s +date: 2025-06-03 +author: "Fabian Kammel (ControlPlane)" +--- + +# Navigating the Post-Quantum Landscape in Kubernetes + +The world of cryptography is on the cusp of a major shift with the advent of +quantum computing. While powerful quantum computers are still largely theoretical +for many applications, their potential to break current cryptographic standards +is a serious concern, especially for long-lived systems. This is where +_Post-Quantum Cryptography_ (PQC) comes in. In this article, I'll dive into what +PQC means for TLS and, more specifically, for the Kubernetes ecosystem. + +## What is Post-Quantum Cryptography? + +Post-Quantum Cryptography refers to cryptographic algorithms that are thought +to be secure against attacks by both classical and quantum computers. The +primary concern is that quantum computers, using algorithms like +[Shor's Algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), +could efficiently break widely used public-key cryptosystems such as RSA and +Elliptic Curve Cryptography (ECC), which underpin much of today's secure +communication, including TLS. The industry is actively working on standardizing +and adopting PQC algorithms. One of the first to be standardized by +[NIST](https://www.nist.gov/) is the Module-Lattice Key Encapsulation Mechanism +(ML-KEM), formerly known as Kyber, and now standardized as +[FIPS-203](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf). + +It is difficult to predict when quantum computers will be able to break +classical algorithms. However, it is clear that we need to start migrating +to PQC algorithms now, as the next section shows. To get a feeling for the +predicted timeline we can look at a +[NIST report](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf) +covering the transition to post-quantum cryptography standards. It declares +that system with classical crypto should be deprecated after 2030 and disallowed +after 2035. + +## Key Exchange vs. Digital Signatures: Different Needs, Different Timelines + +In TLS, there are two main cryptographic operations we need to secure: + +**Key Exchange**: This is how the client and server agree on a shared secret +to encrypt their communication. If an attacker records encrypted traffic today, +they could decrypt it in the future, if they gain access to a quantum computer +capable of breaking the key exchange. This makes migrating KEMs to PQC an +immediate priority. + +**Digital Signatures**: These are primarily used to authenticate the server +(and sometimes the client) via certificates. The authenticity of a server is +verified at the time of connection. While important, the risk of an attack today +is much lower, because the decision of trusting a server cannot be abused after +the fact. Additionally, current PQC signature schemes often come with significant +computational overhead and larger key/signature sizes compared to their classical +counterparts. + +Given these differences, the focus for immediate PQC adoption in TLS has been on +hybrid key exchange mechanisms. These combine a classical algorithm (such +as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)) with a PQC algorithm +(such as ML-KEM). The resulting shared secret is secure as +long as at least one of the component algorithms remains unbroken. The +`X25519MLKEM768` hybrid scheme is the most widely supported one. + +## State of PQC Key Exchange Mechanisms (KEMs) Today + +Support for PQC KEMs is rapidly improving across the ecosystem. + +**Go**: The Go standard library's `crypto/tls` package introduced support for +`X25519MLKEM768` in version 1.24 (released February 2025). Crucially, it's +enabled by default when there is no explicit configuration, i.e., +`Config.CurvePreferences` is `nil`. + +**Browsers & OpenSSL**: Major browsers like Chrome (version 131, November 2024) +and Firefox (version 135, February 2025), as well as OpenSSL (version 3.5.0, +April 2025), have also added support for the ML-KEM based hybrid scheme. + +## PQC KEMs in Kubernetes: An Unexpected Arrival? + +So, what does this mean for Kubernetes? Kubernetes components, including the +API server and kubelet, are built with Go. + +As of Kubernetes v1.33, released in April 2025, the project uses Go 1.24. A quick check of the +Kubernetes codebase reveals that `Config.CurvePreferences` is not explicitly +set. This leads to a fascinating conclusion: Kubernetes v1.33, by virtue of +using Go 1.24, supports hybrid post-quantum `X25519MLKEM768` for TLS connections by +default! + +You can test this yourself. If you set up a Minikube cluster running Kubernetes +v1.33.0, you can connect to the API server using a recent OpenSSL client: + +```console +$ minikube start --kubernetes-version=v1.33.0 +$ kubectl cluster-info +Kubernetes control plane is running at https://127.0.0.1: +$ kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt +$ openssl version +OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) +$ echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt +[...] +Negotiated TLS1.3 group: X25519MLKEM768 +[...] +DONE +``` + +Lo and behold, the negotiated group is `X25519MLKEM768`! This is a significant +step towards making Kubernetes quantum-safe, seemingly without a major +announcement or dedicated KEP. + +## The Go Version Mismatch Pitfall + +An interesting wrinkle emerged with Go versions 1.23 and 1.24. Go 1.23 included +experimental support for a draft version of ML-KEM, identified as +`X25519Kyber768Draft00`. This was also enabled by default if +`Config.CurvePreferences` was `nil`. Kubernetes v1.32 used Go 1.23. +However, Go 1.24 removed the draft support and replaced it with the standardized +version `X25519MLKEM768`. + +What happens if a client and server are using mismatched Go versions (one on +1.23, the other on 1.24)? They won't have a common PQC KEM to negotiate, and the +handshake will fall back to classical ECC curves (e.g., `X25519`). How could +this happen in practice? + +Consider a scenario: + +A Kubernetes cluster is running v1.32 (using Go 1.23 and thus +`X25519Kyber768Draft00`). A developer upgrades their kubectl to v1.33, compiled +with Go 1.24, only supporting `X25519MLKEM768`. Now, when kubectl communicates +with the v1.32 API server, they no longer share a common PQC algorithm. The +connection will downgrade to classical cryptography, silently losing the PQC +protection that has been in place. This highlights the importance of understanding +the implications of Go version upgrades, and the details of the TLS stack. + +## Limitations: Packet Size + +One practical consideration with ML-KEM is the size of its public keys +(around 1.184 bytes for ML-KEM-768). This can cause the initial TLS Client +Hello message to exceed the typical single TCP packet limit (around 1500 bytes). +Some TLS libraries or network appliances might not handle this gracefully, +assuming the Client Hello always fits in one packet. This issue has been +observed in some Kubernetes-related projects and networking components, +potentially leading to connection failures when PQC KEMs are used. More details +can be found at [tldr.fail](https://tldr.fail/tls-client-hello-packet-size). + +## State of Post-Quantum Signatures + +While KEMs are seeing broader adoption, PQC digital signatures are further +behind in terms of widespread integration into standard toolchains. NIST has +published standards for PQC signatures, such as ML-DSA (FIPS-204) and SLH-DSA +(FIPS-205). However, implementing these in a way that's broadly usable (e.g., +for PQC Certificate Authorities) +[presents challenges](https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms): + +**Larger Keys and Signatures**: PQC signature schemes often have significantly +larger public keys and signature sizes compared to classical algorithms like +Ed25519 or RSA. For instance, Dilithium2 keys can be 30 times larger than +Ed25519 keys, and certificates can be 12 times larger. + +**Performance**: Signing and verification operations +[can be substantially slower](https://pqshield.github.io/nist-sigs-zoo/). +We are talking on the order of 10x to 1000x worse performance, compared to +classical algorithms. + +**Toolchain Support**: Mainstream TLS libraries and CA software do not yet have +mature, built-in support for these new signature algorithms. The Go team, for +example, has indicated that ML-DSA support is a high priority, but the soonest +it might appear in the standard library is Go 1.26 +[(as of May 2025)](https://github.com/golang/go/issues/64537#issuecomment-2877714729). + +[Cloudflare's CIRCL](https://github.com/cloudflare/circl) +(Cloudflare Interoperable Reusable Cryptographic Library) library +implements some PQC signature schemes like variants of Dilithium, and they +maintain a [fork of Go (cfgo)](https://github.com/cloudflare/go) +that integrates CIRCL. Using cfgo, it's possible +to experiment with generating certificates signed with PQC algorithms like +Ed25519-Dilithium2. However, this requires using a custom Go toolchain and is +not yet part of the mainstream Kubernetes or Go distributions. + +## Conclusion + +The journey to a post-quantum secure Kubernetes is underway, and perhaps further +along than many realize, thanks to the proactive adoption of ML-KEM in Go. +Kubernetes v1.33 users are already benefiting from hybrid PQC key exchange +in many TLS connections by default. + +However, awareness of potential pitfalls, such as Go version mismatches leading +to downgrades and issues with Client Hello packet sizes, is crucial. While PQC +for KEMs is becoming a reality, PQC for digital signatures and certificate +hierarchies is still in earlier stages of development and adoption for mainstream +use. As Kubernetes maintainers and contributors, staying informed about these +developments will be key to ensuring the long-term security of the platform. From 24ca67825e78458ab454a8a55fa68e9e37aa68f6 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Fri, 30 May 2025 16:21:23 +0200 Subject: [PATCH 02/12] format: follow style guide Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 221 +++++++++--------- 1 file changed, 112 insertions(+), 109 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 31d1d9bad..5445bfd63 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -6,102 +6,97 @@ date: 2025-06-03 author: "Fabian Kammel (ControlPlane)" --- -# Navigating the Post-Quantum Landscape in Kubernetes - The world of cryptography is on the cusp of a major shift with the advent of -quantum computing. While powerful quantum computers are still largely theoretical -for many applications, their potential to break current cryptographic standards -is a serious concern, especially for long-lived systems. This is where -_Post-Quantum Cryptography_ (PQC) comes in. In this article, I'll dive into what -PQC means for TLS and, more specifically, for the Kubernetes ecosystem. - -## What is Post-Quantum Cryptography? - -Post-Quantum Cryptography refers to cryptographic algorithms that are thought -to be secure against attacks by both classical and quantum computers. The -primary concern is that quantum computers, using algorithms like -[Shor's Algorithm](https://en.wikipedia.org/wiki/Shor%27s_algorithm), +quantum computing. While powerful quantum computers are still largely +theoretical for many applications, their potential to break current +cryptographic standards is a serious concern, especially for long-lived +systems. This is where _Post-Quantum Cryptography_ (PQC) comes in. In this +article, I\'ll dive into what PQC means for TLS and, more specifically, for the +Kubernetes ecosystem. + +## What is Post-Quantum Cryptography + +Post-Quantum Cryptography refers to cryptographic algorithms that are thought to +be secure against attacks by both classical and quantum computers. The primary +concern is that quantum computers, using algorithms like [Shor\'s Algorithm], could efficiently break widely used public-key cryptosystems such as RSA and -Elliptic Curve Cryptography (ECC), which underpin much of today's secure +Elliptic Curve Cryptography (ECC), which underpin much of today\'s secure communication, including TLS. The industry is actively working on standardizing -and adopting PQC algorithms. One of the first to be standardized by -[NIST](https://www.nist.gov/) is the Module-Lattice Key Encapsulation Mechanism -(ML-KEM), formerly known as Kyber, and now standardized as -[FIPS-203](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf). +and adopting PQC algorithms. One of the first to be standardized by [NIST] is +the Module-Lattice Key Encapsulation Mechanism (`ML-KEM`), formerly known as +Kyber, and now standardized as [`FIPS-203`]. It is difficult to predict when quantum computers will be able to break -classical algorithms. However, it is clear that we need to start migrating -to PQC algorithms now, as the next section shows. To get a feeling for the -predicted timeline we can look at a -[NIST report](https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf) -covering the transition to post-quantum cryptography standards. It declares -that system with classical crypto should be deprecated after 2030 and disallowed -after 2035. +classical algorithms. However, it is clear that we need to start migrating to +PQC algorithms now, as the next section shows. To get a feeling for the +predicted timeline we can look at a [NIST report] covering the transition to +post-quantum cryptography standards. It declares that system with classical +crypto should be deprecated after 2030 and disallowed after 2035. ## Key Exchange vs. Digital Signatures: Different Needs, Different Timelines In TLS, there are two main cryptographic operations we need to secure: -**Key Exchange**: This is how the client and server agree on a shared secret -to encrypt their communication. If an attacker records encrypted traffic today, +**Key Exchange**: This is how the client and server agree on a shared secret to +encrypt their communication. If an attacker records encrypted traffic today, they could decrypt it in the future, if they gain access to a quantum computer capable of breaking the key exchange. This makes migrating KEMs to PQC an immediate priority. -**Digital Signatures**: These are primarily used to authenticate the server -(and sometimes the client) via certificates. The authenticity of a server is -verified at the time of connection. While important, the risk of an attack today -is much lower, because the decision of trusting a server cannot be abused after -the fact. Additionally, current PQC signature schemes often come with significant -computational overhead and larger key/signature sizes compared to their classical -counterparts. - -Given these differences, the focus for immediate PQC adoption in TLS has been on -hybrid key exchange mechanisms. These combine a classical algorithm (such -as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)) with a PQC algorithm -(such as ML-KEM). The resulting shared secret is secure as -long as at least one of the component algorithms remains unbroken. The -`X25519MLKEM768` hybrid scheme is the most widely supported one. +**Digital Signatures**: These are primarily used to authenticate the server (and +sometimes the client) via certificates. The authenticity of a server is +verified at the time of connection. While important, the risk of an attack +today is much lower, because the decision of trusting a server cannot be abused +after the fact. Additionally, current PQC signature schemes often come with +significant computational overhead and larger key/signature sizes compared to +their classical counterparts. + +Given these differences, the focus for immediate PQC adoption in TLS has been +on hybrid key exchange mechanisms. These combine a classical algorithm (such as +Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)) with a PQC algorithm (such as +`ML-KEM`). The resulting shared secret is secure as long as at least one of the +component algorithms remains unbroken. The `X25519MLKEM768` hybrid scheme is the +most widely supported one. ## State of PQC Key Exchange Mechanisms (KEMs) Today Support for PQC KEMs is rapidly improving across the ecosystem. -**Go**: The Go standard library's `crypto/tls` package introduced support for -`X25519MLKEM768` in version 1.24 (released February 2025). Crucially, it's +**Go**: The Go standard library\'s `crypto/tls` package introduced support for +`X25519MLKEM768` in version 1.24 (released February 2025). Crucially, it\'s enabled by default when there is no explicit configuration, i.e., `Config.CurvePreferences` is `nil`. **Browsers & OpenSSL**: Major browsers like Chrome (version 131, November 2024) and Firefox (version 135, February 2025), as well as OpenSSL (version 3.5.0, -April 2025), have also added support for the ML-KEM based hybrid scheme. +April 2025), have also added support for the `ML-KEM` based hybrid scheme. -## PQC KEMs in Kubernetes: An Unexpected Arrival? +## PQC KEMs in Kubernetes: An Unexpected Arrival So, what does this mean for Kubernetes? Kubernetes components, including the API server and kubelet, are built with Go. -As of Kubernetes v1.33, released in April 2025, the project uses Go 1.24. A quick check of the -Kubernetes codebase reveals that `Config.CurvePreferences` is not explicitly -set. This leads to a fascinating conclusion: Kubernetes v1.33, by virtue of -using Go 1.24, supports hybrid post-quantum `X25519MLKEM768` for TLS connections by -default! +As of Kubernetes v1.33, released in April 2025, the project uses Go 1.24. A +quick check of the Kubernetes codebase reveals that `Config.CurvePreferences` +is not explicitly set. This leads to a fascinating conclusion: Kubernetes +v1.33, by virtue of using Go 1.24, supports hybrid post-quantum +`X25519MLKEM768` for TLS connections by default! You can test this yourself. If you set up a Minikube cluster running Kubernetes v1.33.0, you can connect to the API server using a recent OpenSSL client: ```console -$ minikube start --kubernetes-version=v1.33.0 -$ kubectl cluster-info -Kubernetes control plane is running at https://127.0.0.1: -$ kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt -$ openssl version -OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) -$ echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt -[...] -Negotiated TLS1.3 group: X25519MLKEM768 -[...] -DONE +minikube start --kubernetes-version=v1.33.0 +kubectl cluster-info +# Kubernetes control plane is running at https://127.0.0.1: +kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt +openssl version +# OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) +echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt +# [...] +# Negotiated TLS1.3 group: X25519MLKEM768 +# [...] +# DONE ``` Lo and behold, the negotiated group is `X25519MLKEM768`! This is a significant @@ -110,83 +105,91 @@ announcement or dedicated KEP. ## The Go Version Mismatch Pitfall -An interesting wrinkle emerged with Go versions 1.23 and 1.24. Go 1.23 included -experimental support for a draft version of ML-KEM, identified as +An interesting wrinkle emerged with Go versions 1.23 and 1.24. Go 1.23 +included experimental support for a draft version of `ML-KEM`, identified as `X25519Kyber768Draft00`. This was also enabled by default if -`Config.CurvePreferences` was `nil`. Kubernetes v1.32 used Go 1.23. -However, Go 1.24 removed the draft support and replaced it with the standardized -version `X25519MLKEM768`. +`Config.CurvePreferences` was `nil`. Kubernetes v1.32 used Go 1.23. However, +Go 1.24 removed the draft support and replaced it with the standardized version +`X25519MLKEM768`. What happens if a client and server are using mismatched Go versions (one on -1.23, the other on 1.24)? They won't have a common PQC KEM to negotiate, and the -handshake will fall back to classical ECC curves (e.g., `X25519`). How could -this happen in practice? +1.23, the other on 1.24)? They won\'t have a common PQC KEM to negotiate, and +the handshake will fall back to classical ECC curves (e.g., `X25519`). How +could this happen in practice? Consider a scenario: A Kubernetes cluster is running v1.32 (using Go 1.23 and thus -`X25519Kyber768Draft00`). A developer upgrades their kubectl to v1.33, compiled -with Go 1.24, only supporting `X25519MLKEM768`. Now, when kubectl communicates -with the v1.32 API server, they no longer share a common PQC algorithm. The -connection will downgrade to classical cryptography, silently losing the PQC -protection that has been in place. This highlights the importance of understanding -the implications of Go version upgrades, and the details of the TLS stack. +`X25519Kyber768Draft00`). A developer upgrades their `kubectl` to v1.33, +compiled with Go 1.24, only supporting `X25519MLKEM768`. Now, when `kubectl` +communicates with the v1.32 API server, they no longer share a common PQC +algorithm. The connection will downgrade to classical cryptography, silently +losing the PQC protection that has been in place. This highlights the +importance of understanding the implications of Go version upgrades, and the +details of the TLS stack. ## Limitations: Packet Size -One practical consideration with ML-KEM is the size of its public keys -(around 1.184 bytes for ML-KEM-768). This can cause the initial TLS Client -Hello message to exceed the typical single TCP packet limit (around 1500 bytes). -Some TLS libraries or network appliances might not handle this gracefully, -assuming the Client Hello always fits in one packet. This issue has been -observed in some Kubernetes-related projects and networking components, -potentially leading to connection failures when PQC KEMs are used. More details -can be found at [tldr.fail](https://tldr.fail/tls-client-hello-packet-size). +One practical consideration with `ML-KEM` is the size of its public keys +(around 1.184 bytes for `ML-KEM-768`). This can cause the initial TLS Client +Hello message to exceed the typical single TCP packet limit (around 1500 +bytes). Some TLS libraries or network appliances might not handle this +gracefully, assuming the Client Hello always fits in one packet. This issue +has been observed in some Kubernetes-related projects and networking +components, potentially leading to connection failures when PQC KEMs are used. +More details can be found at [tldr.fail]. ## State of Post-Quantum Signatures While KEMs are seeing broader adoption, PQC digital signatures are further behind in terms of widespread integration into standard toolchains. NIST has -published standards for PQC signatures, such as ML-DSA (FIPS-204) and SLH-DSA -(FIPS-205). However, implementing these in a way that's broadly usable (e.g., -for PQC Certificate Authorities) -[presents challenges](https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms): +published standards for PQC signatures, such as `ML-DSA` (`FIPS-204`) and +`SLH-DSA` (`FIPS-205`). However, implementing these in a way that\'s broadly +usable (e.g., for PQC Certificate Authorities) [presents challenges]: **Larger Keys and Signatures**: PQC signature schemes often have significantly larger public keys and signature sizes compared to classical algorithms like Ed25519 or RSA. For instance, Dilithium2 keys can be 30 times larger than Ed25519 keys, and certificates can be 12 times larger. -**Performance**: Signing and verification operations -[can be substantially slower](https://pqshield.github.io/nist-sigs-zoo/). +**Performance**: Signing and verification operations [can be substantially slower]. We are talking on the order of 10x to 1000x worse performance, compared to classical algorithms. **Toolchain Support**: Mainstream TLS libraries and CA software do not yet have mature, built-in support for these new signature algorithms. The Go team, for -example, has indicated that ML-DSA support is a high priority, but the soonest -it might appear in the standard library is Go 1.26 -[(as of May 2025)](https://github.com/golang/go/issues/64537#issuecomment-2877714729). - -[Cloudflare's CIRCL](https://github.com/cloudflare/circl) -(Cloudflare Interoperable Reusable Cryptographic Library) library -implements some PQC signature schemes like variants of Dilithium, and they -maintain a [fork of Go (cfgo)](https://github.com/cloudflare/go) -that integrates CIRCL. Using cfgo, it's possible -to experiment with generating certificates signed with PQC algorithms like -Ed25519-Dilithium2. However, this requires using a custom Go toolchain and is -not yet part of the mainstream Kubernetes or Go distributions. +example, has indicated that `ML-DSA` support is a high priority, but the +soonest it might appear in the standard library is Go 1.26 [(as of May 2025)]. + +[Cloudflare\'s CIRCL] (Cloudflare Interoperable Reusable Cryptographic Library) +library implements some PQC signature schemes like variants of Dilithium, and +they maintain a [fork of Go (cfgo)] that integrates CIRCL. Using `cfgo`, it\'s +possible to experiment with generating certificates signed with PQC algorithms +like Ed25519-Dilithium2. However, this requires using a custom Go toolchain and +is not yet part of the mainstream Kubernetes or Go distributions. ## Conclusion -The journey to a post-quantum secure Kubernetes is underway, and perhaps further -along than many realize, thanks to the proactive adoption of ML-KEM in Go. -Kubernetes v1.33 users are already benefiting from hybrid PQC key exchange -in many TLS connections by default. +The journey to a post-quantum secure Kubernetes is underway, and perhaps +further along than many realize, thanks to the proactive adoption of `ML-KEM` +in Go. Kubernetes v1.33 users are already benefiting from hybrid PQC key +exchange in many TLS connections by default. However, awareness of potential pitfalls, such as Go version mismatches leading to downgrades and issues with Client Hello packet sizes, is crucial. While PQC for KEMs is becoming a reality, PQC for digital signatures and certificate -hierarchies is still in earlier stages of development and adoption for mainstream -use. As Kubernetes maintainers and contributors, staying informed about these -developments will be key to ensuring the long-term security of the platform. +hierarchies is still in earlier stages of development and adoption for +mainstream use. As Kubernetes maintainers and contributors, staying informed +about these developments will be key to ensuring the long-term security of the +platform. + +[Shor\'s Algorithm]: https://en.wikipedia.org/wiki/Shor%27s_algorithm +[NIST]: https://www.nist.gov/ +[`FIPS-203`]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf +[NIST report]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf +[tldr.fail]: https://tldr.fail/tls-client-hello-packet-size +[presents challenges]: https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms +[can be substantially slower]: https://pqshield.github.io/nist-sigs-zoo/ +[(as of May 2025)]: https://github.com/golang/go/issues/64537#issuecomment-2877714729 +[Cloudflare\'s CIRCL]: https://github.com/cloudflare/circl +[fork of Go (cfgo)]: https://github.com/cloudflare/go From e5688bc7bfba40bcb630e626729ec942207ae59d Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Tue, 3 Jun 2025 16:17:20 +0100 Subject: [PATCH 03/12] work in feedback Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 5445bfd63..cde62b47a 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -12,7 +12,8 @@ theoretical for many applications, their potential to break current cryptographic standards is a serious concern, especially for long-lived systems. This is where _Post-Quantum Cryptography_ (PQC) comes in. In this article, I\'ll dive into what PQC means for TLS and, more specifically, for the -Kubernetes ecosystem. +Kubernetes ecosystem. We will learn what the (suprising) state of PQC in +Kubernetes is and what the implications are for current and future clusters. ## What is Post-Quantum Cryptography @@ -24,7 +25,7 @@ Elliptic Curve Cryptography (ECC), which underpin much of today\'s secure communication, including TLS. The industry is actively working on standardizing and adopting PQC algorithms. One of the first to be standardized by [NIST] is the Module-Lattice Key Encapsulation Mechanism (`ML-KEM`), formerly known as -Kyber, and now standardized as [`FIPS-203`]. +Kyber, and now standardized as [`FIPS-203`] (PDF download). It is difficult to predict when quantum computers will be able to break classical algorithms. However, it is clear that we need to start migrating to @@ -187,7 +188,7 @@ platform. [NIST]: https://www.nist.gov/ [`FIPS-203`]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf [NIST report]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf -[tldr.fail]: https://tldr.fail/tls-client-hello-packet-size +[tldr.fail]: https://tldr.fail/ [presents challenges]: https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms [can be substantially slower]: https://pqshield.github.io/nist-sigs-zoo/ [(as of May 2025)]: https://github.com/golang/go/issues/64537#issuecomment-2877714729 From 83bdb9cf4b41843a71f71c9ea0f338e7f9fa2761 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Tue, 3 Jun 2025 16:22:58 +0100 Subject: [PATCH 04/12] mark post as draft Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 1 + 1 file changed, 1 insertion(+) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index cde62b47a..449d3d4a5 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -4,6 +4,7 @@ title: "Post-Quantum Cryptography in Kubernetes" slug: pqc-in-k8s date: 2025-06-03 author: "Fabian Kammel (ControlPlane)" +draft: true --- The world of cryptography is on the cusp of a major shift with the advent of From 0dcf28f17dd677d3782cb7094f2e1364ab1bb788 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Wed, 4 Jun 2025 16:51:35 +0200 Subject: [PATCH 05/12] Apply suggestions from code review Co-authored-by: Tim Bannister <193443691+lmktfy@users.noreply.github.com> --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 449d3d4a5..65776b9e4 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -13,7 +13,7 @@ theoretical for many applications, their potential to break current cryptographic standards is a serious concern, especially for long-lived systems. This is where _Post-Quantum Cryptography_ (PQC) comes in. In this article, I\'ll dive into what PQC means for TLS and, more specifically, for the -Kubernetes ecosystem. We will learn what the (suprising) state of PQC in +Kubernetes ecosystem. I'll explain what the (suprising) state of PQC in Kubernetes is and what the implications are for current and future clusters. ## What is Post-Quantum Cryptography @@ -35,7 +35,7 @@ predicted timeline we can look at a [NIST report] covering the transition to post-quantum cryptography standards. It declares that system with classical crypto should be deprecated after 2030 and disallowed after 2035. -## Key Exchange vs. Digital Signatures: Different Needs, Different Timelines +## Key exchange vs. digital signatures: different needs, different timelines {#timelines} In TLS, there are two main cryptographic operations we need to secure: @@ -60,7 +60,7 @@ Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)) with a PQC algorithm (such as component algorithms remains unbroken. The `X25519MLKEM768` hybrid scheme is the most widely supported one. -## State of PQC Key Exchange Mechanisms (KEMs) Today +## State of PQC key exchange mechanisms (KEMs) today {#state-of-kems} Support for PQC KEMs is rapidly improving across the ecosystem. @@ -73,7 +73,7 @@ enabled by default when there is no explicit configuration, i.e., and Firefox (version 135, February 2025), as well as OpenSSL (version 3.5.0, April 2025), have also added support for the `ML-KEM` based hybrid scheme. -## PQC KEMs in Kubernetes: An Unexpected Arrival +## Post-quantum KEMs in Kubernetes: an unexpected arrival So, what does this mean for Kubernetes? Kubernetes components, including the API server and kubelet, are built with Go. @@ -91,7 +91,7 @@ v1.33.0, you can connect to the API server using a recent OpenSSL client: minikube start --kubernetes-version=v1.33.0 kubectl cluster-info # Kubernetes control plane is running at https://127.0.0.1: -kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt +kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt openssl version # OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt @@ -105,7 +105,7 @@ Lo and behold, the negotiated group is `X25519MLKEM768`! This is a significant step towards making Kubernetes quantum-safe, seemingly without a major announcement or dedicated KEP. -## The Go Version Mismatch Pitfall +## The Go version mismatch pitfall An interesting wrinkle emerged with Go versions 1.23 and 1.24. Go 1.23 included experimental support for a draft version of `ML-KEM`, identified as @@ -130,7 +130,7 @@ losing the PQC protection that has been in place. This highlights the importance of understanding the implications of Go version upgrades, and the details of the TLS stack. -## Limitations: Packet Size +## Limitations: packet size {#limitation-packet-size} One practical consideration with `ML-KEM` is the size of its public keys (around 1.184 bytes for `ML-KEM-768`). This can cause the initial TLS Client @@ -174,7 +174,7 @@ is not yet part of the mainstream Kubernetes or Go distributions. The journey to a post-quantum secure Kubernetes is underway, and perhaps further along than many realize, thanks to the proactive adoption of `ML-KEM` -in Go. Kubernetes v1.33 users are already benefiting from hybrid PQC key +in Go. With Kubernetes v1.33, users are already benefiting from hybrid post-quantum key exchange in many TLS connections by default. However, awareness of potential pitfalls, such as Go version mismatches leading @@ -185,9 +185,9 @@ mainstream use. As Kubernetes maintainers and contributors, staying informed about these developments will be key to ensuring the long-term security of the platform. -[Shor\'s Algorithm]: https://en.wikipedia.org/wiki/Shor%27s_algorithm +[Shor's Algorithm]: https://en.wikipedia.org/wiki/Shor%27s_algorithm [NIST]: https://www.nist.gov/ -[`FIPS-203`]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf +[FIPS-203]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf [NIST report]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf [tldr.fail]: https://tldr.fail/ [presents challenges]: https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms From 687edbb2fef4010b6b67f290bfb9bfc5f67511a0 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Wed, 4 Jun 2025 17:00:48 +0200 Subject: [PATCH 06/12] Apply suggestions from code review Co-authored-by: Tim Bannister <193443691+lmktfy@users.noreply.github.com> --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 65776b9e4..79d4b489c 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -133,8 +133,10 @@ details of the TLS stack. ## Limitations: packet size {#limitation-packet-size} One practical consideration with `ML-KEM` is the size of its public keys -(around 1.184 bytes for `ML-KEM-768`). This can cause the initial TLS Client -Hello message to exceed the typical single TCP packet limit (around 1500 +with encoded key sizes of around 1.2 kilobytes for `ML-KEM-768`. +This can cause the initial TLS `ClientHello` message not to fit inside +a single TCP/IP packet, given the typical networking constraints +(most commonly, the standard Ethernet frame size limit of 1500 bytes). Some TLS libraries or network appliances might not handle this gracefully, assuming the Client Hello always fits in one packet. This issue has been observed in some Kubernetes-related projects and networking From f5e9806975f700b5d9a7aa044ffbb6171ad0e6dd Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Wed, 4 Jun 2025 16:01:07 +0100 Subject: [PATCH 07/12] fix console Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 79d4b489c..7144c48b6 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -88,17 +88,17 @@ You can test this yourself. If you set up a Minikube cluster running Kubernetes v1.33.0, you can connect to the API server using a recent OpenSSL client: ```console -minikube start --kubernetes-version=v1.33.0 -kubectl cluster-info -# Kubernetes control plane is running at https://127.0.0.1: -kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}' | base64 -d > ca.crt -openssl version -# OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) -echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt -# [...] -# Negotiated TLS1.3 group: X25519MLKEM768 -# [...] -# DONE +$ minikube start --kubernetes-version=v1.33.0 +$ kubectl cluster-info +Kubernetes control plane is running at https://127.0.0.1: +$ kubectl config view --minify --raw -o jsonpath=\'{.clusters[0].cluster.certificate-authority-data}\' | base64 -d > ca.crt +$ openssl version +OpenSSL 3.5.0 8 Apr 2025 (Library: OpenSSL 3.5.0 8 Apr 2025) +$ echo -n "Q" | openssl s_client -connect 127.0.0.1: -CAfile ca.crt +[...] +Negotiated TLS1.3 group: X25519MLKEM768 +[...] +DONE ``` Lo and behold, the negotiated group is `X25519MLKEM768`! This is a significant From 4519d135abd2c76a20ec4d93433d16bb7e093133 Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Mon, 23 Jun 2025 15:09:42 +0200 Subject: [PATCH 08/12] fix: broken links Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 7144c48b6..8f0679cad 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -26,7 +26,7 @@ Elliptic Curve Cryptography (ECC), which underpin much of today\'s secure communication, including TLS. The industry is actively working on standardizing and adopting PQC algorithms. One of the first to be standardized by [NIST] is the Module-Lattice Key Encapsulation Mechanism (`ML-KEM`), formerly known as -Kyber, and now standardized as [`FIPS-203`] (PDF download). +Kyber, and now standardized as [FIPS\-203] (PDF download). It is difficult to predict when quantum computers will be able to break classical algorithms. However, it is clear that we need to start migrating to @@ -187,9 +187,9 @@ mainstream use. As Kubernetes maintainers and contributors, staying informed about these developments will be key to ensuring the long-term security of the platform. -[Shor's Algorithm]: https://en.wikipedia.org/wiki/Shor%27s_algorithm +[Shor\'s Algorithm]: https://en.wikipedia.org/wiki/Shor%27s_algorithm [NIST]: https://www.nist.gov/ -[FIPS-203]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf +[FIPS\-203]: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf [NIST report]: https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf [tldr.fail]: https://tldr.fail/ [presents challenges]: https://blog.cloudflare.com/another-look-at-pq-signatures/#the-algorithms From 8d57b84205ac7378de3b3a4003541fb8322e83ee Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Tue, 24 Jun 2025 13:10:38 +0200 Subject: [PATCH 09/12] added PQC2024 overview blog by cloudflare Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 8f0679cad..35fcbed6e 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -73,6 +73,9 @@ enabled by default when there is no explicit configuration, i.e., and Firefox (version 135, February 2025), as well as OpenSSL (version 3.5.0, April 2025), have also added support for the `ML-KEM` based hybrid scheme. +For a more detailed overview of the state of PQC in the wider industry, +see [this blog post by Cloudflare][PQC2024]. + ## Post-quantum KEMs in Kubernetes: an unexpected arrival So, what does this mean for Kubernetes? Kubernetes components, including the @@ -197,3 +200,4 @@ platform. [(as of May 2025)]: https://github.com/golang/go/issues/64537#issuecomment-2877714729 [Cloudflare\'s CIRCL]: https://github.com/cloudflare/circl [fork of Go (cfgo)]: https://github.com/cloudflare/go +[PQC2024]: https://blog.cloudflare.com/pq-2024/ From 53a78581e9dabc2f52157a24cf58b71dfb525f3b Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Wed, 25 Jun 2025 10:14:46 +0200 Subject: [PATCH 10/12] improve wording on signature performance Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 35fcbed6e..7fc831be2 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -160,8 +160,10 @@ Ed25519 or RSA. For instance, Dilithium2 keys can be 30 times larger than Ed25519 keys, and certificates can be 12 times larger. **Performance**: Signing and verification operations [can be substantially slower]. -We are talking on the order of 10x to 1000x worse performance, compared to -classical algorithms. +While some algorithms are on par with classical algorithms, others may have a +much higher overhead, sometimes on the order of 10x to 1000x worse performance. +To improve this situation, NIST is running a +[second round of standardization][NIST2ndRound] for PQC signatures. **Toolchain Support**: Mainstream TLS libraries and CA software do not yet have mature, built-in support for these new signature algorithms. The Go team, for @@ -201,3 +203,4 @@ platform. [Cloudflare\'s CIRCL]: https://github.com/cloudflare/circl [fork of Go (cfgo)]: https://github.com/cloudflare/go [PQC2024]: https://blog.cloudflare.com/pq-2024/ +[NIST2ndRound]: https://csrc.nist.gov/news/2024/pqc-digital-signature-second-round-announcement From 24b6aa451f6d73eaa5152247106f4da53bdac84a Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Fri, 27 Jun 2025 14:22:06 +0200 Subject: [PATCH 11/12] work in feedback from bwesterb Signed-off-by: Fabian Kammel --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 7fc831be2..927419f2a 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -53,6 +53,10 @@ after the fact. Additionally, current PQC signature schemes often come with significant computational overhead and larger key/signature sizes compared to their classical counterparts. +Another significant hurdle in the migration to PQ certificates is the upgrade +of root certificates. These certificates have long validity periods and are +installed in many devices and operating systems as trust anchors. + Given these differences, the focus for immediate PQC adoption in TLS has been on hybrid key exchange mechanisms. These combine a classical algorithm (such as Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)) with a PQC algorithm (such as @@ -73,6 +77,10 @@ enabled by default when there is no explicit configuration, i.e., and Firefox (version 135, February 2025), as well as OpenSSL (version 3.5.0, April 2025), have also added support for the `ML-KEM` based hybrid scheme. +Apple is also [rolling out support][ApplePQC] for `X25519MLKEM768` in version +26 of their operating systems. Given the proliferation of Apple devices, this +will have a significant impact on the global PQC adoption. + For a more detailed overview of the state of PQC in the wider industry, see [this blog post by Cloudflare][PQC2024]. @@ -204,3 +212,4 @@ platform. [fork of Go (cfgo)]: https://github.com/cloudflare/go [PQC2024]: https://blog.cloudflare.com/pq-2024/ [NIST2ndRound]: https://csrc.nist.gov/news/2024/pqc-digital-signature-second-round-announcement +[ApplePQC]: https://support.apple.com/en-lb/122756 From 83f8c8ab6d9e15764ccd89426b4f2a29a33d72cb Mon Sep 17 00:00:00 2001 From: Fabian Kammel Date: Mon, 30 Jun 2025 09:40:37 +0200 Subject: [PATCH 12/12] Update content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md Co-authored-by: Graziano Casto --- content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md index 927419f2a..1d0d204de 100644 --- a/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md +++ b/content/en/blog/2025/pqc-in-k8s/pqc-in-k8s.md @@ -114,7 +114,7 @@ DONE Lo and behold, the negotiated group is `X25519MLKEM768`! This is a significant step towards making Kubernetes quantum-safe, seemingly without a major -announcement or dedicated KEP. +announcement or dedicated KEP (Kubernetes Enhancement Proposal). ## The Go version mismatch pitfall