Post-quantum support in public libraries, protocols and platforms

The .NET 10 libraries add MLKem, MLDsa and SlhDsa to System.Security.Cryptography, with MLDsa and SlhDsa marked as experimental under diagnostic SYSLIB5006. Availability depends on the host supplying OpenSSL 3.5 or newer, or Windows CNG with post-quantum support.

The public header include/openssl/mlkem.h implements ML-KEM-768 and ML-KEM-1024 and cites FIPS 203 directly. BoringSSL carries no release versions, so a deployment pins a commit rather than a version number.

Botan 3.6.0, dated 2024-10-21 in the project release notes, added ML-KEM, ML-DSA and SLH-DSA under their standardised names, beside the pre-standard Kyber, Dilithium and SPHINCS+ code. Key establishment and signatures arrived in the same release.

Go 1.24 added the crypto/mlkem package for ML-KEM-768 and ML-KEM-1024, and enabled the hybrid X25519MLKEM768 key agreement in crypto/tls by default when Config.CurvePreferences is nil; the GODEBUG setting tlsmlkem=0 reverts that default. The release notes record key establishment, not signatures.

JDK 24 delivered JEP 496, exposing ML-KEM key generation, encapsulation and decapsulation through the KeyPairGenerator, KEM and KeyFactory APIs at all three parameter sets. These are primitives; hybrid key exchange for TLS 1.3 is a separate proposal, JEP 527, which was still at Candidate on the verification date.

liboqs 0.15.0, released 2025-11-14, integrated an SLH-DSA implementation and removed the pre-standard Dilithium code, with SPHINCS+ scheduled for removal in 0.16.0. The Open Quantum Safe project states the library is for research and prototyping and directs readers to its limitations on intended use.

NSS release notes reference the hybrid mlkem768x25519 key agreement, so the implementation is present in the tree. We could not identify the release that introduced it from the published notes, so we record no version here.

OpenSSL 3.5.0, released 2025-04-08, added ML-KEM, ML-DSA and SLH-DSA. The same release changed the default TLS key shares to offer the hybrid X25519MLKEM768 group beside X25519, and changed the default supported-groups list to prefer hybrid post-quantum KEM groups.

wolfSSL states that its Dilithium implementation was updated to ML-DSA and is fully supported in release 5.8.0, dated 2025-04-28. That announcement gives no release number for ML-KEM (FIPS 203), so this row records none.

OpenSSH 9.9 added the hybrid mlkem768x25519-sha256 key agreement and OpenSSH 10.0, April 2025, made it the default. The project states that every post-quantum algorithm it implements is a hybrid pairing a post-quantum scheme with a classical one; key agreement has been on by default since 9.0, April 2022, initially with sntrup761x25519-sha512, which is not a NIST-standardised scheme.

oqs-provider exposes post-quantum key encapsulation and signature algorithms to OpenSSL 3 through the provider interface, including hybrids such as X25519 with ML-KEM-768 and SecP384r1 with ML-KEM-1024. The project documentation states the code is not meant to be used in productive deployments.

AWS documents hybrid TLS to KMS endpoints via s2n-tls, combining ECDH with ML-KEM, and states the hybrid suites are implemented for key exchange only and not for data encryption under a KMS key. The client has to be configured to prefer post-quantum TLS, so the behaviour is opt-in.

Cloudflare documents X25519MLKEM768, TLS group 0x11ec, for inbound connections and marks the earlier X25519Kyber768Draft00 group as obsolete. The same documentation states that post-quantum authentication from the visitor to the edge is still under development, so this row is key agreement only.

Chrome 131 dropped the hybrid Kyber768 codepoint 0x6399 and offers hybrid ML-KEM at codepoint 0x11ec for TLS key agreement. Chrome pairs X25519 with ML-KEM rather than offering ML-KEM on its own.

Cloud KMS offers ML-DSA-65 and SLH-DSA-SHA2-128S for digital signatures, announced at Preview launch stage on 2025-02-21. This row covers signatures, not key establishment.

The draft specifies how a post-quantum key encapsulation mechanism is combined with a classical key exchange inside one TLS 1.3 key share, which is the construction the hybrid groups elsewhere in this table implement. On the verification date it sat in the RFC Editor queue at revision 16, dated 2025-09-07, with no RFC number assigned.