How is this different to Red Hat's process of using OpenSSL instead of Go's crypto libraries? That's how they've been doing it for quite a while - https://developers.redhat.com/blog/2019/06/24/go-and-fips-14...
Microsoft Go 1.24 FIPS changes
51–60 of 70 posts
Re: Microsoft Go 1.24 FIPS changes
#52The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…
Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.
Either projects start shipping FIPS enabled or companies have to rebuild and repackage projects with FIPS enabled.
With OpenSSL installed system wide you can turn on a flag and the library will force it into FIPS mode internally, with Go unless you build your binaries to link against OpenSSL like this Microsoft Go release seems to be doing you don't get that instant on system wide.
Re: Microsoft Go 1.24 FIPS changes
#53Earlier quoted context omitted.
Whether FIPS 140 is actually a good target for cryptography is another question Answer to that question: it is not. It's a thing you only do when you are forced to by some requisitions process.
Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?
Most projects that compile against OpenSSL can be forced into FIPS mode by setting a flag that the OpenSSL library uses to force enable FIPS mode when it is loaded.
Golang projects however don't compile against OpenSSL instead using the internal cryptography. In many cases rebuilding and repackaging a Golang based tool is a no-no since now you are accepting ownership of it in an audit, when instead you want to point to an upstream vendor, or source code is not available.
So in many cases in production while the system itself is in FIPS mode (Linux kernel), and applications using system crypto libraries (OpenSSL primarily) are in FIPS mode, Go binaries are not in FIPS mode and may end up using algorithms that are explicitly disallowed by the FIPS standards.
Re: Microsoft Go 1.24 FIPS changes
#54IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.
I'm not involved in the OpenSSL/CNG-based Microsoft Go fork. I've managed and implemented—along with Daniel McCarney, Roland Shoemaker, and Russ Cox—the native upstream Go validation mentioned in the intro, which is shipping in Go 1.24 and will be certified on Linux (amd64, arm64, ppc64le, s390x), Windows (amd64, arm64), macOS (arm64), and FreeBSD (amd64). The Linux operating environments were funded by various stake…
Is there going to be a way to turn FIPS on as a requirement without having compiled the binary against the FIPS-140 module?
Even now it has been a lot of trouble trying to get vendors to provide us a way to rebuild/repackage their Golang binaries using the FIPS-140 support from RHEL, and if it is still the case that they need to build one-offs, teams will still need to rebuild/repackage a lot of Golang tools just to be FIPS compliant because it's not as simple as setting a flag like it is for OpenSSL.
Re: Microsoft Go 1.24 FIPS changes
#55I've been using Go for about 10 years and this the first time I've heard of "Microsoft Go"
Author here. Microsoft is a soft Go fork mostly for internal Microsoft needs, but some projects outside of Microsoft use it as well due to it's good FIPS 140 story. I expect some of these users to switch back to Google's Go now that it will also ship with a FIPS-140 crypto stack.
out of curiosity: what problems do you solve with this fork at Microsoft and why not C# ?
Re: Microsoft Go 1.24 FIPS changes
#56I've been using Go for about 10 years and this the first time I've heard of "Microsoft Go"
Also not to be confused with Microsoft Surface Go: https://en.m.wikipedia.org/wiki/Surface_Go
Re: Microsoft Go 1.24 FIPS changes
#57TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.
Is the fragmentation due to FIPS 140-2 alone? Or are there other differences?
Why couldn't the crypto changes be rolled into mainstream Go?
Re: Microsoft Go 1.24 FIPS changes
#58IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.
I'm not involved in the OpenSSL/CNG-based Microsoft Go fork. I've managed and implemented—along with Daniel McCarney, Roland Shoemaker, and Russ Cox—the native upstream Go validation mentioned in the intro, which is shipping in Go 1.24 and will be certified on Linux (amd64, arm64, ppc64le, s390x), Windows (amd64, arm64), macOS (arm64), and FreeBSD (amd64). The Linux operating environments were funded by various stake…
When you say "validated module" do you mean Golang module?
Re: Microsoft Go 1.24 FIPS changes
#59TIL there are multiple flavors of Golang including “Microsoft Go”. Wow - I’ve been away from Golang too long. I was initially shocked and then kind of sad that Go is not so simple anymore.
I have been following Go for a while and didn't know that either.
Re: Microsoft Go 1.24 FIPS changes
#60The upstream Go 1.24 changes and macOS support using system libraries in Microsoft's Go distribution are really significant for the large ecosystem of startups trying to sell to institutions requiring FIPS 140 certified cryptography. For a variety of reasons - including "CGo is not Go" ( https://dave.cheney.net/2016/01/18/cgo-is-not-go ) - using boringcrypto and requiring CGO_ENABLED=1 could be a blocker. Not using s…
I had to deal with FIPS compliance while at MS for FedRAMP compliance. It's not a technical problem, but a compliance problem
If you don't need FIPS for compliance you're better off investing in much more useful things for security (more effective linting, test coverage, keeping dependencies up to date, etc)