ML-KEM post-quantum TLS is now compatible with Secrets Manager, ACM, and AWS KMS.
With great pleasure, Amazon Web Services (AWS) announces that three AWS services now use the most recent hybrid post-quantum key agreement standards for TLS. Today, all AWS Regions in the AWS partition enable ML-KEM for hybrid post-quantum key agreement in non-FIPS endpoints via AWS KMS, ACM, and AWS Secrets Manager. Hybrid post-quantum key agreement is now optional for the AWS Secrets Manager Agent, which is based on the AWS SDK for Rust. Customers can use end-to-end post-quantum enabled TLS to include secrets into their applications.
Because they are AWS security-critical services with the greatest pressing need for post-quantum confidentiality, these three services were selected. The precursor to ML-KEM, CRYSTALS-Kyber, was originally supported by these three AWS services. While CRYSTALS-Kyber support will last until 2025, ML-KEM will replace it across all AWS service endpoints in 2026.
AWS transition to post-quantum encryption
AWS is dedicated to adhering to its migration strategy for post-quantum cryptography. Over the upcoming years, AWS intends to implement support for ML-KEM across all AWS services with HTTPS endpoints as part of this promise and the AWS post-quantum shared responsibility model. When connecting to AWS service HTTPS endpoints, AWS customers need to upgrade their TLS clients and SDKs to support ML-KEM. This will guard against future harvesting now and decipher dangers from advances in quantum computing later. When clients offer ML-KEM, it will be up to the AWS service HTTPS endpoints to choose it.
AWS open-source FIPS-140-3-validated cryptographic library, AWS Libcrypto (AWS-LC), and its open-source TLS implementation, s2n-tls, which is utilised across AWS service HTTPS endpoints, enable AWS dedication to negotiating hybrid post-quantum key agreement techniques.
The impact on TLS performance of hybrid post-quantum ML-KEM
An ECDH+ML-KEM hybrid key agreement necessitates that the TLS handshake send more data and carry out more cryptographic operations than an Elliptic Curve Diffie-Hellman (ECDH)-only key agreement. An additional 1600 bytes will be transferred during the TLS handshake when switching from a classical to a hybrid post-quantum key agreement. Additionally, ML-KEM cryptographic operations will need an additional 80–150 microseconds of compute time. This initial TLS connection cost is deducted from the total number of HTTP requests sent via the connection over the course of the connection’s lifespan.
AWS is attempting to provide a seamless transition for TLS to hybrid post-quantum key agreement. In order to help clients comprehend the effects of enabling hybrid post-quantum key agreement with ML-KEM, this study involves doing benchmarks on sample workloads.
The number of AWS KMS GenerateDataKey requests per second that a single thread can send serially between an Amazon Elastic Compute Cloud (Amazon EC2) C6in.metal client and the public AWS KMS endpoint has been measured by AWS using the AWS SDK for Java v2. The US-West-2 Region was home to both the client and the server.
For key agreement, hybrid post-quantum TLS connections used the X25519 elliptic curve with ML-KEM-768, whereas classical TLS connections to AWS KMS used the P256 elliptic curve. Your environment, including your instance type, workload profiles, parallelism and thread usage, and network location and capability, will determine your specific performance characteristics, which may vary. Both active and disabled TLS connection reuse were used to measure the HTTP request transaction rates.
According to AWS findings, using hybrid post-quantum TLS with standard SDK setup options has very little effect on performance. According to AWS measurements, the maximum TPS rate was only reduced by 0.05 percent when hybrid post-quantum TLS was enabled for a default-case sample workload. Additionally, AWS findings demonstrate that the maximum TPS rate was only reduced by 2.3% when SDK settings were overridden to compel the worst-case situation of executing a new TLS handshake for each request.
Through 2025, AWS service endpoints that support CRYSTALS-Kyber the forerunner of ML-KEM—will still be able to do so. Once customers have switched to the ML-KEM standard, we will gradually discontinue support for the pre-standard CRYSTALS-Kyber implementations. Customers should update to the most recent AWS SDK versions with ML-KEM support if they are still using older versions of the Java SDK with CRYSTALS-Kyber support. Customers utilising a generally available release of the AWS SDK for Java v2 can upgrade from CRYSTALS-Kyber to ML-KEM without requiring any code changes.
Once CRYSTALS-Kyber is eliminated from AWS service HTTPS endpoints, customers that are actively negotiating CRYSTALS-Kyber and do not upgrade their AWS Java SDK v2 clients by 2026 will see their clients gently revert to a classical key agreement.
Hybrid post-quantum key agreement usage
Adding the rustls package to your crate and turning on the prefer-post-quantum feature flag will allow the hybrid post-quantum key agreement if you’re using the AWS SDK for Rust.
When creating your AWS Common Runtime HTTP client using the AWS SDK for Java 2.x, you can call.postQuantumTlsEnabled(true) to enable hybrid post-quantum key agreement.
Step 1: Update your Java dependencies to include the AWS Common Runtime HTTP client.
Your Maven dependencies should include the AWS Common Runtime HTTP client. AWS advise using the most recent version. To make ML-KEM usable, use version 2.30.22 or later.
Step 2: Configure your Java SDK client to support post-quantum TLS.
Use the AwsCrtAsyncHttpClient configured with post-quantum TLS when setting up your AWS service client.
Things to try
Here are some suggestions for using this client that is post-quantum enabled:
Perform benchmarks and load tests: The AwsCrtAsyncHttpClient utilises AWS Libcrypto on Linux-based systems and is highly performance-optimized. Try the AwsCrtAsyncHttpClient now if you haven’t previously experienced the speed advantages over the SDK HTTP client by default. Post-quantum TLS support should be enabled after using AwsCrtAsyncHttpClient.
Attempt to join from several network locations: Your request may be denied by intermediate hosts, proxies, or DPI firewalls, depending on its network path. Unblocking these new TLS techniques may require updating your network’s firewalls with your IT administrators or security team.
In conclusion
Three security-critical AWS service endpoints now support ML-KEM-based hybrid key agreements. When TLS connection reuse is enabled, the performance impact of turning on hybrid post-quantum TLS is probably minimal. AWS tests revealed that invoking AWS KMS GenerateDataKey only resulted in a 0.05 percent drop in the maximum number of transactions per second.
When utilising the AWS Common Runtime HTTP client on Linux-based platforms, the AWS SDK for Java v2 now supports ML-KEM-based hybrid key agreement as of version 2.30.22. In your Java SDK client configuration, try turning on post quantum key agreement for TLS right now.
As part of AWS post-quantum cryptography migration strategy, AWS intends to implement support for ML-KEM-based hybrid post-quantum key agreement to all AWS service HTTPS endpoints over the next several years. To help guarantee that ML-KEM key agreement is provided when connecting to AWS service HTTPS endpoints, AWS customers will be in charge of updating their TLS clients and SDKs. This will guard against future harvesting now and decipher dangers from advances in quantum computing later.
Read more on Quantum Computing Course Free in 60 Days
