The FIPS 140-3 Go Cryptographic Module
44 comments
·July 15, 2025tptacek
FiloSottile
> Applications that have no need for FIPS 140-3 compliance can safely ignore [this page], and should not enable FIPS 140-3 mode.
https://go.dev/doc/security/fips140
Yup.
chrisabrams
> Having said all this: nobody should be using crypto/fips140 unless they know specifically why they're doing that. Even in its 140-3 incarnation, FIPS 140 is mostly a genuflection to FedGov idiosyncrasies.
What should folks use then?
tptacek
crypto/, not crypto/fips140.
FiloSottile
To nitpick, there is no special crypto/fips140 package. (Ok, there is, but it just has an Enabled() bool function.)
FIPS 140-3 mode is enabled by building with GOFIPS140=v1.0.0 (or similar, see https://go.dev/doc/security/fips140), but it shares 99% of the code with non-FIPS mode.
Still, your message is right, just GOFIPS140=off (the default!), not GOFIPS140=v1.0.0.
twoodfin
Would you say there’s a brown M&M’s aspect (intentional or otherwise) to FIPS-140, or is it all just bowing to the sovereign for his indulgences?
YawningAngel
Not really. It isn't hard to use FIPS validated software, it's just annoying to do because most libraries you would want to use aren't FIPS compliant by default for good reasons. If you can get a government contract in the first place you are already administratively competent enough to use FIPS.
EvanAnderson
> If you can get a government contract in the first place you are already administratively competent enough to use FIPS.
Speaking as a sysadmin for a local government roped into FIPS requirements by way of FBI CJIS compliance I can safely say your assumption of competence is incorrect.
tptacek
Yeah, I don't think there's any malice to any of this; FIPS is just the product of a particularly conservative (backwards-looking, path-dependent) and market-unaccountable standards process. It's like what would happen if JPMC had so much market power that they could make their own cryptographic standard; it would, I am saying, suck ass, without anyone meaning for it to.
LtWorf
> If you can get a government contract in the first place you are already administratively competent enough to use FIPS.
My personal experience disagrees.
3eb7988a1663
Does that mean it might be easier, regardless of language, to shell out to your cryptographic Go binary rather than deal with OpenSSL? I dislike a lot of Go, but they have been pretty good about backwards compatibility.
SAI_Peregrinus
The "Uncompromising Security" section[1] is particularly interesting to me. FIPS-140 compliance usually leads to reduced security, but it looks like the Go team found ways around the main janky bits. It's nice that there's now a FIPS-140 module for FedRAMP that doesn't require avoiding VMs to stay secure, for example.
hamburglar
This is huge. I’ve spent years jumping through hoops to get Go projects signed off for FIPS-140 and I always worried that something was going to go wrong and we’d have a compliance nightmare on our hands. They just made it super easy.
dadrian
If DOGE had done nothing other than get rid of FIPS validation, the GDP unlock alone would have solved the debt problem.
dlock17
Companies don't need any additional reasons to skimp out on security.
The money could probably be more wisely spent if not following FIPS but without FIPS the average company wouldn't direct that money towards security at all.
tptacek
No. FIPS has literally nothing to do with security.
dlock17
I may be thinking more about FedRAMP in general rather than just FIPS140-3, but mandating things like keeping user passwords out of logs is a security improvement.
And the average company needs to be dragged kicking and screaming to care about security at all.
thayne
I wouldn't say nothing. It is intended to ensure some level of security. And in some ways it can lead to decreased security if you comply with it (for example, if a vulnerability is found in your crypto library, you have to wait for the fix to be "validated" before you can patch it).
But yeah, complying with FIPS doesn't necessarily mean you are secure, and it is definitely possible to be secure without being FIPS compliant.
api
Doesn’t it at least keep snake oil crypto out of government? If it were removed it should be replaced by something. No standard would lead to a lot of crap being deployed.
aranw
I’m curious to understand what implications this will have on Go and where it is used? How does this differ to other languages as well? I don’t fully understand what it will mean for Go and its community
haiku2077
It means companies with US government contracts writing Go code can use the standard library crypto package in native Go instead if having to enable CGO and using a crypto library written in C. CGO is kind of a pain in the ass to develop with compared to fully native Go code, especially when cross-compiling (and cross compilation is very common now that ARM is common on both laptops and servers).
This also now makes Go a very convenient language to write US Gov software in.
If you have never heard of FIPS before ignore this entirely and continue to live in happiness.
tptacek
None; it's an optional package you use when your users require FIPS 140.
dangoodmanUT
I think this was in MS Go before, right?
FiloSottile
No, the Go 1.24 native module effort that they talk about in https://devblogs.microsoft.com/go/go-1-24-fips-update/ is this effort, which Microsoft was not involved in. We simply decided to delay the official announcement until the module reached the In Process list.
The system libraries approach used by Microsoft Go is cgo based IIUC, and I think derived from Go+BoringCrypto. I understand they are working on migrating their bindings to fit better downstream of the new native mode.
firesteelrain
Does the use of the library in your application still require the application itself to be FIPS validated? This just makes it a little easier to go through full, validated NIST compliance, right?.
FiloSottile
[ Big I am a cryptographer, not your cryptographer disclaimer ]
It depends, but if you are targeting Security Level 1 (which is what most folks think about when they think about FIPS 140) you generally don't need your entire application to be validated, only the cryptographic module.
So (again, depending on your requirements and on the Operating Environment you deploy to and on what algorithms you use and how) setting GOFIPS140 might actually be all you need to do.
firesteelrain
Thank you. I will remember this the next time this comes up at work
null
midocon
This is a test
It's interesting and kind of neat in an inside-baseball way that the standard Go cryptographic library (already unusual in the major languages for being a soup-to-nuts implementation rather than wrappers around an OpenSSL) is almost fully NIST-validated; in particular, it means vendors who want to sell into FedGov can confidently build with the Go standard library.
Having said all this: nobody should be using crypto/fips140 unless they know specifically why they're doing that. Even in its 140-3 incarnation, FIPS 140 is mostly a genuflection to FedGov idiosyncrasies.