# BoringSSL: Google's Post-Quantum Implementation Status **Source**: https://quantumsequrity.com/blog/boringssl-pq-status **Category**: Implementations --- [← Back to Blog](../../blog.html) Implementations # BoringSSL: Google's Post-Quantum Implementation Status 11 min read BoringSSL is the TLS library that Google built when it forked OpenSSL in 2014. The project page at github.com/google/boringssl is blunt about its purpose. The README states that BoringSSL is "not intended for general use," that there are "no guarantees of API or ABI stability," and that anyone outside Google should think carefully before depending on it. Despite that warning, BoringSSL is the cryptographic engine inside Chrome, Android, Cloud Load Balancing, and a long list of Google services that touch billions of devices every day. When BoringSSL ships a post-quantum algorithm, it lands in the real world fast. This article walks through what BoringSSL actually supports for post-quantum cryptography as of 2026, how the rollout reached Chrome, and where the project sits relative to OpenSSL, NSS, and AWS-LC. ## Why BoringSSL Exists at All Before getting into post-quantum specifics, a quick orientation helps. OpenSSL is the dominant TLS library on Linux servers. Google found that maintaining patches against OpenSSL was painful and that some of the patches Google needed conflicted with the upstream roadmap. Rather than fight, Google forked. The fork strips features Google does not need (DTLS for SCTP, certain legacy ciphers, the SRP password protocol) and adds features Google does need (custom build system, chosen-prefix collision experiments, in-house hardening). The trade-off is that BoringSSL evolves on Google's schedule. Distributions that depend on OpenSSL get a stable release every year or so. BoringSSL has no formal releases at all. Users pin to a Git commit. That sounds chaotic but works because almost every BoringSSL consumer is also inside Google or under Google's direct guidance, such as Conscrypt for Android and certain CNCF projects. For deeper background on hybrid TLS architecture, see [hybrid encryption](../hybrid-encryption.html). ## What BoringSSL Ships for Post-Quantum The post-quantum surface area in BoringSSL is intentionally narrow. Google did not adopt every NIST candidate. Instead, the project tracks the algorithms that Chrome and Google's edge infrastructure plan to deploy. | Algorithm | Status in BoringSSL | |-----------|---------------------| | ML-KEM-768 | Shipped, used in Chrome hybrid TLS | | ML-KEM-512 | Implemented | | ML-KEM-1024 | Implemented | | X25519MLKEM768 hybrid | Default group in Chrome 131+ | | SecP256r1MLKEM768 | Available | | ML-DSA | Experimental work in tree | | SLH-DSA | Not present | | FN-DSA / Falcon | Not present | | HQC | Not present | | BIKE / FrodoKEM | Not present | This is a deliberately small menu compared to the Open Quantum Safe project's liboqs, which carries roughly two dozen post-quantum algorithms and parameter sets. Google's view is that shipping is winning and that adding extra algorithms multiplies the attack surface and the maintenance burden without adding security against the only adversary that matters: a future cryptanalytically relevant quantum computer. ## How ML-KEM Landed in Chrome The deployment path went through three named TLS groups, each one pulling Chrome closer to a NIST-final design. The first group was X25519Kyber768Draft00, deployed behind a flag in Chrome 116 in August 2023. This used a draft of Kyber that pre-dated the NIST FIPS 203 standardization. It was a hybrid: client and server combined the shared secrets from X25519 (classical) and Kyber-768 (post-quantum) using a hash, so neither algorithm alone could be the weak link. The second iteration, X25519MLKEM768, replaced the draft Kyber with the FIPS 203 final ML-KEM. NIST published FIPS 203 on August 13, 2024. Within months, BoringSSL switched. The wire format changed slightly, which is why deploying both client and server simultaneously matters. The third stage, the Chrome 131 default rollout in late 2024, made X25519MLKEM768 the preferred TLS 1.3 key exchange group for any server that advertises support. This was not a controlled experiment behind a flag. It became the negotiation default. Cloudflare's blog and Google's Online Security blog both confirmed double-digit percentages of TLS handshakes using ML-KEM within weeks. For a deeper look at how this maps to the FIPS 203 specification, see [ML-KEM explained](../ml-kem-explained.html). ## How BoringSSL's ML-KEM Implementation Compares BoringSSL's ML-KEM is written in C. The implementation lives in the boringssl/crypto/mlkem subdirectory, with assembly-optimized backends for AVX2 (x86_64) and Neon (aarch64). The C code follows BoringSSL's house style: explicit memory wiping with OPENSSL_cleanse, fixed-time comparisons, and bounded stack usage so the algorithms work inside Android's app processes. Compared to liboqs (the reference for Open Quantum Safe), BoringSSL's version is slimmer. liboqs supports build-time selection of multiple ML-KEM variants and parameter levels. BoringSSL hard-codes the parameters it needs and prunes the rest. This makes the binary smaller and reduces fuzzing surface. Compared to AWS-LC, which is Amazon's BoringSSL fork, the algorithms are nearly identical. AWS-LC re-syncs from BoringSSL periodically and tracks the same post-quantum priorities. AWS-LC is what AWS KMS, ALB, and CloudFront use under the hood. The two libraries can be thought of as siblings with separate productization but a shared engineering core. ## What BoringSSL Does Not Have Equally important is the negative space. BoringSSL is not the place to look for SLH-DSA, FN-DSA, HQC, BIKE, or FrodoKEM. Those algorithms are present in oqs-provider for OpenSSL 3 and in Botan, but Google has not adopted them in BoringSSL. The reasoning is documented across mailing lists: SLH-DSA is too slow for online TLS, FN-DSA was not yet final at the time decisions were made, and HQC/BIKE were not selected as final standards by NIST until 2025. This means that if your application requires algorithm diversity beyond ML-KEM, you cannot rely on BoringSSL alone. Most production deployments live with that trade-off because diversity is a long-tail concern and ML-KEM is the immediate need. ## Build and Integration Considerations BoringSSL ships no shared library by default. Consumers vendor it in or compile it as part of their own build. The cmake configuration produces libcrypto and libssl static archives. There is a Bazel build maintained for Chromium integration. API stability is explicitly not promised. Even within Google, callers pin to specific commits. For external users, the practical advice is to track an LTS-like commit such as the chromium-stable branches, or to use AWS-LC, which packages a more conservative variant with proper releases. For migration planning across both Google and Amazon-managed services, see [AWS KMS quantum migration](../aws-kms-quantum-migration.html). ## Performance Characteristics ML-KEM is engineered to be fast. On a modern x86_64 server, BoringSSL's ML-KEM-768 keypair generation completes in a few hundred microseconds, and encapsulation/decapsulation runs in similar time. The total round trip cost added to a TLS 1.3 handshake by switching from X25519 alone to X25519MLKEM768 is dominated by the increased payload size, not by the CPU work. The numbers Google has shared publicly indicate that the X25519MLKEM768 ClientHello message grows by about a kilobyte. For most TCP MSS values that means an extra packet at handshake time. On lossy networks (mobile, satellite, congested links) the extra packet shows up in handshake latency tail percentiles. Google's deployment data suggests p99 handshake time grew by single-digit milliseconds in most regions. On constrained networks the regression is larger and remains a topic of active engineering. For background on the underlying problem, see [harvest now decrypt later](../harvest-now-decrypt-later.html). ## How the Roadmap Continues BoringSSL's roadmap, inferred from commit traffic and public talks by Google's TLS team, points in three directions. The first direction is ML-DSA. Authentication via post-quantum signatures is a heavier change than KEM swap because certificates are larger, the chain of CAs is involved, and clients must verify multiple signatures per handshake. ML-DSA-65 keys and signatures together can grow a TLS handshake by several kilobytes. BoringSSL is doing the engineering work but has not flipped the default. The second direction is signed transcripts and post-quantum-secure session resumption. TLS 1.3 session tickets and PSK flows have their own forward-secrecy properties, but the full picture of quantum-safe resumption needs careful thought. BoringSSL is participating in IETF discussions through Google's TLS WG members. The third direction is transport beyond TLS. QUIC uses TLS 1.3 for its handshake, so QUIC inherits ML-KEM automatically. HTTP/3 over QUIC therefore got post-quantum protection for free in Chrome 131. SSH and other protocols that BoringSSL touches indirectly through Conscrypt and Tink are following. ## How Chrome's Hybrid Group Works on the Wire The X25519MLKEM768 hybrid TLS group combines two key exchange computations into one negotiated parameter. On the wire, the structure looks like this. The client offers the group identifier (0x11ec, in the IANA-assigned range for hybrid groups) in its supported_groups extension. If the server matches, the client sends a key share extension that contains both an X25519 public key (32 bytes) and an ML-KEM-768 public key (1184 bytes). The server replies with its own X25519 public share and an ML-KEM-768 ciphertext (1088 bytes). Both sides then derive an X25519 shared secret and an ML-KEM-768 shared secret, concatenate them in a defined order, and feed the result through HKDF as the new TLS 1.3 secret material. This means the actual added bytes per handshake are roughly 2.3 kilobytes. On a server with low MTU (such as MTU 1500 minus IPv6 overhead minus TCP overhead), this means an extra packet, sometimes two extra packets if other extensions are also large. The packet-count increase is the number that matters for handshake latency, not the absolute byte count. For mobile networks where round trip times can be 100ms or more, an extra round trip would matter. TLS 1.3 already does the application data exchange on the same trip after the handshake, so the extra packet is amortized into the existing handshake round trip. Practical measurements at Cloudflare and Google have indicated single-digit-millisecond p50 increases and tail-latency increases of tens of milliseconds for the worst networks. For background on key exchange concepts, see [DH group exchange](../dh-group-exchange.html). ## Internal Versus External BoringSSL A nuance worth understanding: the BoringSSL inside Chrome and Android is sometimes ahead of the public github.com/google/boringssl mirror. Google has internal CI and rollout processes that bring features into production before they appear in the public commits. This is why a Chrome version sometimes negotiates a TLS group that does not appear in the public BoringSSL build. For external projects depending on BoringSSL (or AWS-LC, which mirrors BoringSSL), this means there can be a lag in feature visibility. The general guidance is to track AWS-LC releases for stability, since AWS productizes the post-quantum work with releases on a regular cadence rather than relying on Git commits as the unit of release. ## Frequently Asked Questions ### Can I use BoringSSL in production myself? Technically yes, in the same sense that you can edit the kernel directly. Practically, Google does not promise stability and does not provide releases. Most projects use AWS-LC if they want a BoringSSL-like API with a stable release cadence, or oqs-provider over OpenSSL 3 if they want broader algorithm coverage. ### Is BoringSSL FIPS validated? Google maintains FIPS 140-3 validation of a specific BoringSSL module called BoringCrypto, which is a frozen subset built for compliance. The validated module did not include post-quantum algorithms in its early validations. Updated FIPS submissions including ML-KEM and ML-DSA are progressing through CMVP through 2026. ### Why did Chrome ship post-quantum before browsers like Firefox? Chrome controls its own TLS stack via BoringSSL and can ship updates independently. Firefox uses Mozilla NSS, which has a different release model. Firefox is rolling out post-quantum support in stages aligned with the NSS roadmap. See [Mozilla NSS PQ status](nss-pq-status.html) for the parallel story. ### Does BoringSSL implement the standardized FIPS 203 ML-KEM? Yes. BoringSSL implemented an early Kyber draft, then migrated to the final FIPS 203 ML-KEM specification. The wire format used in Chrome's X25519MLKEM768 group is the standardized one. ### Where can I read the actual code? The repository is at github.com/google/boringssl. The post-quantum modules are under crypto/mlkem and crypto/kyber (some legacy paths remain). Test vectors live under crypto/mlkem/test. ### Does BoringSSL support multiple PQC providers like OpenSSL does? No. BoringSSL has no provider architecture. Algorithms are compiled directly into the library. This is a deliberate simplification. There is no equivalent of oqs-provider for BoringSSL. ### How does Chrome handle servers that don't support hybrid TLS? Chrome includes both X25519MLKEM768 and X25519 in its supported_groups list. The server picks whichever group it supports best. If the server only supports X25519, the handshake falls back to classical key exchange. This negotiation is the standard TLS 1.3 mechanism; no special fallback logic is needed. ### What Chrome version was the first with X25519MLKEM768 enabled by default? Chrome 131 enabled X25519MLKEM768 by default for TLS 1.3 connections. Earlier versions had it behind a flag or as an experimental group. The default rollout was a watershed moment for post-quantum TLS deployment. ## Sources 1. BoringSSL repository, github.com/google/boringssl 2. NIST FIPS 203 (Module-Lattice-Based Key-Encapsulation Mechanism Standard), August 2024 3. Google Online Security Blog, "Protecting Chrome Traffic with Hybrid Kyber KEM," 2023 4. IETF draft-kwiatkowski-tls-ecdhe-mlkem (X25519MLKEM768) 5. AWS-LC repository, github.com/aws/aws-lc 6. Cloudflare Research, post-quantum deployment posts on blog.cloudflare.com ## Related Articles - [What is post-quantum cryptography](../what-is-post-quantum-cryptography.html) - [ML-KEM explained](../ml-kem-explained.html) - [Hybrid encryption](../hybrid-encryption.html) - [Harvest now decrypt later](../harvest-now-decrypt-later.html) - [OpenSSL PQC status 2026](../openssl-pqc-status-2026.html) --- ### Protect Your Data Before Q-Day Arrives QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats. [Try QNSQY](../../pricing.html)