up:: In the Protocols MOC

Cloudflare CIRCL

Cloudflare CIRCL (Cloudflare Interoperable Reusable Cryptographic Library) is an open-source cryptographic library written in Go and maintained by Cloudflare, that provides both classical elliptic-curve primitives and a deep set of post-quantum ones, including production Go implementations of the NIST-standardized ML-KEM, ML-DSA, and SLH-DSA. It is the most complete post-quantum toolkit a Go team can reach for today, and it is the cryptographic engine behind Cloudflare’s own network-wide post-quantum key agreement, so it runs underneath a large share of real internet traffic. Its maintainers label it experimental, and it is not a FIPS-validated module, so “the Go service uses CIRCL” answers the algorithm-availability question and not the regulated-compliance question.

The short version:

• CIRCL is Cloudflare’s open-source Go crypto library, and it ships finalized-standard ML-KEM (kem/mlkem), ML-DSA (sign/mldsa), and SLH-DSA (sign/slhdsa) alongside the earlier pre-standard Kyber and Dilithium schemes under separate package names.
• Go’s standard library covers only ML-KEM key exchange as of Go 1.24 (crypto/mlkem plus automatic X25519MLKEM768 in crypto/tls), so a plain TLS server on modern Go needs no library at all; CIRCL is what you reach for when you need PQC signatures, hybrid signatures, X-Wing, or PQC certificate experiments the standard library doesn’t provide.
• cfgo (github.com/cloudflare/go) is Cloudflare’s experimental fork of the Go toolchain that patches crypto/tls to consume CIRCL, which is how CIRCL reaches the TLS handshake and how Cloudflare experiments with post-quantum certificates and hybrid signatures like Ed25519-Dilithium2.
• CIRCL is a primitive toolkit, so it also ships classical X25519, Ed25519, and NIST P-curve ECC as first-class defaults; a service that imports CIRCL but still negotiates classical-only key exchange keeps accumulating HNDL exposure.
• CIRCL is production-deployed but self-labeled experimental, and no CMVP-validated CIRCL module exists, so a FIPS-required workload needs a separate validated module even though the algorithms are correct-by-construction against the FIPS documents.

Think of CIRCL as a well-stocked parts shop for Go cryptography, next to the small set of standard parts Go now keeps on its own shelf. If all you need is the common part, the ML-KEM key-exchange bolt that TLS uses, Go’s own shelf already has it and you never walk into the shop. You go to CIRCL when the job needs parts the standard shelf doesn’t carry yet: the post-quantum signatures, the hybrid signatures, the experimental certificate formats. The parts are real and they fit, and the shop’s own sign still reads “experimental, we may rearrange the shelves,” which a regulated buyer has to read before wiring one into a compliance-bound machine.

What is Cloudflare CIRCL?

Cloudflare CIRCL is a Go module (github.com/cloudflare/circl) that collects modern and post-quantum cryptographic primitives in one place, published under a BSD-3-Clause license. It is original Cloudflare work rather than a fork of another crypto library, and it is corporate-maintained open source, not a community-governed foundation project. Its role in the ecosystem is the Go counterpart to what liboqs is for C and what the Bouncy Castle post-quantum provider is for Java, an ecosystem-specific place a developer in that language goes to get post-quantum algorithms.

Source: CIRCL repository and README, github.com/cloudflare/circl.

Two things make CIRCL unusual among PQC libraries. The first is scale of real use. Cloudflare turned on post-quantum key agreement across its global network, and CIRCL supplies the ML-KEM and hybrid key-agreement code on the server side of those handshakes, so the library carries live traffic rather than demo traffic.

Source: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum”.

The second is the explicit stability caveat. The repository states plainly that “changes in the code, repository, and API occur in the future,” a maintainer’s warning that the library is a moving target and that a production consumer should pin a version and expect churn.

Source: CIRCL repository, github.com/cloudflare/circl.

What post-quantum algorithms does CIRCL implement?

CIRCL is one of the most PQC-complete libraries in any language, and the distinction it forces a reader to hold is between the finalized FIPS schemes and the pre-standard schemes of the same mathematical lineage, because CIRCL ships both under different package names and they do not interoperate on the wire. The table below is the coverage as published in the Go package documentation.

Scheme	CIRCL package	Standard / status	Landed in
ML-KEM 512/768/1024	kem/mlkem	FIPS 203, finalized	v1.4.0 (2024-08-20)
Kyber 512/768/1024	kem/kyber	pre-standard round 3, superseded by ML-KEM	earlier
ML-DSA 44/65/87	sign/mldsa	FIPS 204, finalized	v1.5.0 (2024-10-10)
Dilithium 2/3/5	sign/dilithium	pre-standard, deprecated for new use	earlier
SLH-DSA	sign/slhdsa	FIPS 205, finalized	v1.6.2 (2025-12-22)
X-Wing	kem/xwing	general-purpose ML-KEM-768 + X25519 hybrid KEM	v1.6.0 (2025-02-04)
Ed25519-Dilithium2	sign/eddilithium2	hybrid classical + PQC signature	earlier
Ed448-Dilithium3	sign/eddilithium3	hybrid classical + PQC signature	earlier
Hybrid KEM for TLS	kem/hybrid	X25519Kyber768Draft00, X25519MLKEM768	earlier
FrodoKEM-640-SHAKE	conservative lattice KEM	research and interop	earlier
SIDH / SIKE	isogeny KEM, cryptographically broken	retained for testing only	earlier

Sources: CIRCL Go package documentation, pkg.go.dev/github.com/cloudflare/circl; version-landed facts from the git tags and published release notes at github.com/cloudflare/circl/releases (CIRCL ships no standalone changelog, so tags plus release notes are the authoritative record).

Three details in that table are load-bearing for the transition:

1. The finalized-versus-pre-standard split is real and permanent. kem/mlkem targets the finalized FIPS 203 (ML-KEM), and kem/kyber holds the earlier round-3 scheme; a CBOM has to record which import path a service actually uses, because a peer on kem/kyber will not interoperate with a finalized-standard peer and will need a second migration.
2. ML-KEM landed against the final standard from day one. CIRCL v1.4.0 shipped on 2024-08-20, one week after final FIPS 203 (ML-KEM) was published on 2024-08-13, so kem/mlkem matched the finalized document from the start rather than tracking a draft.
3. The same v1.5.0 release that added ML-DSA also added the standardized X25519MLKEM768 hybrid KEM, which is the group now carrying real post-quantum TLS traffic.

Source: github.com/cloudflare/circl/releases; final FIPS 203 publication date from NIST, FIPS 203.

How does CIRCL relate to Go’s standard-library crypto/mlkem?

CIRCL is the extended library and crypto/mlkem is the standard library, and the boundary between them decides whether a Go team needs CIRCL at all. Go 1.24 added crypto/mlkem to the standard library, exposing ML-KEM-768 and ML-KEM-1024 directly, and it made crypto/tls negotiate the X25519MLKEM768 hybrid group automatically. So on modern Go, an ordinary TLS server gains post-quantum key exchange on the toolchain upgrade alone, with no third-party dependency and no code change.

Sources: Go crypto/mlkem; Go 1.24 release notes.

What the standard library does not cover is everything past ML-KEM key exchange. crypto/mlkem is key encapsulation only, so it gives you the confidentiality half of the transition and nothing for signatures. CIRCL is where a Go program goes for the parts the standard library omits:

1. Post-quantum signatures: ML-DSA (sign/mldsa) and SLH-DSA (sign/slhdsa), which the standard library does not yet provide.
2. Hybrid signatures like Ed25519-Dilithium2 (sign/eddilithium2), used in Cloudflare’s post-quantum certificate experiments.
3. Broader KEM options beyond ML-KEM, including X-Wing (kem/xwing) and FrodoKEM, for teams that want a general-purpose hybrid KEM or a more conservative lattice fallback.
4. The KEM outside TLS, when an application needs to call ML-KEM directly for its own protocol rather than let crypto/tls handle it.

Source: pkg.go.dev/github.com/cloudflare/circl.

The practical takeaway is that the two are complementary rather than competing. For plain TLS termination on Go 1.24 or newer, the standard library is enough and is the simpler choice. For PQC signatures, PQC certificates, or KEM work beyond ML-KEM-in-TLS, CIRCL is the mature Go option, and much of Cloudflare’s forward-looking PQC work rides on it.

What is cfgo, and how does CIRCL reach TLS?

cfgo is Cloudflare’s experimental fork of the Go toolchain (github.com/cloudflare/go) that patches Go’s crypto/tls to consume CIRCL, and it is how CIRCL’s post-quantum primitives reach the TLS handshake in Cloudflare’s own experiments. Standard Go’s crypto/tls is a closed surface that a third-party library cannot extend from outside, so to wire CIRCL into TLS at the layers Go doesn’t expose, Cloudflare maintains a whole forked toolchain rather than an importable package.

Source: cfgo, Cloudflare’s fork of Go, github.com/cloudflare/go.

The distinction that matters is between the two integration paths a Go team can take:

1. Upstream Go, where crypto/tls on Go 1.24+ negotiates the standardized X25519MLKEM768 hybrid group automatically. This is the mainstream, supported path for post-quantum key exchange.
2. The cfgo fork, where the patched toolchain enables the experimental surface that upstream doesn’t carry yet: post-quantum and hybrid certificates, delegated credentials, Encrypted Client Hello, and hybrid signatures like Ed25519-Dilithium2. This is a research toolchain, and building against it is a toolchain swap, not a dependency bump.

Source: github.com/cloudflare/go; Cloudflare SSL/TLS post-quantum documentation, developers.cloudflare.com/ssl/post-quantum-cryptography.

CIRCL’s kem/hybrid package is the other half of this story. Cloudflare deployed the pre-standard X25519Kyber768Draft00 hybrid group (TLS identifier 0xfe31) network-wide, on by default, starting in 2022, and the finalized X25519MLKEM768 group (TLS identifier 0x11ec) is the live successor. Hybrid is the correct transitional posture, pairing a classical curve with a post-quantum KEM so a session survives if either half holds, which the hybrid pattern and the TLS hybrid key exchange notes cover in full.

Source: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum”.

When should a Go developer reach for CIRCL?

Reach for CIRCL when the job needs post-quantum cryptography that Go’s standard library doesn’t cover, and skip it when the standard library already does. The decision comes down to what part of the transition the service touches:

1. Plain TLS key exchange on Go 1.24+: use the standard library. crypto/tls negotiates X25519MLKEM768 automatically, and you gain post-quantum key exchange on the toolchain bump with no dependency.
2. Post-quantum signatures (ML-DSA, SLH-DSA): use CIRCL, since the standard library provides no PQC signature scheme yet.
3. PQC or hybrid certificates and delegated credentials: use CIRCL through the cfgo fork, understanding it is experimental research tooling.
4. KEM work outside TLS, or a general-purpose hybrid KEM like X-Wing: use CIRCL for the direct package call.
5. A constrained device or microcontroller: reach for neither, since CIRCL targets server and cloud Go workloads; prefer a C implementation such as liboqs for small targets.

Because Go links statically, gaining a CIRCL algorithm means adding or upgrading the github.com/cloudflare/circl dependency and recompiling the binary, then calling the relevant package directly. There is no runtime provider to register and no config-only path, which places CIRCL in the rebuild style of crypto-agility: the per-application cost is one dependency bump plus one recompile plus one redeploy per binary, multiplied across every Go service that needs it.

Source: pkg.go.dev/github.com/cloudflare/circl.

Is CIRCL FIPS-validated?

No CMVP-validated CIRCL module has been identified, and this is the decisive fact for any regulated workload. The algorithms in CIRCL are present and correct-by-construction against the FIPS documents, and “present in an open-source Go module” is a different claim from “shipped inside a CMVP-validated cryptographic module.” The two must never be conflated, because CAVP validates an algorithm implementation while CMVP validates a bounded module, and a compliance gate turns on the module, not the algorithm.

Source: NIST Cryptographic Module Validation Program, validated-modules list, csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules.

The consequence is concrete. A Go service in a FIPS-required environment needs a validated module underneath its cryptographic operations, for example a Go build against a validated BoringCrypto-style module or an HSM, and CIRCL by itself does not satisfy that requirement. The peer library carrying ML-KEM into a FIPS 140-3 validation is AWS-LC, not CIRCL, and Cloudflare’s own edge FIPS 140 compliance is delivered through validated modules and HSMs rather than through CIRCL as a validated module. This confirmed-absent status should be re-verified against the CMVP list before it is relied on, because validations are added over time.

Source: NIST CMVP validated-modules list, csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules.

Common misconceptions

• “CIRCL replaces Go’s standard crypto library.” CIRCL complements it. Go’s crypto/mlkem and automatic X25519MLKEM768 in crypto/tls cover ML-KEM key exchange as of Go 1.24, and CIRCL adds what the standard library omits, the PQC signatures, hybrid signatures, and broader KEMs.
• “Using CIRCL settles FIPS compliance.” The algorithms are correct, and CIRCL is not a CMVP-validated module, so a FIPS-scoped operation still needs a validated module such as an HSM or a validated Go crypto build. Algorithm correctness and module validation are separate gates.
• “CIRCL’s Kyber and ML-KEM are the same thing.” kem/kyber is the pre-standard round-3 scheme and kem/mlkem is the finalized FIPS 203 (ML-KEM). They carry different package names, they do not interoperate on the wire, and only the finalized kem/mlkem should ship for new work.
• “Importing CIRCL makes a Go service post-quantum by default.” CIRCL is a primitive toolkit, so a service that imports it but still negotiates classical X25519 or ECC key exchange gains no post-quantum protection on that channel. The safe-by-default behavior comes from the deployment choice, which is why Cloudflare’s network-wide, on-by-default hybrid rollout matters for traffic behind its edge.
• “cfgo is how everyone should deploy CIRCL in TLS.” cfgo is Cloudflare’s experimental research fork for certificates and advanced features. For mainstream post-quantum TLS key exchange, upstream Go 1.24+ is the supported path, and cfgo is for the experimental surface upstream doesn’t carry.
• “CIRCL is a stable, frozen library.” Its maintainers state that the code, repository, and API may change, so a production consumer pins a version and plans for churn rather than assuming a fixed interface.

Questions people ask

Do I need CIRCL if I’m on Go 1.24 or newer? For plain TLS key exchange, no. Go 1.24’s standard library ships crypto/mlkem and negotiates the X25519MLKEM768 hybrid group automatically, so an ordinary TLS server gains post-quantum key exchange on the toolchain upgrade alone. You need CIRCL when you want PQC signatures, hybrid signatures, PQC certificates, or KEM work beyond ML-KEM-in-TLS.

What post-quantum signatures does CIRCL support? It ships finalized ML-DSA (sign/mldsa, modes 44/65/87) and SLH-DSA (sign/slhdsa), plus the pre-standard Dilithium (sign/dilithium) kept separately and treated as deprecated for new use, and the hybrid classical-plus-PQC signatures Ed25519-Dilithium2 and Ed448-Dilithium3.

Is CIRCL FIPS-validated? No CMVP-validated CIRCL module has been identified. The algorithms are correct against the FIPS documents, and a regulated workload still needs a validated cryptographic module underneath, such as an HSM or a validated Go crypto build, because CMVP validates a module rather than an algorithm.

What’s the difference between CIRCL and cfgo? CIRCL (github.com/cloudflare/circl) is the importable Go library of primitives. cfgo (github.com/cloudflare/go) is Cloudflare’s experimental fork of the Go toolchain that patches crypto/tls to consume CIRCL, which is how CIRCL reaches the TLS handshake for post-quantum certificate and hybrid-signature experiments that upstream Go doesn’t expose.

Is CIRCL production-ready? It is production-deployed, since it runs Cloudflare’s network-wide hybrid key exchange, and it is also self-labeled experimental, with the maintainers warning the API may change. The safe posture is to pin a specific version, track releases, and treat it as a fast-moving dependency.

How does a Go application actually gain a CIRCL algorithm? Because Go links statically, the application adds or upgrades the github.com/cloudflare/circl dependency, recompiles the binary, and calls the relevant package. There is no runtime provider to register, so the cost is a recompile-and-redeploy per binary, which is the rebuild style of crypto-agility.

Does traffic behind Cloudflare already use CIRCL? Yes on the server side of the edge hop. Cloudflare enabled post-quantum hybrid key agreement across its network using CIRCL, so a TLS 1.3 connection negotiating a hybrid group through Cloudflare runs CIRCL on Cloudflare’s side. The origin hop between Cloudflare and the backend is a separate channel that has to be confirmed on its own.

Should I use CIRCL or liboqs? For a Go codebase, CIRCL is the native fit. For C, C-embeddable, or constrained-device targets, liboqs is the counterpart; for Java, the Bouncy Castle post-quantum provider plays the same ecosystem role. The choice follows the language and the deployment target.

---

Everything here is the map, given freely. When your team needs its Go services and Cloudflare-fronted traffic assessed for a safe post-quantum rollout, including which schemes are actually in the binary and where a validated module has to sit, that is what an alignment briefing is for.

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