Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Microsoft Go 1.24 FIPS changes

devblogs.microsoft.com

Post reply on HN
Print view View original

41–50 of 70 posts

Re: Microsoft Go 1.24 FIPS changes

#41

Post by lantastic »

prerok wrote: post #38
lantastic wrote: post #33

Earlier quoted context omitted.

Does this mean FIPS-enabled software never runs as such in production (or at all) in environments where it is supposedly mandated?

I don't understand the question. We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure. It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: no…

FIPS and "be secure" aren't necessarily a full overlap: there's plenty of ways to be secure that isn't even allowed in FIPS, so you need to actively disable that set if you run FIPS mode (depending on libraries used, this may e.g. disqualify hardware intrinsics because it was not covered by CMVP, creating potentially material performance consequences).

If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.

Re: Microsoft Go 1.24 FIPS changes

#43

Post by tetraodonpuffer »

qmuntal wrote: post #24
lordofgibbons wrote: post #11

I'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.

Any plans to use it for the managed azure istio so that can be used in FEDRAMP environments?

Re: Microsoft Go 1.24 FIPS changes

#44

Post by dolmen »

BoppreH wrote: post #39
FiloSottile wrote: post #29

Earlier quoted context omitted.

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…

I just wanted to say that we've adopted many of your projects at $DAYJOB, and it has been one of the best technical decisions we've made. So far I've used the Go crypto package, age , and more recently xwing. It all works flawlessly, and at every turn we have happy surprises (smooth cross-compilation, the Age plugin framework, typage, fast xwing revisions, your blog posts). If we ever meet in person, I own you a beer…

I think that Filippo deserves a bit more than a beer. He has business setup for true sponsorship.

https://words.filippo.io/full-time-maintainer/

Re: Microsoft Go 1.24 FIPS changes

#45

Post by dstroot »

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

Re: Microsoft Go 1.24 FIPS changes

#46

Post by raggi »

FiloSottile wrote: post #29
tptacek wrote: post #7

IIRC, 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…

Do you anticipate that:

> When GODEBUG=fips140=only is used, in addition to the above, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Note that this mode is a best effort and can’t guarantee compliance with all FIPS 140-3 requirements.

Will need to be more complete/certain in order to pass certification? My gut says it would based on the requirements, but I don't know how the auditors would respond in practice.

Re: Microsoft Go 1.24 FIPS changes

#47

Post by AaronFriel »

dagss wrote: post #40
AaronFriel wrote: post #16

Earlier quoted context omitted.

The comment is accurate that if you don't need this, you can ignore it. It's likely not an avenue for backdoors. I wouldn't say it's security theater but it just isn't meaningful to most. As for why not a library? Go has a pretty big "batteries included" implementation for networking. For customers demanding FIPS compliance it isn't enough to say, write all of your own application code to use a package that does FIPS…

Wouldn't declaring the "replace" directive in go.mod once take effect for all the dependencies?

Oh that's an interesting question, I've never tried to build a binary with "replace"-ing one of the builtin packages.

Maybe that works? But many of the standard library packages use linker shenanigans, if I recall, like //go:linkname pragmas. Maybe that's an issue, maybe not?

It would be interesting if the fork was unnecessary and it was possible to implement FIPS via package replacements! That would be a lot simpler.

Re: Microsoft Go 1.24 FIPS changes

#48

Post by AaronFriel »

tptacek wrote: post #25
AaronFriel wrote: post #13

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

I had a hunch you'd reply and say as much!

It's just unfortunate for the many orgs delivering software that eventually customers start demanding this and it was really painful in Go.

Re: Microsoft Go 1.24 FIPS changes

#49

Post by prerok »

lantastic wrote: post #41
prerok wrote: post #38

Earlier quoted context omitted.

I don't understand the question. We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure. It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: no…

FIPS and "be secure" aren't necessarily a full overlap: there's plenty of ways to be secure that isn't even allowed in FIPS, so you need to actively disable that set if you run FIPS mode (depending on libraries used, this may e.g. disqualify hardware intrinsics because it was not covered by CMVP, creating potentially material performance consequences). If you're already compliant (implying you are using FIPS complian…

Well, I agree that if you are using alternate means to achieve the same effect (or better!) and that's not recognized by the FIPS compliance then that can be painful.

My experience lies mostly in C and embedded applications, where the physical security was also in question and that is where the most of the effort to certify went. Software was relatively easy by using the right versions. So, maybe not just a certification, but non-fretting one.

Re: Microsoft Go 1.24 FIPS changes

#50

Post by cpuguy83 »

nick__m wrote: post #5
infogulch wrote: post #4

"What the heck is Microsoft Go ?" > This repository produces a modified version of Go that can be used to build FIPS 140-2 compliant applications. Our goal is to share this implementation with others in the Go community who have the same requirement, and to merge this capability into upstream Go as soon as possible. It is also the default 'golang' package on Azure Linux 3.0. Microsoft Go fork: https://github.com/micr…

Is Azure Linux 3.0 a rebranding of CBL-mariner

Sort of... AzureLinux is a rebranding from CBL-Mariner.

But 3.0 is an actual new version of the distro with newer packages (like going from Ubuntu 22.04 to 24.04, as an example).

Post reply on HN