IIRC, the FIPS-compliant Go crypto project was a Filippo Valsorda joint. I hate it, but I'm glad someone sane managed it.
> "was a Filippo Valsorda joint"
I like the reference.
Microsoft Go 1.24 FIPS changes
21–30 of 70 posts
Re: Microsoft Go 1.24 FIPS changes
#22The 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…
Author here. The macOS support currently uses cgo, but we are trying to make it cgo-less in Go 1.25, just as already happens on Windows. The goal is to allow pain-free cross-compilations from Linux to macOS.
Re: Microsoft Go 1.24 FIPS changes
#23Microsoft Go? I've used Go on windows for years now and this is the first I've heard of this fork. So it only exists because microsoft wants to have a crypto package that complies with an arbitrary regulation? Is there a reason that a better package requires a fork of the entire runtime rather than just, say, a normal Go package? It sounds like it requires cgo to call into third-party libraries, but that's already a…
"Is there a reason that a better package requires a fork of the entire runtime rather than just, say, a normal Go package?"
I think at the time that would have been the only way to make it so any in-the-wild 3rd party code you want to use would use the FIPS-compliant libraries anytime someone imported "crypto/whatever" from the standard library.
I haven't tested the workspaces functionality [1] to see if it allows you to override standard library functionality, but in principle something either very like that, or slightly tweaked, would be enough that you could just use standard Go with a particular text file dropped into place and some libraries to override the standard library now.
But yeah, if you didn't even know this fork existed, you're not in the target audience. tptacek or someone else who really knows their stuff can Cunningham's Law me if I'm wrong, but my impression is that FIPS has a track record of rigidly demanding very medium levels of security, possibly including some rigidly poor security choices, and if you don't have a need to be in compliance, you can and should do much better by using newer and better options than what it mandates.
Re: Microsoft Go 1.24 FIPS changes
#24I'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.
Re: Microsoft Go 1.24 FIPS changes
#25The 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.
Re: Microsoft Go 1.24 FIPS changes
#26I worked on a project about 4-5 years ago that required operating in a FIPS 140-2 environment and this was a huge problem, happy to see there's multiple different investments into doing this right. Same with OpenSSL offering an easy-to-snag FIPS-certified implementation. We had to buy what felt like bootleg Canonical OpenSSL binaries, and Go looked like building some speculative forks that clearly had not been design…
> We had to buy what felt like bootleg Canonical OpenSSL binaries Isn't this the entire FIPS scam? You have to do whatever your auditor says, even if it's ridiculous, and they are getting paid under the table by vendors.
Why under the table? Seems like someone like Canonical could just outright do the auditing itself.
Re: Microsoft Go 1.24 FIPS changes
#27This is interesting, but in this moment it is impossible to take any aspect of the FIPS program seriously. To get FedRAMP contracts you must meet FIPS 140-2 or -3! Or, you can just change your 4chan handle to "BigBalls". That's also acceptable.
There's a few issues here. The dash version, 140-2 or 140-3 is the major version of the standard. You can only certify against -3 right now. Within the standard there are four level, 1 - 4 with 1 being the lowest and 4 being the highest. So a full cert descriptor would be something like "FIPS 140-3 Level 2".
In order to get that you need to hire a certification lab to verify what you did and from there the government processes it. That processing, reading paperwork and asking a couple questions, takes over a year at this point which is where a significant issue is. This is also a prereq to FedRAMP, which is a whole new set of paperwork and checkbox compliance that adds debatable quality.
I can understand the need to prevent unsafe solutions, but the current process is so slow and expensive that it makes selling useful things to customers that require FIPS a huge PITA.
Re: Microsoft Go 1.24 FIPS changes
#28The 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.
> It's a thing you only do when you are forced to by some requisitions process.
We're going through a FIPS compliance project right now and it's nothing more than a miserably expensive set of check boxes. Contractor they hired is incompetent so that isn't helping either.
Re: Microsoft Go 1.24 FIPS changes
#29IIRC, 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 stakeholders, the rest were funded by Geomys for the benefit of the Go community.
There are some details now at https://go.dev/doc/security/fips140, but we're going to write a proper blog post once the module gets on the CMVP In Process list.
tl;dr is that it should soon take a single environment variable to transparently build against a FIPS 140-3 validated module which is just a slightly out of date version of the same Go standard library everyone else is using. (AFAIK this is the first non-JVM memory safe FIPS 140 module!)
Re: Microsoft Go 1.24 FIPS changes
#30"We evaluated changing Microsoft Go to use the new Go FIPS module rather than system libraries. However, we ultimately determined that this approach doesn’t align with Microsoft internal cryptography strategy and policies."
Any good modern conspiracy theories about Windows system libraries for cryptography?