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.
> 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.
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.
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.
> 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.
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.
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.
> already unusual in the major languages for being a soup-to-nuts implementation rather than wrappers around an OpenSSL
What does "Soup-to-nuts" require in this context? Should I expect that Go has for some reason re-implemented the x86-64 machine code to do ChaCha20 or do you still consider it a "Soup-to-nuts" implementation if they reuse the same machine code for this that you'd find in everybody else's implementation so long as they wrote their own wrapper code ?
Unlike say compression there's no real room in these core features to innovate. You can't pick different "nothing up my sleeve" numbers, you can't can't offer more parametrisation, anything like that would be an incompatibility - it's intentionally a standardized component.
Off the top of my head, there might be some old assembly by Andy Polyakov and by Vlad Krasnov that was contributed to both Go and OpenSSL. Even there, we’ve been working for years to port hand-written assembly to higher level generators, and there’s not as much as you’d think. Everything else is original.
Besides integrating properly with Go applications, this lets us optimize for readability and correctness, with IMHO excellent empirical results.
Nah, I'm pretty sure there's exactly as much (assembly) as I'd think because I spent some time prodding it before writing the question in the first place.
You likely understand what it does much better than me, but I'm under no illusion that there's a lot of this code, nor indeed that it's problematic to use this code.
However I'm not at all convinced that porting "hand written assembler to higher level generators" is a good strategy for this specific code. It serves to launder the creativity, so that maybe some day one lawyer can convince another lawyer that A and B are distinct works despite every actual process along the convoluted path from A to B being mechanical... but it doesn't seem like it gets us closer to having a sustainable alternative.
And that's what I actually am interested in here, I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm. So that actually gets to the same Readability and Correctness goals you state, but rather than hoping to get away with writing Go (or any GP language) we accept that it's never going to make sense for a General Purpose language to prioritise this. IMO We're more or less guaranteeing one day we accidentally ship an Oracle.
Well, ML-KEM has zero assembly and was written entirely from scratch, for example, so it must be more than you'd think if you think we "reuse the same machine code for this that you'd find in everybody else's implementation." In fact, almost everyone else's was found to be producing a variable-time DIV instruction, while ours was unaffected.
Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.
The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.
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.
Part of the issue was that there are multiple FIPS-140 versions, and the Go support is for FIPS-140-3, which is honestly quite updated and less annoying. To the point I actually recommended running our entire environment (for a pretty big cloud company) FIPS-140-3 mode (maybe not fully compliant for everything, but essentially going with "FIPS-140-3 as default but outside of FedRAMP we're not going to consider it a breaking change if it doesn't pass") because the only thing we might really be missing was ChaCha ciphers which mainly would impact clients running from mobile devices or otherwise lacking in power/AES accelleration... and we had no such clients
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.
Yes. Any language that dynamically links to the OS crypto library (like OpenSSL) is more attractive because your Government customer can install your software on their OS with their FIPS compliant OS crypto library.
This moves the needle for Go but you still need to cut a FIPS version of your software since this crypto is still statically linked. I like this option quite a bit if the Government customers get on board with it.
There are some Go forks maintained by Microsoft and RedHat I believe that do dynamic linking for crypto which requires CGO.
To clarify, you could previously link to an external SSL library (typically something like BoringSSL) and people did do that. However, it makes cross compilation a pain compared to native Go.
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.
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.
FIPS-140 doesn't even speak to most cryptographic vulnerabilities; it could prevent you from using, like, the PKZip cipher rather than AES, but not (really) from having code that could be induced into reusing a GCM nonce.
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.
> but mandating things like keeping user passwords out of logs is a security improvement.
That has nothing to do with FIPS 140.
FIPS 140 is just requirements for "cryptographic modules".
It specifies which algorithms are allowed and requires that you use modules that have been "validated" by going through an expensive and slow auditing process.
While I don't think it is completely useless to have those requirements, it has some problems, such as:
- it takes a very long time for anything to get validated. For example, Ubuntu 22.04 only recently got its crypto packages validated after being "in process" for years.
- bug fixes have to go through the validation process too, so if a vulnerability is found, you can be left vulnerable for a while
- For many languages and runtimes, using FIPS certified modules is a royal pain. For example, for several versions of node, there was no good way to run it in a FIPS compatible way, because it required a newer version of openssl than the latest FIPS certified version. AWS lambdas, even in GovCloud don't include FIPS certified crypto, so you have to bundle it in your package and make sure to use your local library instead of the system library, which can be quite difficult depending on the language. Prior to this change in go, using FIPS in go required using cgo to link to a FIPS certified c library, and make sure you either did some fancy link magic to get any libraries you used to also use that, or don't use any libraries that use the standard crypto library.
- It doesn't include many algorithms that are widely used and generally considered secure including Ed25519, chacha20-poly1305, argon (along scrypt, bcrypt, etc.), etc. This can cause problems with compatibility with other systems.
Luckily, FedRAMP have updated their FIPS guidance just this year to allow using crypto modules that have been validated and then received security patches. They realized that security patching is important and you don't need to recertify every patch before using it anymore.
This is about exclusively using "validated" implementations of specific cryptographic constructions. You can avoid it simply by not encrypting stuff at all, which is an indication of how little it has to do with security.
This has relatively little to do with actual security. It is compliance and certification theater for the most part. In many cases you can avoid it entirely by outsourcing caring about it to the customer. This isn’t always a bad thing; sometimes they understand and can deliver on their requirements much better than you can.
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.
The way you get quality products is by requiring and validating quality, not by picking a lowest common denominator and then pinning it in place for a decade with paperwork and calcified standards bodies.
There's a difference between FIPS validation and FIPS-approved algorithms. We can say "you have to use the FIPS-approved algorithms", but skip the useless validation step.
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
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.
Yeah, honestly, this just rocketed Go to possible one of the best languages to write these services in. You can write a fully self-contained and compliant program using just the standard library, where a lot of other languages need to be linked to a commercial SSL library.
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.
Yes, it calls out to OpenSSL on Linux and to CNG on Windows. I think, but I am not certain, that at least the OpenSSL cgo bindings are derived from the Go+BoringCrypto ones (which makes sense, since the BoringSSL and OpenSSL APIs are still very similar).
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?.
[ 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.
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.
> 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.
> 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?
crypto/, not crypto/fips140.
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.
Not a nitpick! I was just wrong!
That's a nice solution when managing a platform. You can "upgrade" all your teams, and/or easily detect they have upgraded.
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?
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.
> 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.
It may be that just everyone else is even moreso incompetent.
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.
> If you can get a government contract in the first place you are already administratively competent enough to use FIPS.
My personal experience disagrees.
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.
> already unusual in the major languages for being a soup-to-nuts implementation rather than wrappers around an OpenSSL
What does "Soup-to-nuts" require in this context? Should I expect that Go has for some reason re-implemented the x86-64 machine code to do ChaCha20 or do you still consider it a "Soup-to-nuts" implementation if they reuse the same machine code for this that you'd find in everybody else's implementation so long as they wrote their own wrapper code ?
Unlike say compression there's no real room in these core features to innovate. You can't pick different "nothing up my sleeve" numbers, you can't can't offer more parametrisation, anything like that would be an incompatibility - it's intentionally a standardized component.
Off the top of my head, there might be some old assembly by Andy Polyakov and by Vlad Krasnov that was contributed to both Go and OpenSSL. Even there, we’ve been working for years to port hand-written assembly to higher level generators, and there’s not as much as you’d think. Everything else is original.
Besides integrating properly with Go applications, this lets us optimize for readability and correctness, with IMHO excellent empirical results.
https://words.filippo.io/a-literate-go-implementation-of-pol...
https://go.dev/blog/tob-crypto-audit
https://www.youtube.com/watch?v=lkEH3V3PkS0
> there’s not as much as you’d think
Nah, I'm pretty sure there's exactly as much (assembly) as I'd think because I spent some time prodding it before writing the question in the first place.
You likely understand what it does much better than me, but I'm under no illusion that there's a lot of this code, nor indeed that it's problematic to use this code.
However I'm not at all convinced that porting "hand written assembler to higher level generators" is a good strategy for this specific code. It serves to launder the creativity, so that maybe some day one lawyer can convince another lawyer that A and B are distinct works despite every actual process along the convoluted path from A to B being mechanical... but it doesn't seem like it gets us closer to having a sustainable alternative.
And that's what I actually am interested in here, I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm. So that actually gets to the same Readability and Correctness goals you state, but rather than hoping to get away with writing Go (or any GP language) we accept that it's never going to make sense for a General Purpose language to prioritise this. IMO We're more or less guaranteeing one day we accidentally ship an Oracle.
Well, ML-KEM has zero assembly and was written entirely from scratch, for example, so it must be more than you'd think if you think we "reuse the same machine code for this that you'd find in everybody else's implementation." In fact, almost everyone else's was found to be producing a variable-time DIV instruction, while ours was unaffected.
Porting the assembly to higher-level generators has nothing to do with lawyers (??), the goals are stated in https://go.dev/wiki/AssemblyPolicy.
The idea that one day we'll write All Of The Cryptography Code Once And For All In The Perfect Language and reuse that across languages comes up pretty regularly, and has never panned out.
> I think we want a Special Purpose language focused on emitting guaranteed constant time machine code for an algorithm.
https://github.com/jasmin-lang/jasmin
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.
[1] https://go.dev/blog/fips140#uncompromising-security
Part of the issue was that there are multiple FIPS-140 versions, and the Go support is for FIPS-140-3, which is honestly quite updated and less annoying. To the point I actually recommended running our entire environment (for a pretty big cloud company) FIPS-140-3 mode (maybe not fully compliant for everything, but essentially going with "FIPS-140-3 as default but outside of FedRAMP we're not going to consider it a breaking change if it doesn't pass") because the only thing we might really be missing was ChaCha ciphers which mainly would impact clients running from mobile devices or otherwise lacking in power/AES accelleration... and we had no such clients
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.
Did this make Go a less attractive option compared to other languages then? I’m interested in understanding how this will help Go and the community
Yes. Any language that dynamically links to the OS crypto library (like OpenSSL) is more attractive because your Government customer can install your software on their OS with their FIPS compliant OS crypto library.
This moves the needle for Go but you still need to cut a FIPS version of your software since this crypto is still statically linked. I like this option quite a bit if the Government customers get on board with it.
There are some Go forks maintained by Microsoft and RedHat I believe that do dynamic linking for crypto which requires CGO.
> This moves the needle for Go
To clarify, you could previously link to an external SSL library (typically something like BoringSSL) and people did do that. However, it makes cross compilation a pain compared to native Go.
If DOGE had done nothing other than get rid of FIPS validation, the GDP unlock alone would have solved the debt problem.
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.
No. FIPS has literally nothing to do with security.
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.
FIPS-140 doesn't even speak to most cryptographic vulnerabilities; it could prevent you from using, like, the PKZip cipher rather than AES, but not (really) from having code that could be induced into reusing a GCM nonce.
It is of no security value.
fedramp as of last year allows to use not fips validated version in order to patch security vulnerabilities
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.
> but mandating things like keeping user passwords out of logs is a security improvement.
That has nothing to do with FIPS 140.
FIPS 140 is just requirements for "cryptographic modules".
It specifies which algorithms are allowed and requires that you use modules that have been "validated" by going through an expensive and slow auditing process.
While I don't think it is completely useless to have those requirements, it has some problems, such as:
- it takes a very long time for anything to get validated. For example, Ubuntu 22.04 only recently got its crypto packages validated after being "in process" for years.
- bug fixes have to go through the validation process too, so if a vulnerability is found, you can be left vulnerable for a while
- For many languages and runtimes, using FIPS certified modules is a royal pain. For example, for several versions of node, there was no good way to run it in a FIPS compatible way, because it required a newer version of openssl than the latest FIPS certified version. AWS lambdas, even in GovCloud don't include FIPS certified crypto, so you have to bundle it in your package and make sure to use your local library instead of the system library, which can be quite difficult depending on the language. Prior to this change in go, using FIPS in go required using cgo to link to a FIPS certified c library, and make sure you either did some fancy link magic to get any libraries you used to also use that, or don't use any libraries that use the standard crypto library.
- It doesn't include many algorithms that are widely used and generally considered secure including Ed25519, chacha20-poly1305, argon (along scrypt, bcrypt, etc.), etc. This can cause problems with compatibility with other systems.
Luckily, FedRAMP have updated their FIPS guidance just this year to allow using crypto modules that have been validated and then received security patches. They realized that security patching is important and you don't need to recertify every patch before using it anymore.
https://www.fedramp.gov/rev5/fips/
FYI, Ed25519 is now included.
This is about exclusively using "validated" implementations of specific cryptographic constructions. You can avoid it simply by not encrypting stuff at all, which is an indication of how little it has to do with security.
> You can avoid it simply by not encrypting stuff at all, which is an indication of how little it has to do with security.
The consequences of encrypting wrongly quite possibly are worse than if you never encrypted at all.
Remember when HN was losing its collective mind over Dual_EC_DRBG? That was delivered to customers with a FIPS validated software stack.
Both of these things can be true at the same time:
- "Don't use unproven cryptography" is a reasonable policy.
- Policymaking can be subverted by bad actors.
Yes, but neither of those things have anything to do with FIPS 140-3.
FIPS validation address the compliance problem of needing validation. Beyond that, the benefits are ambiguous at best.
Good thing FIPS 140 does virtually nothing to prevent cryptographic vulnerabilities, then.
fedramp requires to encrypt a bunch of stuff
FedRAMP is more a cheatsheet for compliance people. Someone in a federal agency had an auditor validate that the required NIST controls were done.
The most useful thing about FIPS 140 is that it’s a great way of quickly identifying clueless security people.
This has relatively little to do with actual security. It is compliance and certification theater for the most part. In many cases you can avoid it entirely by outsourcing caring about it to the customer. This isn’t always a bad thing; sometimes they understand and can deliver on their requirements much better than you can.
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.
It’s way better at preventing usage of modern crypto than it is at blocking snake oil.
You seem to be assuming modern well designed crypto would win in government contracting with no standard.
I’m speaking from experience, not assuming.
The way you get quality products is by requiring and validating quality, not by picking a lowest common denominator and then pinning it in place for a decade with paperwork and calcified standards bodies.
A lot of FIPS-compatible crap is already deployed, and our most secure and trusted cryptography generally wasn't created under any standards regime.
There's a difference between FIPS validation and FIPS-approved algorithms. We can say "you have to use the FIPS-approved algorithms", but skip the useless validation step.
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
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.
> This also now makes Go a very convenient language to write US Gov software in.
This is something I wondered. Will we now see even more adoption of Go? Will Go be a more attractive option compared to language X/Yv
Yeah, honestly, this just rocketed Go to possible one of the best languages to write these services in. You can write a fully self-contained and compliant program using just the standard library, where a lot of other languages need to be linked to a commercial SSL library.
None; it's an optional package you use when your users require FIPS 140.
Ahh okay I didn’t realise it is just a package. I wondered if it was more than that and included stuff with the compiler or something
It's also a new compiler option to transparently replace calls to the crypto stdlib package with FIPS versions
Congrats, Filippo!
Yes its been a long journey since the early boringssl versions a decade ago.
This is at est!
I think this was in MS Go before, right?
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.
> and I think derived from Go+BoringCrypto
It's based on OpenSSL
Yes, it calls out to OpenSSL on Linux and to CNG on Windows. I think, but I am not certain, that at least the OpenSSL cgo bindings are derived from the Go+BoringCrypto ones (which makes sense, since the BoringSSL and OpenSSL APIs are still very similar).
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?.
[ 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.
Thank you. I will remember this the next time this comes up at work
> although it doesn’t necessarily improve security, FIPS 140 compliance is a requirement in certain regulated environments
LOL. At least they don't bury the lede.
This is a test