Go 1.24 introduced the fips140=only GODEBUG setting, which strictly enforces that only FIPS 140-3 compliant cryptography is used, either panicking in or returning an error from non-compliant functions.

For the vast majority of use cases, this is likely to be overly strict, as programs will likely need to use non-compliant functions in code paths that do not require FIPS 140-3 compliant cryptography (for instance, when using non-compliant hashes for non-cryptographic purposes).

More complex programs would likely benefit from a more selective policy enforcement framework that either allows marking non-compliant function calls as acceptable or allows selectively enforcing compliance requirements (or both).

For instance, one possible approach would be to add a function to crypto/fips140 which takes an options struct and a function. Within this function, enforcement decisions would be modified by the specified options (e.g., “allow calls to x, y, and z non-compliant functions” or “strictly enforce FIPS 140-3 compliance”).

This issue doesn’t propose any explicit changes; it is mainly intended, for now, to collect ideas from the community. We’d especially like to hear from users who have experience developing applications that would benefit from this type of selective enforcement and from those who have experience using similar frameworks in other languages.

Comment From: gabyhelp

Related Issues

Related Documentation

(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)

Comment From: qmuntal

More than a runtime enforcement I would find more useful to have a static analysis tool that reports which non-FIPS compliant algorithms are used. It could be a special govulncheck mode, for example.

But that might be food for another proposal.

Comment From: CanobbioE

Just wanted to share my experience migrating to GODEBUG=fips140=only at the company I work for.

We encountered only two issues during the process. Sharing them here in case it helps others.

Issue 1
For unit testing, we were using a fakekms client with a aesgcm fake key.
The aesgcm implementation of NewAEAD internally calls NewGCM, which, under fips140=only, returns an error suggesting the use of NewGCMWithRandomNonce.

Solution 1
We resolved this by generating a new fake key with aesgcmsiv, which is allowed in FIPS mode.

Issue 2
Redis script caching uses SHA-1 to generate the cache key.
Due to legacy code, we were generating the SHA-1 hash ourselves, which resulted in the error: use of SHA-1 is not allowed.

Solution 2
We updated the code to delegate SHA-1 generation to Redis by calling SCRIPT LOAD, avoiding the explicit use of SHA-1 in Go.

In conclusion, the migration to the strictest configuration (fips140=only) was quick and relatively straightforward, kudos!