Hacker News Reader

Comment by AaronFriel | Hacker News Reader

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 system libraries meant that getting all of the software to agree on internal certificate chains was a chore. Go was in a pretty weird place.

Whether FIPS 140 is actually a good target for cryptography is another question. My understanding is that FIPS 140-1 and 140-2 cipher suites were considered by many experts to be outdated when those standards were approved, and that FIPS 140 still doesn't encompass post quantum crypto, and the algorithms chosen don't help mitigate misuse (e.g.: nonce reuse).

View on HN

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.

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

There are people here better positioned to answer than than I am. We've said "no" to customers who asked for this.

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: not FIPS-2 compliant.

So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.

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.

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.

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.

In some cases that's true, but not all. We have customers who require that our software supports running in a FIPS compliant mode, but never actually end up enabling it in production. But they wouldn't have bought our software without the option of enabling FIPS mode.

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.

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.

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.

For those building applications with FIPS 140 crypto the primary concern is compliance rather than security. There are many organizations (e.g., US federal) that have requirements for it.

The latest version is FIPS 140-3 and is more up to date.

Note, binaries made for FIPS 140 with OpenSSL dynamically linked do not run on Alpine. While I've not looked at the Microsoft go/openssl compiler, it's worth testing its output across distros/versions as different distros have different versions of glibc and openssl.

From https://news.ycombinator.com/item?id=28540916#28546930 :

  GOLANG_FIPS=1

From https://news.ycombinator.com/item?id=42265927 :

> Chrome switching to NIST-approved ML-KEM quantum encryption" (2024) https://www.bleepingcomputer.com/news/security/chrome-switch...

From https://news.ycombinator.com/item?id=41535866 :

>> Someday there will probably be a TLS1.4/2.0 with PQ, and also FIPS-140-4?

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)

Is the juice worth the squeeze for FIPS compliance? It sounds absolutely miserable

Uncle Sam wouldn’t even consider purchasing your product if it doesn’t tick some boxes. Now there are ways to get exceptions if you go high enough up the chain.

But it is a miserable exercise all in all. As you’re implementing it, you think “this is making things worse, less robust or secure, but oh well, that’s the only way it will sell”.

Depends on what you mean by juice. Is it worth the money? Yes

Reply on news.ycombinator.com