The FIPS 140-3 Go Cryptographic Module

by FiloSottile • 1 year ago

196 71 1 year ago

aranw4• 1 year ago

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

tptacek10• 1 year ago

None; it's an optional package you use when your users require FIPS 140.

aranw4• 1 year ago

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

haiku20774• 1 year ago

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.

aranw4• 1 year ago

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

tptacek10• 1 year ago

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.

twoodfin• 1 year ago

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• 1 year ago

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.

FiloSottile8• 1 year ago

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• 1 year ago

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?

tptacek10• 1 year ago

crypto/, not crypto/fips140.

3eb7988a1663• 1 year ago

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.

tialaramex3• 1 year ago

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.

FiloSottile8• 1 year ago

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

hamburglar• 1 year ago

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.

aranw4• 1 year ago

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

caleblloyd• 1 year ago

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.

dangoodmanUT• 1 year ago

I think this was in MS Go before, right?

FiloSottile8• 1 year ago

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.

metaltyphoon• 1 year ago

and I think derived from Go+BoringCrypto

It's based on OpenSSL

dadrian2• 1 year ago

If DOGE had done nothing other than get rid of FIPS validation, the GDP unlock alone would have solved the debt problem.

dlock172• 1 year ago

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.

tptacek10• 1 year ago

No. FIPS has literally nothing to do with security.

dadrian2• 1 year ago

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.

firesteelrain2• 1 year ago

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?.

FiloSottile8• 1 year ago

[ 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.

firesteelrain2• 1 year ago

Thank you. I will remember this the next time this comes up at work

bradfitz• 1 year ago

Congrats, Filippo!

midocon2• 1 year ago

This is at est!

justincormack• 1 year ago

Yes its been a long journey since the early boringssl versions a decade ago.

midocon2• 1 year ago

This is a test

SAI_Peregrinus• 1 year ago

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

p_l• 1 year ago

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

jeffrallen• 1 year ago

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.

The FIPS 140-3 Go Cryptographic Module

Related Stories