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'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.
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.
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?.
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
12 comments
[ 3.1 ms ] story [ 27.6 ms ] threadHaving 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.
[1] https://go.dev/blog/fips140#uncompromising-security
LOL. At least they don't bury the lede.