Quantum-secure gateways in Red Hat OpenShift Service Mesh 3.2

December 18, 2025
Jacek Ewertowski
Related topics:
Service MeshSecurity
Related products:
Red Hat OpenShiftRed Hat OpenShift Service Mesh

Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to withstand attacks by both classical and quantum computers. As quantum computing technology advances, traditional cryptographic methods like RSA, ECDSA, and ECDH become vulnerable to quantum attacks, particularly through algorithms like Shor's algorithm, which can efficiently factor large integers and solve discrete logarithm problems.

PQC algorithms are based on mathematical problems that are believed to be difficult for both classical and quantum computers to solve, such as:

  • Lattice-based cryptography: Relies on the difficulty of problems such as learning with errors (LWE).
  • Code-based cryptography: Built upon the security of error-correcting codes.
  • Multivariate cryptography: Based on solving systems of multivariate polynomial equations.
  • Hash-based signatures: The security of these signatures stems from cryptographic hash functions.
  • Isogeny-based cryptography: Founded on the concept of walks in supersingular isogeny graphs.
  • Symmetric cryptography: Symmetric algorithms like AES-256 remain quantum-resistant (though Grover's algorithm provides quadratic speedup).

Addressing symmetric cryptography

While the focus of PQC is often on asymmetric cryptography (key exchange and digital signatures), it's important to consider symmetric algorithms as well. Symmetric-key algorithms, such as AES-256, are generally considered quantum-resistant.

The primary concern regarding symmetric encryption in a quantum world relates to Grover's algorithm. Grover's algorithm offers a quadratic speed increase for searching unsorted databases, which means an attacker with a large-scale quantum computer could potentially halve the effective security of a symmetric key.

For example:

  • A classical attack against a 128-bit key requires 2128 operations.
  • A quantum attack using Grover's algorithm requires approximately 2128/2 = 264 operations.

To maintain the equivalent classical security level (for example, 128 bits of security), the key size for symmetric algorithms should be doubled. Therefore, while AES-128 is considered effective against classical attacks, migrating to AES-256 is recommended for post-quantum readiness to mitigate the effect of Grover's algorithm.

It's critical to note that the immediate focus for PQC migration remains the asymmetric algorithms (RSA, ECDSA, ECDH) that are completely broken by Shor's algorithm.

The Quantum threat to current cryptography

The development of large-scale quantum computers poses a significant threat to current cryptographic systems:

  • Shor's algorithm: Efficiently factors large integers and computes discrete logarithms, breaking RSA, ECDSA, and ECDH.
  • Grover's algorithm: Provides a quadratic speedup for searching unsorted databases, effectively halving the security level of symmetric cryptographic algorithms.
  • Timeline concerns: While large-scale quantum computers don't exist today, experts estimate they could become reality within 10 to 30 years.

Organizations need to start preparing now because:

  • Harvest now, decrypt later: Adversaries may be collecting encrypted data today to decrypt it once quantum computers become available.
  • Migration complexity: Transitioning to post-quantum cryptography requires significant planning and testing.
  • Compliance requirements: Various standards bodies and governments are beginning to mandate PQC readiness.

PQC algorithms and standards

The U.S. National Institute of Standards and Technology (NIST) has been leading the standardization of post-quantum cryptographic algorithms. In 2022, NIST published the first set of PQC standards.

Key encapsulation mechanisms (KEM)

  • CRYSTALS-KYBER (ML-KEM): A lattice-based algorithm for key establishment
  • X25519MLKEM768: A hybrid approach combining traditional X25519 with ML-KEM-768

Digital signatures

  • CRYSTALS-DILITHIUM (ML-DSA): A lattice-based signature algorithm
  • FALCON: A lattice-based signature algorithm optimized for smaller signatures
  • SPHINCS+: A hash-based signature algorithm

The hybrid approach (like X25519MLKEM768) is particularly important during the transition period, because it provides security against both classical and quantum attacks while maintaining compatibility with existing systems.

Quantum-secure gateway

Red Hat OpenShift Service Mesh enables you to configure Istio gateways with post-quantum cryptographic algorithms, providing protection against both current and future quantum computer attacks. This implementation uses hybrid key exchange mechanisms that combine traditional cryptography with post-quantum algorithms.

Prerequisites

Before setting up a quantum-secure gateway, ensure that you have the following:

  • OpenShift 4.19+
  • Cluster-admin permissions
  • Red Hat OpenShift Service Mesh Operator 3.2.1+ installed in your cluster
  • A local install of oc, podman, and curl
  • A basic understanding of Istio gateways and service mesh concepts

Install OpenShift Service Mesh

  1. Install the Istio CNI
$ oc new-project istio-cni
$ oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: IstioCNI
metadata:
  name: default
spec:
  version: v1.26.2
  namespace: istio-cni
EOF
  1. Install the Istio control plane with post-quantum cryptography enabled
$ oc apply -f - <<EOF
apiVersion: sailoperator.io/v1
kind: Istio
metadata:
  name: default
spec:
  version: v1.26.2
  namespace: istio-system
  updateStrategy:
    type: InPlace
  values:
    meshConfig:
      accessLogFile: /dev/stdout
      tlsDefaults:
        ecdhCurves:
        - X25519MLKEM768
EOF

The meshConfig.tlsDefaults.ecdhCurves setting applies to all non-mesh TLS connections in your Istio deployment. This includes:

  • Ingress gateways: TLS connections from external clients to your gateways
  • Egress gateways: TLS connections from your gateways to external services
  • External service connections: Any TLS connections to services outside the mesh

However, this setting does NOT apply to mesh-internal mTLS. Communication between services within the mesh continues to use Istio's default mTLS configuration.

Currently, Istio does not provide the capability to enable post-quantum cryptography algorithms on a per-workload basis. The tlsDefaults configuration is a mesh-wide setting that affects all gateways and external TLS connections uniformly.

If you need different TLS configurations for different gateways, you would need to deploy separate Istio control planes with different meshConfig.tlsDefaults settings.

Generate TLS certificates

  1. Create the necessary certificates for your gateway
$ mkdir certs
$ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
  -subj '/O=example Inc./CN=example.com' \
  -keyout certs/example.com.key \
  -out certs/example.com.crt
$ openssl req -out certs/httpbin.example.com.csr -newkey rsa:2048 -nodes \
  -keyout certs/httpbin.example.com.key \
  -subj "/CN=httpbin.example.com/O=httpbin organization"
$ openssl x509 -req -sha256 -days 365 \
  -CA certs/example.com.crt -CAkey certs/example.com.key \
  -set_serial 0 -in certs/httpbin.example.com.csr \
  -out certs/httpbin.example.com.crt
  1. Create a Kubernetes secret containing the TLS certificate for your gateway
$ oc create -n istio-system secret tls httpbin-credential \
    --key=certs/httpbin.example.com.key \
    --cert=certs/httpbin.example.com.crt

Deploy quantum-secure gateway

Deploy a gateway using the Kubernetes Gateway API with the custom PQC-enabled proxy image:

$ oc apply -f - <<EOF
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: pqc-gateway
  namespace: istio-system
spec:
  gatewayClassName: istio
  listeners:
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: httpbin-credential
        namespace: istio-system
    allowedRoutes:
      namespaces:
        from: All
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: default
spec:
  parentRefs:
  - name: pqc-gateway
    namespace: istio-system
  hostnames:
  - "httpbin.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: httpbin
      port: 8000
EOF

The sidecar.istio.io/proxyImage annotation specifies the custom proxy image with PQC support.

Deploy back-end server

Now you can deploy the back-end server:

$ oc label ns default istio-injection=enabled
$ oc apply -n default -f \
https://raw.githubusercontent.com/openshift-service-mesh/istio/master/samples/httpbin/httpbin.yaml

Verification

It's important to verify that your setup works as expected, to demonstrate:

  • PQC protection: Only clients supporting post-quantum algorithms can establish connections.
  • Backward incompatibility: Standard clients without PQC support cannot connect, ensuring quantum-safe communication.
  • Hybrid security: The X25519MLKEM768 algorithm provides protection against both classical and quantum attacks.

Retrieve the gateway's external address depending on your load balancer provider. For a hostname-based load balancer:

$ INGRESS_ADDR=$(kubectl get svc pqc-gateway-istio \
-n istio-system \
-o jsonpath='{.status.loadBalancer.ingress[0].hostname}')

For an IP-based load balancer:

$ INGRESS_ADDR=$(kubectl get svc pqc-gateway-istio \
-n istio-system \
-o jsonpath='{.status.loadBalancer.ingress[0].ip}')

Test connection with PQC-enabled client. This should succeed:

$ podman run --rm -it \
  -v ./certs/example.com.crt:/etc/certs/example.com.crt \
  docker.io/openquantumsafe/curl \
  curl -vk "https://$INGRESS_ADDR:443/headers" \
  -H "Host: httpbin.example.com" \
  --curves X25519MLKEM768 \
  --cacert /etc/certs/example.com.crt

The above request should succeed, and you should receive HTTP status 200.

This command uses the OQS-enabled curl client that supports the X25519MLKEM768 hybrid key exchange algorithm. Test it again with a standard curl. This should fail with a handshake error:

$ curl -vk "https://$INGRESS_ADDR:443/headers" \
  -H "Host: httpbin.example.com" \
  --cacert ./certs/example.com.crt

It's expected that you get the following errors in the output:

* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, handshake failure (552):
* TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure
* closing connection #0
curl: (35) TLS connect error: error:0A000410:SSL routines::ssl/tls alert handshake failure

Conclusion

To help counter the potential threats posed by quantum computing, Red Hat OpenShift Service Mesh 3.2 allows early adoption of post-quantum cryptography (PQC). In this article, you've customized the Istio proxy with the OQS provider and configured hybrid algorithms (for example, X25519MLKEM768) and successfully introduced quantum-secure key exchange into the Istio ingress gateway. This protects external traffic from both classical and quantum attacks and mitigates the "Harvest now, decrypt later" risk. Although built-in PQC support is expected in future versions, this method enables enterprises to secure their service mesh perimeter today for quantum readiness.

For more information, take a look at these resources: