crypto: obtain a FIPS 140-3 validation

[FiloSottile]

Background

FIPS 140 is a set of U.S. Government requirements for cryptographic modules. A number of companies must comply with them, for example as part of a broader FedRAMP compliance posture. (If that's not you, you can ignore this. Run!)

Current solutions for Go program compliance are based on cgo, and replace some of the crypto packages internals with FIPS 140 validated non-memory safe modules. These solutions come with varying levels of support (for example the Go+BoringCrypto solution is not officially supported and its compliance profile is left to the user to assess), introduce memory unsafe code, sometimes delay Go version updates, can have performance issues, affect the developer experience (for example inhibiting cross-compilation), and their compliance profile is debatable. As Go is adopted more and more in regulated settings, this is going to affect Go's adoption and developer experience.

The Go FIPS module

We plan to pursue a FIPS 140-3 validation for the NIST approved components of the Go standard library. The resulting module will be distributed as part of the standard library under the same license as the rest of the Go project, and will be transparently used by the relevant standard library packages with no API changes (wherever possible).

Users will be able to select the module to use at build time, for example choosing between a certified version, a version in the In Process list, or the latest unvalidated update. Moreover, we'll provide some mechanism for applications to disable the use of non-approved algorithms and modes at runtime.

Further planning details

The goal is shipping the module as part of Go 1.24, assuming our validation strategy is successful. This is the first time as far as we know that a Go library (or any non-Java memory safe library) is validated.

Unless completely unavoidable, we'll not compromise on security to achieve compliance. For example, we will inject random bytes from the kernel as additional input per SP 800-90Ar1, Section 8.7.2, every time we use the mandatory DRBG, and we'll use a dedicated DRBG for ECDSA to implement a "hedged" nonce generation equivalent to what crypto/ecdsa does now (safer than both NIST options of fully random and deterministic). Also, we'll try to add minimal complexity to regular non-FIPS builds.

NIST approved packages will be prioritized in being moved to the standard library (#65269) to get validated along the rest.

We'll test at least on Linux on amd64 and arm64. Further details will be available later in the process. (If you have specific requirements, please inquire about becoming a sponsor, see below.)

We aim to deprecate and hopefully remove Go+BoringCrypto once the module lands.

After the initial validation, we plan to revalidate at least every year, and every time a CVE affects the module with no standard library-side mitigation.

All work will be done on Gerrit, tracked in the issue tracker, and the testing harnesses will be committed in the tree.

This is an umbrella issue to track related issues and CLs, and to provide updates to the community. We'll file separate proposals for the exact build-time settings, for the FIPS-only policy mechanism, for any new APIs, and for any behavior changes.

We have started working with a CMVP testing laboratory, and contracted @cpu to help. This is an industry-sponsored effort that I (@FiloSottile) am leading as an independent maintainer, not a Google or Go team project (although it is coordinated with the Go team and @golang/security). We're funded by a few major stakeholders, and we're available to accept sponsorships and offer commercial support (reach out to [email protected] if interested).

[gabyhelp]

Related Issues and Documentation

• crypto: Understanding lack of FIPS validation #45188 (closed)
• crypto: FIPS Mode and Validation of Crypto Provider? #11658 (closed)
• crypto: FIPS 140-2 Certification? #21734 (closed)

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

[DejeroDaniel]

I was just about to ask a question regarding Ed25519 usage in the other ticket when this was posted. Exciting news! Is Ed25519 support planned to be certified in this new native implementation?

[FiloSottile]

Is Ed25519 support planned to be certified in this new native implementation?

Yes, we'll post a full list of algorithms once we are close to finalizing it, but it approximates to "everything that's NIST approved and not frozen, deprecated, or legacy-use".

[mateusz834]

Users will be able to select the module to use at build time, for example choosing between a certified version, a version in the In Process list, or the latest unvalidated update.

How this is going to be achieved? Build tags? The default is going to be non-FIPS validated?

[FiloSottile]

How this is going to be achieved? Build tags?

Probably something more explicit, such as a go build flag. I suspect build tags won't be flexible enough, but I might be wrong! We'll bring up a dedicated proposal to discuss that.

The default is going to be non-FIPS validated?

Yes.

[gopherbot]

Change https://go.dev/cl/614495 mentions this issue: crypto/sha256,crypto/sha512: make assembly structure consistent

[gopherbot]

Change https://go.dev/cl/614656 mentions this issue: crypto/sha256,crypto/sha512: test fallback implementations

[gopherbot]

Change https://go.dev/cl/615235 mentions this issue: crypto/sha256,crypto/sha512: move implementation to crypto/internal/fips

[gopherbot]

Change https://go.dev/cl/615816 mentions this issue: crypto/internal: add FIPS module test wrapper

[manistal]

Out of curiosity, how will Go natively handle the key zeroization requirements of FIPS?

[gopherbot]

Change https://go.dev/cl/616636 mentions this issue: crypto/hmac: move implementation to crypto/internal/fips

[gopherbot]

Change https://go.dev/cl/616717 mentions this issue: crypto/internal/fips/sha3: import x/crypto/sha3

[gopherbot]

Change https://go.dev/cl/616716 mentions this issue: crypto/internal/fips/subtle: provide XORBytes

[gopherbot]

Change https://go.dev/cl/616715 mentions this issue: internal/cpu: add ARM64.HasSHA3

[gopherbot]

Change https://go.dev/cl/617357 mentions this issue: crypto/internal/fips/sha3: restructure as an internal package

[gopherbot]

Change https://go.dev/cl/617359 mentions this issue: crypto/internal/fips/sha3: reduce s390x divergence

[gopherbot]

Change https://go.dev/cl/617535 mentions this issue: crypto/internal/fips/sha3: test alternative s390x implementation

[gopherbot]

Change https://go.dev/cl/619477 mentions this issue: crypto/internal/fips: import x/crypto/pbkdf2

[gopherbot]

Change https://go.dev/cl/619236 mentions this issue: crypto/internal/fips/pbkdf2: stub service indicator

[gopherbot]

Change https://go.dev/cl/620795 mentions this issue: crypto/internal/fips: add service indicator mechanism

[gopherbot]

Change https://go.dev/cl/621075 mentions this issue: crypto/internal/fips: add self-test mechanism

[gopherbot]

Change https://go.dev/cl/621275 mentions this issue: crypto/internal/fips/hkdf: new package

[gopherbot]

Change https://go.dev/cl/622275 mentions this issue: crypto/internal/alias: move to crypto/internal/fips/alias

[gopherbot]

Change https://go.dev/cl/622276 mentions this issue: crypto/subtle: document and test XORBytes overlap rules

[gopherbot]

Change https://go.dev/cl/623195 mentions this issue: crypto/internal/fips/pbkdf2: add CAST testing

[gopherbot]

Change https://go.dev/cl/624395 mentions this issue: crypto/aes: move to crypto/internal/fips/aes

[aclements]

@FiloSottile can you post a list of the proposals that this depends on? Also, my sense is that some of the proposals are required, while others are more "nice to have". If that's right, please indicate that in the list. Thanks!

[FiloSottile]

@aclements the following proposals are necessary to expose the functionality of the module to applications. They are not strictly speaking necessary to validate the module, but a validated module with algorithms that can't be used by applications is not very useful :)

• [ ] https://github.com/golang/go/issues/70123
• [ ] https://github.com/golang/go/issues/70200 (edited to add)
• [ ] https://github.com/golang/go/issues/70122
• [ ] https://github.com/golang/go/issues/69982
• [ ] https://github.com/golang/go/issues/69488
• [ ] https://github.com/golang/go/issues/61477
• [ ] https://github.com/golang/go/issues/69981

The following is nice-to-have but still relevant, since we are not validating these modes.

• [ ] https://github.com/golang/go/issues/69445

There there's a few other crypto proposals in flight, of which the ones to wire ML-KEM into crypto/tls are somewhat related and would be important to land in Go 1.24.

• https://github.com/golang/go/issues/69985
• https://github.com/golang/go/issues/69393
• https://github.com/golang/go/issues/67516

Finally there are a couple hash proposals that are related to https://github.com/golang/go/issues/69982 above, but that are not really blocking anything.

• https://github.com/golang/go/issues/69518
• #69521

[gopherbot]

Change https://go.dev/cl/624736 mentions this issue: crypto/internal/fips/gcm: move GCM from .../aes and crypto/cipher

[gopherbot]

Change https://go.dev/cl/624975 mentions this issue: crypto/rand: replace crypto/aes with internal/chacha8rand for plan9