ML-KEM post-quantum TLS now supported in Amazon KMS, ACM, and Secrets Manager

Amazon Web Services (Amazon Web Services) is excited to announce that the latest hybrid post-quantum key agreement standards for TLS have been deployed to three Amazon Web Services services. Today, Amazon Key Management Service (Amazon KMS), Amazon Certificate Manager (ACM), and Amazon Secrets Manager endpoints now support Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM) for hybrid post-quantum key agreement in non-FIPS endpoints in all Amazon Web Services Regions in the aws partition. The Amazon Secrets Manager Agent, built on Amazon Web Services SDK for Rust now also has opt-in support for hybrid post-quantum key agreement. With this, customers can bring secrets into their applications with end-to-end post-quantum enabled TLS.

These three services were chosen because they are security-critical Amazon Web Services services with the most urgent need for post-quantum confidentiality. These three Amazon Web Services services have previously deployed support for CRYSTALS-Kyber, the predecessor of ML-KEM. Support for CRYSTALS-Kyber will continue through 2025, but will be removed across all Amazon Web Services service endpoints in 2026 in favor of ML-KEM.

Our migration to post-quantum cryptography

Amazon Web Services is committed to following our post-quantum cryptography migration plan. As part of this commitment, and part of the Amazon Web Services post-quantum shared responsibility model, Amazon Web Services plans to deploy support for ML-KEM to all Amazon Web Services services with HTTPS endpoints over the coming years. Amazon Web Services customers must update their TLS clients and SDKs to offer ML-KEM when connecting to Amazon Web Services service HTTPS endpoints. This will protect against future harvest now, decrypt later threats posed by quantum computing advancements. Meanwhile, Amazon Web Services service HTTPS endpoints will be responsible for selecting ML-KEM when offered by clients.

Our commitment to negotiate hybrid post-quantum key agreement algorithms is enabled by Amazon Web Services Libcrypto (Amazon Web Services-LC), our open-source FIPS-140-3-validated cryptographic library used throughout Amazon Web Services, and s2n-tls, our open-source TLS implementation used across Amazon Web Services service HTTPS endpoints. Amazon Web Services-LC has been awarded multiple FIPS certificates from NIST (#4631, #4759, and #4816), and was the first open-source cryptographic module to include ML-KEM in a FIPS 140-3 validation.

The effect of hybrid post-quantum ML-KEM on TLS performance

Migrating from an Elliptic Curve Diffie-Hellman (ECDH)-only key agreement to an ECDH+ML-KEM hybrid key agreement necessarily requires that the TLS handshake send more data and perform more cryptographic operations. Switching from a classical to a hybrid post-quantum key agreement will transfer approximately 1600 additional bytes during the TLS handshake and will require approximately 80–150 microseconds more compute time to perform ML-KEM cryptographic operations. This is a one-time TLS connection startup cost and is amortized over the lifetime of the TLS connection across the HTTP requests sent over that connection.

Amazon Web Services is working to provide a smooth migration to hybrid post-quantum key agreement for TLS. This work includes performing benchmarks on example workloads to help customers understand the impact of enabling hybrid post-quantum key agreement with ML-KEM.

Using the Amazon Web Services SDK for Java v2, Amazon Web Services has measured the number of Amazon KMS GenerateDataKey requests per second that a single thread can issue serially between an Amazon Elastic Compute Cloud (Amazon EC2) C6in.metal client and the public Amazon KMS endpoint. Both the client and server were in the us-west-2 Region. Classical TLS connections to Amazon KMS negotiated the P256 elliptic curve for key agreement, and hybrid post-quantum TLS connections negotiated the X25519 elliptic curve with ML-KEM-768 for their hybrid key agreement. Your own performance characteristics might differ and will depend on your environment, including your instance type, your workload profiles, the amount of parallelism and number of threads used, and your network location and capacity. The HTTP request transaction rates were measured with TLS connection reuse both enabled and disabled.

Figure 1 shows the number of requests per second issued at different percentiles when TLS 1.3 connection reuse is disabled. It shows that in the worst-case scenario—when the cost of a TLS handshake is never amortized and every HTTP request must perform a full TLS handshake—enabling hybrid post-quantum TLS decreases the transactions per second (TPS) by about 2.3 percent on average, from 108.7 TPS to 106.2 TPS.

Figure 1: Amazon KMS GenerateDataKey requests per second without TLS connection reuse

Figure 2 shows the number of requests per second issued at different percentiles when TLS connection reuse is enabled. Reusing TLS connections and amortizing the cost of a TLS handshake over many HTTP requests is the default setting in the Amazon Web Services SDK for Java v2. We show that enabling hybrid post-quantum TLS when using default SDK settings leaves the TPS rate almost unchanged, with only a 0.05 percent decrease on average, from 216.1 TPS to 216.0 TPS.

Figure 2: Amazon KMS GenerateDataKey requests per second with TLS connection reuse

Our results show that the performance impact of enabling hybrid post-quantum TLS is negligible when using typical configuration settings in your SDK. Our measurements show that enabling hybrid post-quantum TLS for a default-case example workload only lowered maximum TPS rate by 0.05 percent. Our results also show that overriding SDK defaults to force the worst-case scenario of performing a new TLS handshake for every request only decreased maximum TPS rate by 2.3 percent.

The following table shows the benchmark data that we measured. Each benchmark performed 500 one-second TPS measurements for varying TLS key agreement settings and TLS connection reuse settings. The measurements used v2.30.22 of the Amazon Web Services SDK for Java v2. The TLS key agreement was switched between classical and hybrid post-quantum by toggling the postQuantumTlsEnabled() configuration. TLS connection reuse was toggled by injecting a Connection: close HTTP header into each HTTP request. This header forces the TLS connection to be shut down after each HTTP request and requires that a new TLS connection be created for each HTTP request.

Removing support for draft post-quantum standards

Amazon Web Services service endpoints with support for CRYSTALS-Kyber, the predecessor of ML-KEM, will continue to support CRYSTALS-Kyber through 2025. We will slowly phase out support for the pre-standard CRYSTALS-Kyber implementations after customers have moved to the ML-KEM standard. Customers using previous versions of the Amazon Web Services SDK for Java with CRYSTALS-Kyber support should upgrade to the latest SDK versions that have ML-KEM support. No code changes are necessary for customers using a generally available release of the Amazon Web Services SDK for Java v2 to upgrade from CRYSTALS-Kyber to ML-KEM.

Customers currently negotiating CRYSTALS-Kyber who do not upgrade their Amazon Web Services Java SDK v2 clients by 2026 will see their clients gracefully fall back to a classical key agreement once CRYSTALS-Kyber is removed from Amazon Web Services service HTTPS endpoints.

How to use hybrid post-quantum key agreement

If using the Amazon Web Services SDK for Rust, you can enable the hybrid post-quantum key agreement by adding the rustls package to your crate and enabling the prefer-post-quantum feature flag. See the rustls documentation for more information.

If using the Amazon Web Services SDK for Java 2.x, you can enable hybrid post-quantum key agreement by calling .postQuantumTlsEnabled(true) when building your Amazon Web Services Common Runtime HTTP client.

Step 1: Add the Amazon Web Services Common Runtime HTTP client to your Java dependencies.

Add the Amazon Web Services Common Runtime HTTP client to your Maven dependencies. We recommend using the latest available version. Use version 2.30.22 or greater to enable the use of ML-KEM.

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>aws-crt-client</artifactId>
    <version>2.30.22<version>
</dependency>

Step 2: Enable post-quantum TLS in your Java SDK client configuration

When configuring your Amazon Web Services service client, use the AwsCrtAsyncHttpClient configured with post-quantum TLS.

// Configure an Amazon Web Services Common Runtime HTTP client with Post-Quantum TLS enabled
SdkAsyncHttpClient awsCrtHttpClient = AwsCrtAsyncHttpClient.builder()
          .postQuantumTlsEnabled(true)
          .build();

// Create an Amazon Web Services service client that uses the Amazon Web Services Common Runtime client
KmsAsyncClient kmsAsync = KmsAsyncClient.builder()
         .httpClient(awsCrtHttpClient)
         .build();

// Make a request over a TLS connection that uses post-quantum key agreement
ListKeysReponse keys = kmsAsync.listKeys().get();

See the KMS PQ TLS example application for an end-to-end example of a post-quantum TLS setup.

Things to try

Here are some ideas about how to use this post-quantum-enabled client:

• Run load tests and benchmarks. The AwsCrtAsyncHttpClient is heavily optimized for performance and uses Amazon Web Services Libcrypto on Linux-based environments. If you aren’t already using the AwsCrtAsyncHttpClient, try it today to see the performance benefits compared to the default SDK HTTP client. After using AwsCrtAsyncHttpClient, enable post-quantum TLS support. See if using AwsCrtAsyncHttpClient with post-quantum TLS is an overall performance gain to using the default SDK HTTP client without post-quantum TLS.
• Try connecting from different network locations. Depending on the network path that your request takes, you might discover that intermediate hosts, proxies, or firewalls with deep packet inspection (DPI) block the request. If this is the case, you might need to work with your security team or IT administrators to update firewalls in your network to unblock these new TLS algorithms. We want to hear from you about how your infrastructure interacts with this new variant of TLS traffic.

Conclusion

Support for ML-KEM-based hybrid key agreement has been deployed to three security-critical Amazon Web Services service endpoints. The performance impact of enabling hybrid post-quantum TLS is likely to be negligible when TLS connection reuse is enabled. Our measurements showed only a 0.05 percent decrease to maximum transactions per second when calling Amazon KMS GenerateDataKey.

Starting with version 2.30.22, the Amazon Web Services SDK for Java v2 now supports ML-KEM-based hybrid key agreement on Linux-based platforms when using the Amazon Web Services Common Runtime HTTP client. Try enabling post quantum key agreement for TLS in your Java SDK client configuration today.

Amazon Web Services plans to deploy support for ML-KEM-based hybrid post-quantum key agreement to every Amazon Web Services service HTTPS endpoint over the coming years as part of our post-quantum cryptography migration plan. Amazon Web Services customers will be responsible for updating their TLS clients and SDKs to help ensure that ML-KEM key agreement is offered when connecting to Amazon Web Services service HTTPS endpoints. This will protect against future harvest now, decrypt later threats posed by quantum computing advancements.

For additional information, blog posts, and periodic updates on our post-quantum cryptography migration, keep watching the Amazon Web Services Post-Quantum Cryptography page. To learn more about post-quantum cryptography with Amazon Web Services, contact the post-quantum cryptography team.

If you have feedback about this post, submit comments in the Comments section below. If you have questions about this post, start a new thread on the Amazon Web Services Security, Identity, & Compliance re:Post or contact Amazon Support.

Additional resources:

• Amazon Web Services Post-Quantum Cryptography
• Amazon Web Services post-quantum cryptography migration plan
• Customer compliance and security during the post-quantum cryptographic migration
• Amazon Web Services-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation
• The impact of data-heavy, post-quantum TLS 1.3 on the Time-To-Last-Byte of real-world connections
• Amazon Web Services Workshop: Using Post-Quantum Cryptography on Amazon Web Services
• NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)

If you have feedback about this post, submit comments in the Comments section below.