up:: In the Protocols MOC

AWS-LC

AWS-LC (AWS libcrypto) is Amazon’s open-source cryptographic library in C, maintained by the AWS Cryptography team and based on code from Google’s BoringSSL and the OpenSSL project, usable as a drop-in for the OpenSSL libcrypto API. It sits at the low-level primitive tier, supplying key-exchange, signature, and hashing building blocks; the TLS layer that negotiates connections is a separate AWS library, s2n-tls, which links AWS-LC for those primitives. It matters for the post-quantum transition because AWS-LC was, by AWS’s own account, the first open-source cryptographic module to carry ML-KEM inside a completed FIPS 140-3 validation, one of the earliest routes to a validated post-quantum key encapsulation primitive.

Source: aws/aws-lc, README; AWS Security Blog, “AWS-LC FIPS 3.0: First cryptographic library to include ML-KEM in FIPS 140-3 validation” (2024-12-10).

The short version:

• AWS-LC is Amazon’s C libcrypto, forked from BoringSSL and OpenSSL, and it provides the low-level cryptographic primitives; s2n-tls is the TLS library that links it and turns those primitives into post-quantum handshakes.
• AWS-LC FIPS 3.0 was the first open-source cryptographic module to include ML-KEM in a FIPS 140-3 validation, per AWS, and the validated AWS-LC 3 module (CMVP certs #5314 and #5298, FIPS 140-3 Level 1) now carries ML-KEM-512, 768, and 1024.
• s2n-tls uses AWS-LC to negotiate the hybrid groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, plus pure ML-KEM-1024 under its CNSA 2.0 policy.
• AWS turned this on in production: KMS, ACM, and Secrets Manager endpoints negotiate X25519MLKEM768 post-quantum TLS on the AWS-LC plus s2n-tls stack.
• The Rust binding is aws-lc-rs, and it’s the default cryptographic provider for rustls, which prioritizes post-quantum X25519MLKEM768 key exchange by default when backed by aws-lc-rs.

Think of AWS-LC as an engine block. On its own it does the raw cryptographic work, but it doesn’t drive anywhere by itself. s2n-tls is the car built around that engine, the thing that actually gets on the TLS road and talks to browsers and services. aws-lc-rs is the same engine re-wired to bolt into a Rust chassis, which is how rustls gets its power. When Amazon wanted its own services to speak post-quantum TLS, it didn’t build a new engine, it dropped ML-KEM into this one and let everything above it inherit the capability.

What is AWS-LC?

AWS-LC is a production cryptographic library, in active use across Amazon’s own services, that exposes the OpenSSL libcrypto API so existing code can link it with minimal changes. Its README states plainly that it “is based on code from the Google BoringSSL project and the OpenSSL project,” so it’s a downstream fork of BoringSSL (itself a fork of OpenSSL) that keeps broad OpenSSL API compatibility and then diverges on the parts AWS prioritizes, chiefly FIPS-validation cadence and post-quantum support. It’s written in C with architecture-specific assembly and licensed primarily under Apache 2.0, with portions under the OpenSSL, ISC, and BoringSSL licenses.

Source: aws/aws-lc, README and LICENSE.

The distinction to hold onto is the layering. AWS-LC is libcrypto, the primitive tier, and it does not by itself terminate a TLS connection. The TLS state machine, the handshake negotiation, and the security-policy selection all live one level up, in s2n-tls, which is AWS’s open-source TLS implementation (Apache 2.0) built to link against AWS-LC for its cryptographic operations. So “does AWS-LC support post-quantum TLS” is really two questions: does the library carry the ML-KEM primitive (it does, and validated), and does the TLS layer above it negotiate a post-quantum group (that’s an s2n-tls policy choice).

Source: aws/s2n-tls, repository.

Which post-quantum algorithms does AWS-LC support, and is it FIPS-validated?

AWS-LC carries validated ML-KEM and exposes ML-DSA for authentication, and its headline claim is a FIPS-validation first. AWS states that the FIPS 3.0 validation made AWS-LC “the first open source cryptographic module to provide post-quantum algorithm support within the FIPS module,” and that the module “includes the ML-KEM algorithm for all three provided parameter sets” (ML-KEM-512, ML-KEM-768, ML-KEM-1024).

Source: AWS Security Blog, “AWS-LC FIPS 3.0” (2024-12-10).

That validation is now complete on the NIST CMVP list. The AWS-LC 3 Cryptographic Module holds CMVP certificate #5314 (static, validated 2026-06-05) and #5298 (dynamic, validated 2026-06-03), both FIPS 140-3 Level 1, module version AWS-LC FIPS 3.1.0, and the #5298 security policy lists ML-KEM as its post-quantum approved algorithm with FIPS 203 KeyGen and Encap/Decap.

Sources: NIST CMVP, Validated Modules search (AWS-LC 3 Cryptographic Module, certs #5314 and #5298); NIST CMVP, cert #5298 security policy PDF.

One nuance is worth teaching, because regulators care about it. A CAVP-tested algorithm is not the same thing as a CMVP-validated module shipping it. CAVP validates that an algorithm implementation is correct in isolation; CMVP validates the whole cryptographic module. AWS-LC satisfies both for ML-KEM, which is exactly the combination a regulated deployment needs. The other post-quantum families are not present as of this writing: the AWS-LC main source tree ships modules only for ML-KEM and ML-DSA (crypto/fipsmodule/ml_kem and crypto/fipsmodule/ml_dsa), with no SLH-DSA, FN-DSA, or HQC implementation, and the validated module lists ML-KEM as its sole post-quantum approved algorithm.

Source: aws/aws-lc, fipsmodule source tree, main branch (confirmed 2026-07-09).

Algorithm	Where it lives	FIPS status
ML-KEM (512, 768, 1024)	AWS-LC primitive, negotiated via s2n-tls	Validated in the AWS-LC 3 module (CMVP #5314 / #5298), FIPS 140-3 Level 1
ML-DSA	s2n-tls authentication (needs AWS-LC v1.50.0 or newer)	Present in source; used for post-quantum authentication at the TLS layer
SLH-DSA, FN-DSA, HQC	Not implemented	Confirmed-absent from the AWS-LC main tree and the validated module (2026-07-09)
Classical RSA, ECDH, ECDSA	AWS-LC primitive, default unless a PQC policy is selected	Long-validated; quantum-vulnerable, so a non-PQC default produces HNDL exposure

Source: aws/s2n-tls, post-quantum usage guide; AWS-LC fipsmodule tree.

A note on the superlative. The defensible form is the one AWS actually wrote, the first open-source cryptographic module to carry post-quantum support in a FIPS 140-3 validation. The broader “first library, period” framing is a vendor claim that hasn’t been independently audited against every module ever validated, so the qualified wording is the one to trust.

How does s2n-tls use AWS-LC to go post-quantum?

s2n-tls goes post-quantum by linking a PQC-capable AWS-LC and then selecting a security policy that advertises the hybrid key-exchange groups. The library requires being built against AWS-LC to use post-quantum algorithms at all, and ML-DSA authentication specifically requires AWS-LC v1.50.0 or newer. Once that’s in place, the whole post-quantum behavior is a policy selection rather than application-level cryptographic rework.

Source: aws/s2n-tls, post-quantum usage guide.

The policies map to intent:

1. default_pq (currently the numbered policy 20250721) advertises the three hybrid groups X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, keeping classical fallback so a peer that can’t do post-quantum still connects.
2. cnsa_2 implements the NSA CNSA 2.0 TLS profile, mandating pure ML-KEM-1024 key exchange and ML-DSA-87 authentication with no classical fallback, for national-security-grade deployments.
3. cnsa_1_2_interop is the transitional policy for moving from CNSA 1.0 to CNSA 2.0 while interoperating with both.

Source: aws/s2n-tls, post-quantum usage guide.

The X25519MLKEM768 group is the one that carries most real traffic, and the two P-curve variants exist for stacks that must standardize on the NIST curves, most often because a profile like CNSA 2.0 requires them. The full mechanics of how those hybrid groups combine a classical share with an ML-KEM value live in TLS 1.3 Hybrid Key Exchange; the point here is that AWS-LC supplies the primitives and s2n-tls chooses whether to use them.

One deployment behavior belongs in any rollout plan. An s2n-tls server with post-quantum enabled will require PQ key exchange with any client that advertises PQ algorithms, which can trigger a HelloRetryRequest and one extra round trip if the client didn’t send a PQ key share in its first flight. That’s a deliberate security-over-latency choice, and it maps to the rebuild-plus-config pattern in Crypto-Agility rather than a runtime provider swap.

Source: aws/s2n-tls, post-quantum usage guide.

Where do AWS services deploy it?

AWS runs this stack under its own service endpoints, so the deployment surface is large and mostly invisible to the client. When AWS enabled post-quantum TLS on AWS Key Management Service (KMS), AWS Certificate Manager (ACM), and AWS Secrets Manager, the mechanism underneath was AWS-LC plus s2n-tls negotiating the X25519MLKEM768 hybrid group, so a client SDK connecting to those endpoints gets post-quantum key exchange on the wire.

Source: AWS Security Blog, “ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager” (2025-04-07).

Two things make that surface bigger than it looks. The first is the SDK path: AWS SDKs embed this cryptography, so client-side calls into AWS inherit the same timeline. The second is the migration off the pre-standard algorithm. AWS’s earlier post-quantum support used CRYSTALS-Kyber, and AWS announced that Kyber support continues through 2025 and is removed across AWS service endpoints in 2026 in favor of the standardized ML-KEM, with clients gracefully falling back to classical key agreement when Kyber is withdrawn. A client still pinned to a Kyber-only draft group is the thing to catch before that cutover.

Source: AWS Security Blog, “ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager” (2025-04-07).

What is aws-lc-rs, and how does rustls use it?

aws-lc-rs is the Rust cryptographic library that wraps AWS-LC, giving Rust code access to AWS-LC’s primitives (and its FIPS-validated build) through a safe API. Its README describes it as “a cryptographic library using AWS-LC for its cryptographic operations” that “strives to be API-compatible with the popular Rust library named ring,” and its stated motivation is to provide FIPS-validated cryptography as a drop-in replacement for ring. Under the hood it uses auto-generated FFI crates (aws-lc-sys and aws-lc-fips-sys) to call into AWS-LC.

Source: aws/aws-lc-rs, README.

This is how AWS-LC’s post-quantum capability reaches the Rust TLS ecosystem. rustls, the widely used Rust TLS library, supports pluggable cryptographic providers, and aws-lc-rs is the default one. The rustls documentation states that “by default it uses aws-lc-rs for implementing the cryptography in TLS,” and that the aws-lc-rs-backed provider “prioritizes post-quantum secure key exchange by default (using X25519MLKEM768).” So a rustls application on default settings gets hybrid post-quantum key exchange without extra configuration, because the AWS-LC primitives underneath it already carry ML-KEM.

Source: rustls, crate documentation on docs.rs (default provider aws-lc-rs; X25519MLKEM768 prioritized by default).

The chain is worth stating once, end to end. AWS-LC provides ML-KEM as a primitive; aws-lc-rs exposes that primitive to Rust; rustls, using aws-lc-rs as its default provider, negotiates X25519MLKEM768 on the wire. The same primitive tier serves both the C world (through s2n-tls) and the Rust world (through aws-lc-rs and rustls).

When should a developer reach for AWS-LC or s2n-tls?

Reach for this stack when the deployment context is AWS-adjacent, FIPS-bound, or already in C or Rust and you want validated post-quantum key exchange without waiting on a vendor roadmap. The decision usually resolves along a few concrete lines:

1. You need FIPS-validated ML-KEM today. AWS-LC is one of the earliest routes to a CMVP-validated module that carries ML-KEM, so a federal or regulated deployment that cannot ship research-grade code has a real, certificated option here.
2. You’re building TLS in C or C++ on the AWS ecosystem. s2n-tls linked against a PQC-capable AWS-LC gives hybrid post-quantum TLS as a policy selection, which is a lighter lift than integrating a separate PQC library into an existing TLS stack.
3. You’re building TLS in Rust. rustls with its default aws-lc-rs provider gives post-quantum X25519MLKEM768 by default, so much of the surface migrates on the dependency alone.
4. You want a ring-compatible Rust crypto library with a FIPS story. aws-lc-rs is designed as a drop-in for ring, which lowers the migration cost for Rust projects that already use ring’s API.

The counter-case is where the OpenSSL provider model, a different TLS library, or a platform-native module already anchors your stack, in which case OpenSSL 3.5’s native ML-KEM or another PQC-capable library may fit better. The library carries the primitive either way; the choice is about which ecosystem you already live in.

Common misconceptions

1. “Using AWS-LC means my traffic is post-quantum.” The library carries ML-KEM, and that capability is dormant until the TLS layer negotiates a post-quantum group. An s2n-tls deployment on a non-PQC policy, or a product that pins a pre-3.x AWS-LC, runs classical-only handshakes and keeps producing HNDL exposure. The capability is opt-in at the policy level.
2. “AWS-LC and s2n-tls are the same thing.” AWS-LC is libcrypto, the primitive layer; s2n-tls is the TLS implementation that links it. AWS-LC does not terminate TLS on its own, and s2n-tls needs AWS-LC underneath it to do post-quantum key exchange at all.
3. “A CAVP-tested ML-KEM is a validated module.” CAVP validates an algorithm implementation in isolation; CMVP validates the cryptographic module that ships it. For a regulated gate the CMVP module certificate is the load-bearing fact, and AWS-LC satisfies both.
4. “AWS-LC supports all the NIST PQC standards.” It carries ML-KEM (validated) and ML-DSA. SLH-DSA, FN-DSA, and HQC are confirmed-absent from the main source tree and the validated module as of 2026-07-09.
5. “The FIPS-validated build is a separate, closed product.” The FIPS build is the same open-source tree; there’s no differently-licensed commercial FIPS variant. The validation applies to the AWS-LC 3 module built from that public code.
6. “aws-lc-rs is unrelated to AWS-LC.” aws-lc-rs is the Rust binding that calls straight into AWS-LC through generated FFI crates, so it inherits AWS-LC’s primitives and its FIPS build. That’s how rustls, which defaults to aws-lc-rs, gets post-quantum key exchange.

Questions people ask

Is AWS-LC FIPS 140-3 validated for ML-KEM? Yes. The AWS-LC 3 Cryptographic Module holds CMVP certificates #5314 (static, 2026-06-05) and #5298 (dynamic, 2026-06-03), both FIPS 140-3 Level 1, module version AWS-LC FIPS 3.1.0, and ML-KEM (FIPS 203) is listed as an approved algorithm in the module’s security policy. Verify the current CMVP listing before a client deployment, because validation state changes over time.

What’s the difference between AWS-LC and s2n-tls? AWS-LC is the low-level cryptographic library (libcrypto), supplying primitives like ML-KEM, ECDH, and signatures. s2n-tls is the TLS library that links AWS-LC and actually negotiates connections, including choosing whether to advertise post-quantum hybrid groups through its security policies.

Which hybrid group does s2n-tls negotiate? Under its default_pq policy, s2n-tls advertises X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Under the cnsa_2 policy it mandates pure ML-KEM-1024 with ML-DSA-87 and no classical fallback, implementing the CNSA 2.0 TLS profile.

Do AWS services actually use it in production? Yes. AWS KMS, ACM, and Secrets Manager endpoints negotiate X25519MLKEM768 post-quantum TLS on the AWS-LC plus s2n-tls stack, and AWS SDKs embed the same cryptography, so client calls into those services inherit it.

Is aws-lc-rs the default crypto provider for rustls? Yes. rustls uses aws-lc-rs by default and, on that backend, prioritizes post-quantum X25519MLKEM768 key exchange by default, so a rustls application on default settings gets hybrid post-quantum key exchange. rustls also supports other providers, including ring, for projects that need them.

How does an application actually gain post-quantum support here? For C or C++, rebuild or relink against a PQC-capable AWS-LC, build s2n-tls against it, and select a PQC security policy such as default_pq. For Rust, use rustls on its default aws-lc-rs provider. In both cases the per-application work is a dependency bump and a policy or provider choice, which maps to the rebuild-plus-config pattern in Crypto-Agility.

Does AWS-LC still support CRYSTALS-Kyber? AWS’s earlier post-quantum support used Kyber, which continued through 2025 and is removed across AWS service endpoints in 2026 in favor of the standardized ML-KEM, with graceful fallback to classical key agreement. A client pinned to a Kyber-only draft group should move to the standardized X25519MLKEM768 before that cutover.

Is standalone ML-KEM available, or only hybrid? Both. The default_pq policy uses hybrid groups that pair ML-KEM with a classical curve, while the cnsa_2 policy uses pure ML-KEM-1024 with no classical component, for deployments bound by the NSA CNSA 2.0 profile.

---

Everything here is the map, given freely. When your team needs the AWS-LC versions, s2n-tls policies, and rustls providers across its estate assessed for a real post-quantum rollout, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.