This Shit is Hard: Making FIPS boring, fast, and post-quantum
- View all articles
Dimitri John Ledkov
Senior Principal Software Engineer
Chainguard
Dimitri John Ledkov Senior Principal Software Engineer
When I joined Chainguard, Federal Information Processing Standards (FIPS) compliance across the industry was in a dire state. Not because the standards were bad. Because almost nobody shipping an operating system treated FIPS as a product. It was a checkbox, ticked late, by someone else.
"FIPS-validated" meant that a vendor shipped a release and then sent a frozen snapshot of its crypto library to a lab. By the time the National Institute of Standards and Technology (NIST) issued a certificate, that version had Common Vulnerabilities and Exposures (CVEs), and the fixes lived in an unvalidated stream. Versions were either secure or compliant, but never both.
Worse, several vendors tied their userspace FIPS modules to their own kernels, so a validated OpenSSL in a container needed an older, more expensive edition of that vendor's OS on the host. Nothing in FIPS 140-3 requires that. It was vendor lock-in hiding behind a compliance badge, and it kept FIPS containers off the managed Kubernetes hosts people actually use.
I wanted to change that. Here's what it took.
Step one: Cut the kernel cord
FIPS modules leaned on the kernel for one reason: entropy. A validated module needs a validated randomness source, and pointing at the kernel lets the host carry the certificate. That works only on the handful of kernels that have ever been validated, which lag years behind.
So we moved the entropy source into the container. The Chainguard FIPS Provider for OpenSSL ships with the Chainguard CPU Time Jitter RNG Entropy Source, validated to SP 800-90B (certificate #E191), inside the container's userspace next to the module. Every key gets full entropy regardless of the kernel underneath, from a cloud provider's container-optimized OS to a locked-down FedRAMP host. We launched kernel-independent FIPS in November 2024 and extended it to every Java FIPS image in August 2025. The OpenSSL side went upstream under Apache-2.0.
Step two: Zero CVEs inside the boundary
Deploying anywhere is pointless if the module has known vulnerabilities. We attacked in two ways.
First, cryptographic agility by subtraction. Before submitting our 3.4 and 3.6 providers, we removed obsolete, historical, and legacy algorithms from the module entirely. Not disabled: gone. In June 2026, OpenSSL published CVE-2026-42770, a small-subgroup attack on X9.42 Diffie-Hellman peer validation that recovers the victim's private key. Upstream lists the FIPS modules for 3.0 through 4.0 as affected. Ours weren't. X9.42 DH, a 1990s construction that lets the peer supply its own subgroup order, was already gone from our submissions. Only safe-prime groups remained, so there was nothing to patch.
Our second angle was speed. When a CVE falls within the boundary, we submit an update to NIST as quickly as the program allows. Two landed while 3.6 was in the queue: CVE-2026-31790, a failure-handling bug in RSA key encapsulation that could leak uninitialized memory to a peer, and CVE-2026-28386, an out-of-bounds read in AES-CFB on AVX-512 processors. Both were fixed inside the module before validation; the certificate covers the fixed code. As a direct vendor in the Cryptographic Module Validation Program (CMVP), we submit fixes, algorithms, and operating environments ourselves.
So you stay on the validated module, on the FIPS edition, with zero known CVEs. No unvalidated stream, and no need to risk running the non-FIPS image.
Step three: Run everywhere
Auditors read the operational environments listed on a certificate. So we tested on everything. The 3.6 security policy lists 59 environments: RHEL 9 and 10, Ubuntu 20.04 through 26.04 LTS, Debian 12 and 13, SUSE Linux Enterprise Server 15 and 16, AlmaLinux, Rocky Linux, CentOS Stream, Amazon Linux, Azure Linux, Bottlerocket, and Google's Container-Optimized OS, on Intel Sapphire Rapids, AWS Graviton, Azure Cobalt, and Google Axion.
And a Raspberry Pi 5. Not a joke. It's one of the most widely deployed embedded boards anywhere; its BCM2712 has the Arm cryptographic extensions, and nobody has made it FIPS capable with hardware acceleration. There was demand, so we did it.
To my knowledge, we're the first validated module to list RHEL 10 or Ubuntu 26.04, ahead of the vendors who wrote them. Put a Chainguard FIPS image on the host you already have. The certificate backs you up.
Deploy anywhere, zero CVEs, no lock-in. A reasonable person would have stopped here.
Step four: Leapfrog
Two clocks are running. Harvest-now, decrypt-later means traffic recorded today gets decrypted once a big enough quantum computer exists, so long-lived secrets are already exposed. And the Commercial National Security Algorithm Suite (CNSA) 2.0 expects post-quantum algorithms in new national security acquisitions from January 2027, with NIST disallowing classical public-key algorithms after 2035.
Chainguard Containers have shipped post-quantum algorithms since April 2025. For FIPS customers, that was irrelevant: no validated module from any vendor had them.
On September 15, 2026, the Chainguard FIPS Provider for OpenSSL 3.6 received FIPS 140-3 validation, certificate #5523. It includes ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), all parameter sets, and all three standardized TLS 1.3 hybrids approved as services: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
OpenSSL 3.6 was in development from April 8, 2025, with hybrid key exchange already in our module, and for nearly all of that time, there was no way to declare a hybrid as an approved FIPS service. SP 800-227 was a draft. The Implementation Guidance was silent. Every browser had standardized on X25519MLKEM768; the validation program had no rulebook. We built to where we believed the rules should land, then helped write them through the Cryptographic Module User Forum (CMUF), the industry's channel to NIST and the CMVP.
The result is IG D.S, Key Encapsulation Mechanisms, published September 2, 2025. SP 800-227 went final on September 18. OpenSSL 3.6.0 shipped on October 1. We immediately reworked the submission to the new rules, tracked the April 2026 revision from the queue, and today that guidance is mandatory for every hybrid claim. It says what we built: a fixed set of named hybrids, module-controlled secret combining, and an ML-KEM that carries the security claim. X25519, never FIPS-approved on its own, appears as "no security claimed" and is allowed only inside the hybrid. A FIPS image can negotiate X25519MLKEM768 today and stay in approved mode.
The other half of leapfrogging was removing SHA-1. Not deprecating it. Removing it. The strings SHA-1, MD5, and MD4 do not appear anywhere in the 135-page security policy. The only legacy items left are two verification-only exhibits SP 800-131A still permits, ECDSA on P-192 and RSA with X9.31 padding, so old signatures can still be checked. Between shedding SHA-1 and adding the full post-quantum suite, Chainguard OS is, as far as I can tell, the only operating system on the market, open source or proprietary, whose validated cryptography satisfies the pure post-quantum requirements of CNSA 2.0. Most non-FIPS distributions don't ship post-quantum by default, and almost none are near removing SHA-1.
Certificates last five years. Our sunsets in September 2031. I designed this module to remain the right answer in 2035 by removing museum cryptography and blocking weak algorithms wherever they have security relevance: HMAC, signatures, and encryption.
Keeping the museum open, behind glass
Remove SHA-1 and MD5, and a startling amount of software breaks for reasons unrelated to security. PDF generators use MD5 for document IDs. Maven and Gradle publish MD5 and SHA-1 checksums because the repository format says so. Webpack hashes module names with MD4.
The old answer was to leave them in the FIPS module and hope, so we decided to do something different. NIST guidance distinguishes security-relevant from non-security-relevant digest use, so alongside the FIPS provider, we ship the Chainguard Legacy Approved provider: a digest-only MD4, MD5, and SHA-1. It hashes files. It cannot sign, verify, key an HMAC, or encrypt. PDFs render, Maven publishes, webpack builds, and no non-approved cryptography ever reaches the workload for a security purpose. Safe, post-quantum, validated, and everything keeps working.
None of us are safe until all of us are safe
Nearly everything above is upstream work: designs, bug reports, and patches to OpenSSL, AWS-LC, BoringSSL, LibreSSL, and dozens of other projects, including compiling obsolete algorithms out of OpenSSL entirely, which any distribution can now use.
We'll keep doing it, because your security depends on the weakest TLS stack in the conversation. The way forward is raising the minimum bar while doing the unglamorous engineering to keep everything working above it.
What's next
We're already designing the next submission: hardware-accelerated post-quantum performance, memory safety inside the module boundary, and memory-hard algorithms such as password hashing that cover real gaps NIST has not yet standardized.
FIPS used to be the afterthought that held you back. But when it’s built for from the start, it pushes you forward. We hope this encourages other vendors and maintainers to keep improving the cryptographic agility and safety of what they ship.
Read the announcement for the validated 3.6 provider and check out the Chainguard FIPS commitment page for current certificates.
Share this article
Related articles
- engineering
This Shit is Hard: Getting commercial software into regulated environments using AI
- engineering
This Shit is Hard: Factory-scale toolchain management
- engineering
What it took to reach 1 billion build manifests
- engineering
This Shit is Hard: Taming the Thundering Herd
- engineering
This Shit is Hard: Getting AI to prove where a number came from
- engineering
This Shit is Hard: Patching a vulnerability that has no fix