fips140=only bypass

We have been collecting feedback about the GODEBUG=fips140=only enforcement mode, and for Go 1.26+ we are proposing a limited bypass mechanism.

// WithoutEnforcement disables strict FIPS 140-3 enforcement while executing f.
// Calling WithoutEnforcement without strict enforcement enabled
// (GODEBUG=fips140=only is not set or already inside of a call to
// WithoutEnforcement) is a no-op.
//
// WithoutEnforcement does not affect any goroutines started within it.
func WithoutEnforcement(f func())

This will be applied directly in the standard-library for e.g. hybrids of Approved and non-Approved key exchanges, and will be usable from libraries and applications to allow non-security uses of e.g. SHA-1.

If you have any comments, please share them with us here or on the issue!

proposal: crypto/fips140: selective policy enforcement framework · Issue #74630 · golang/go · GitHub

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

Entropy Source Validation Timeline

As planned, the FIPS 140-3 Go Cryptographic Module v2.0.0 will have a built-in entropy source, as virtually required for all modules submitted after December 31st, 2025 (when the "passive entropy" exception is retired).

Unfortunately, the lab informed us that the NIST ESV queue, once quick, now takes up to three months. Moreover, ESV certificate issuance blocks CMVP module submission, so if we want to hit our goal of submitting v2.0.0 before the Go 1.26 release in early February we need to submit the ESV early next month.

Entropy sources must be tested on the same Operating Environments as the CMVP module, so we will need to finalize the list of tested (not Vendor Affirmed) OEs in about two weeks.

If your platforms are included as tested OEs in the Geomys certificate, we apologize for the short notice. We realize some procurement processes are still ongoing, so we plan to include the platforms of all prospective clients with tested OEs in the ESV certificate at our own risk, to avoid submission delays. We will reach out directly in the coming days.

The good news is that we are structuring the entropy source to be independent, so hopefully we'll not need a ESV submission every year.

Imported key PCTs and amended v1.0.0

There used to be a sentence in Implementation Guidance 10.3.A that required Pairwise Consistency Tests (checking that the public key matches the private key) on key import, as well as generation. Besides being a performance drag, this meant we could not trigger a fatal error on PCT failure, since applications could provide mismatched keys.

This was confusing for other implementers, as well.

On September 2nd, NIST removed the requirement.

This is, generally, good news. It does mean however that our previous strategy of non-fatal errors is less defensible. We agreed with the lab to amend the v1.0.0 In Process module submission to remove key import PCTs and make key generation PCTs fatal.

This will involve a lot of backporting and some re-testing, but from your point of view it should be completely transparent: a minor release of Go 1.24 and Go 1.25 will include the new v1.0.0 module zip file. We will provide the amended Security Policy draft as soon as it's available.