Golang crypto: obtain a FIPS 140-3 validation

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 filippo@golang.org if interested).

Comment From: gabyhelp

Related Issues and Documentation

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

Comment From: 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?

Comment From: 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".

Comment From: 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?

Comment From: 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.

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: manistal

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: 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!

Comment From: 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

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

Change https://go.dev/cl/624977 mentions this issue: crypto/internal/fips/drbg: implement CTR_DRBG

Comment From: gopherbot

Change https://go.dev/cl/624978 mentions this issue: crypto/internal/fips/drbg: implement FIPS-mode randomness generation

Comment From: gopherbot

Change https://go.dev/cl/624976 mentions this issue: crypto/rand: move OS interaction to crypto/internal/sysrand

Comment From: gopherbot

Change https://go.dev/cl/625435 mentions this issue: crypto/internal/fips/drbg: add CAST and service indicator

Comment From: gopherbot

Change https://go.dev/cl/625815 mentions this issue: crypto/internal/fips: avoid some non-relocatable global initializers

Comment From: gopherbot

Change https://go.dev/cl/626000 mentions this issue: all: enable FIPS verification code

Comment From: gopherbot

Change https://go.dev/cl/625997 mentions this issue: cmd/compile, cmd/link: add FIPS verification support

Comment From: gopherbot

Change https://go.dev/cl/625995 mentions this issue: cmd/internal/objabi, cmd/link: add FIPS symbol kinds

Comment From: gopherbot

Change https://go.dev/cl/625998 mentions this issue: crypto/internal/fips/check: add new package

Comment From: gopherbot

Change https://go.dev/cl/625999 mentions this issue: cmd/dist: add more pie tests, fips tests

Comment From: gopherbot

Change https://go.dev/cl/626175 mentions this issue: crypto/rsa: port PrivateKey.Validate to bigmod, add validations

Comment From: erahn

Apologies if this isn't the right place to ask - but do you know the full set of algorithms you plan to certify? One annoying thing that I've hit with certifying openssl / openssh is that the SSH KDF (along with IKE for IPsec, the CAK -> SAK stuff for MACsec) is part of FIPS 140 but was not part of the FIPS 140 module for openssl. This means that to certify a system using ssh I've had to add the SSH KDF into the openssl FIPS module.

I'm interested in understanding if you plan to add in algorithms like SSH KDF so that one could have, say, a pure Go implementation of SSH that would be covered under FIPS 140?

Comment From: FiloSottile

I'm interested in understanding if you plan to add in algorithms like SSH KDF so that one could have, say, a pure Go implementation of SSH that would be covered under FIPS 140?

Yes, we plan to include the SSH KDF in the validation, and to update x/crypto/ssh to use the module. (Once the validation is finalized, we'll also share a complete table of the validated algorithms.)

Comment From: gopherbot

Change https://go.dev/cl/626437 mentions this issue: crypto/internal/fips/aes: add CAST

Comment From: gopherbot

Change https://go.dev/cl/626675 mentions this issue: crypto/internal/fips/aes/gcm: add GCMForTLS12 and GCMForTLS13

Comment From: gopherbot

Change https://go.dev/cl/624916 mentions this issue: crypto/internal/fips/aes/gcm: add SealWithRandomNonce

Comment From: gopherbot

Change https://go.dev/cl/626835 mentions this issue: crypto/internal/fips/aes: add service indicators

Comment From: gopherbot

Change https://go.dev/cl/626837 mentions this issue: crypto/internal/fips/tls12: implement TLS 1.2 KDF

Comment From: gopherbot

Change https://go.dev/cl/626836 mentions this issue: crypto/internal/fips/tls13: implement TLS 1.3 KDF

Comment From: gopherbot

Change https://go.dev/cl/626875 mentions this issue: crypto/internal/fips/ssh: implement SSH KDF

Comment From: gopherbot

Change https://go.dev/cl/626877 mentions this issue: crypto/internal/fips/hkdf: correctly set the service indicator for short salts

Comment From: gopherbot

Change https://go.dev/cl/626879 mentions this issue: crypto/internal/mlkem768: move to crypto/internal/fips/mlkem

Comment From: gopherbot

Change https://go.dev/cl/626936 mentions this issue: crypto/internal/fips/mlkem: implement Pairwise Consistency Check

Comment From: gopherbot

Change https://go.dev/cl/627956 mentions this issue: crypto/internal/fips: wrap and lock internal dependencies

Comment From: gopherbot

Change https://go.dev/cl/627955 mentions this issue: crypto/internal/fips: move most tests to crypto/internal/fipstest

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

Change https://go.dev/cl/628679 mentions this issue: crypto/ecdsa: move s390x assembly to crypto/internal/fips/ecdsa

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

Change https://go.dev/cl/628678 mentions this issue: crypto/internal/fips/ecdsa: add CAST, PCT, DRBG, and FIPS 186-5 references

Comment From: gopherbot

Change https://go.dev/cl/628680 mentions this issue: crypto/internal/fips/ecdsa: add HMAC_DRBG

Comment From: gopherbot

Change https://go.dev/cl/628775 mentions this issue: crypto/internal/nistec: don't use go:embed

Comment From: gopherbot

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

Comment From: gopherbot

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

Comment From: gopherbot

Change https://go.dev/cl/628855 mentions this issue: crypto/internal/fips: handle the one possible PCT failure

Comment From: gopherbot

Change https://go.dev/cl/629056 mentions this issue: crypto/internal/fips: import crypto/internal/fips/check throughout

Comment From: gopherbot

Change https://go.dev/cl/629095 mentions this issue: crypto/internal/fips/aes/gcm: add GCMForSSH

Comment From: gopherbot

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

Comment From: gopherbot

Change https://go.dev/cl/630095 mentions this issue: crypto/internal/fips/rsa: support all SHA hashes in PKCS#1 v1.5

Comment From: gopherbot

Change https://go.dev/cl/629675 mentions this issue: crypto/tls: FIPS mode

Comment From: gopherbot

Change https://go.dev/cl/632215 mentions this issue: crypto/internal/fips140/rsa: add Miller-Rabin test

Comment From: gopherbot

Change https://go.dev/cl/632415 mentions this issue: crypto/internal/fips140/bigmod: add Inverse and gcd

Comment From: gopherbot

Change https://go.dev/cl/632479 mentions this issue: crypto/internal/fips140/rsa: do trial divisions in key generation

Comment From: gopherbot

Change https://go.dev/cl/632478 mentions this issue: crypto/x509: keep RSA CRT values in ParsePKCS1PrivateKey

Comment From: gopherbot

Change https://go.dev/cl/632476 mentions this issue: crypto/rsa: move precomputation to crypto/internal/fips140/rsa

Comment From: gopherbot

Change https://go.dev/cl/632477 mentions this issue: crypto/rsa: move key generation to crypto/internal/fips140/rsa

Comment From: gopherbot

Change https://go.dev/cl/632535 mentions this issue: crypto/rsa: minor FIPS 186-5 compliance fixes

Comment From: gopherbot

Change https://go.dev/cl/632537 mentions this issue: crypto/internal/fips140/rsa: add Pairwise Consistency Test

Comment From: gopherbot

Change https://go.dev/cl/632536 mentions this issue: crypto/rsa: allow keys larger than 16384 bits in FIPS mode

Comment From: gopherbot

Change https://go.dev/cl/634775 mentions this issue: crypto/internal/fips140/ecdsa: fix reseed_counter check for HMAC_DRBG_Generate_algorithm

Comment From: gopherbot

Change https://go.dev/cl/636558 mentions this issue: crypto/internal/fips140: add Name and Version

Comment From: gopherbot

Change https://go.dev/cl/636775 mentions this issue: crypto/internal/fips140/aes: mark AES-ECB as not approved

Comment From: gopherbot

Change https://go.dev/cl/636795 mentions this issue: crypto/cipher: block non-AES CTR and CBC in fips140=only mode

Comment From: gopherbot

Change https://go.dev/cl/637175 mentions this issue: crypto/internal/fips140/aes/gcm: use aes.EncryptBlockInternal on ppc64x and s390x

Comment From: gopherbot

Change https://go.dev/cl/637177 mentions this issue: cmd/go,crypto: reject using Go+BoringCrypto and fips140 together

Comment From: kojiatdell

Hi @FiloSottile I like to know how the Go Crypto code will be validated. Is it going to be FIPS140-3 validated as source code?

Comment From: gopherbot

Change https://go.dev/cl/638855 mentions this issue: crypto/internal/fips140/check: remove Enabled

Comment From: gopherbot

Change https://go.dev/cl/640597 mentions this issue: crypto/internal/fips140/drbg: add package comment

Comment From: juliens

Hi Team,

From my understanding, there seems to be a conflict between FIPS requirements and the QUIC specification defined in RFC 9001. ( I created an issue on the Quic-go repository as well https://github.com/quic-go/quic-go/issues/4894 )

According to Section 5.8 of RFC 9001, QUIC mandates the use of a fixed nonce for handshake retries. However, FIPS explicitly prohibits the use of fixed nonces, as this weakens cryptographic security. This appears to create a direct conflict between the two standards.

What would be the best approach to address this apparent conflict in a FIPS-compliant context?

Thank you for your insights and guidance!

Comment From: neild

Some added detail on QUIC vs. FIPS:

With GODEBUG=fips140-only set, crypto/cipher.NewGCM panics with an error indicating that GCM with arbitrary IVs is not permitted.

QUIC includes a feature called "address validation", in which a server responds to a client's first packet with a demand for proof that the client can receive packets sent to its source IP address. In address validation, the server sends a "Retry" packet to the client containing a token and the client restarts the handshake with the provided token (providing proof that it was able to receive the server's Retry packet).

The Retry packet sent by the server contains proof that the sender observed the client's Initial packet, preventing an off-path attacker from sending spoofed retries.

This proof (the Retry Integrity Tag) comes in the form of the output of AEAD_AES_128_GCM used with a fixed secret key, fixed nonce, empty plaintext, and associated data containing certain fields from the client's Initial packet.

It doesn't appear to be possible to generate the Retry Integrity Tag in FIPS-140 mode.

See: https://www.rfc-editor.org/rfc/rfc9000#section-8.1.2 https://www.rfc-editor.org/rfc/rfc9001.html#section-5.8

Comment From: FiloSottile

I believe at the very least we'd have to explicitly test the use of the FIPS module's AES-GCM with QUIC, and claim support in the Security Policy. It's too late for that in v1.0, but we can keep it in mind for v2.0.

Comment From: neild

Presumably too late for v1.0, but perhaps a no-plaintext GCM variant would be acceptable to FIPS? (Returns an AEAD that accepts key, nonce, and additional data only, panics if the plaintext is non-empty.)

Comment From: marten-seemann

I'm not sure what v1.0 and v2.0 refer to here (it's the first time these version numbers are mentioned in this thread, as far as I can tell), but it sounds like resolving this problem won't happen before the Go 1.24 release? Is that correct?

If that's the case, it simply won't be possible to run QUIC when using fips-only mode, as Retry is a non-optional part of the RFC. quic-go currently panics on initialization, since we call cipher.NewGCM in init, but we could change this to returning an error when the user tries to dial / listen for QUIC connections.

Comment From: bwesterb

I think the use of AES GCM here is a red herring. When using TLS over TCP, there is plenty of stuff that's not encrypted (packet headers), which FIPS doesn't care about. I don't think FIPS cares about the retry packet.

Comment From: chr-bell

There are other forms of AES_GCM which have different IV constructions that are exceptions to the rules in SP 800-38D; they are noted mostly in FIPS 104-3 IG C.H. If the QUIC retry requirement looks like one of the applications listed there, then your CSTL should be able to justify the usage of AES_GCM in this way. In addition, your lab could write an RFG to the CMVP regarding this. It is quite possible that you can get an explicit approval of this use which would appear in an updated 140-3 IG.

Also, the rule for the nonce (which is part of the IV in AES_GCM in SP 800-38D) is to ensure that no IV/Key is ever applied to two different data blocks; this is because those two variables alone define the key stream used in the encryption. If the IV/key for the retry packet has only been used to encrypt an empty block in the past, then then no rules are violated here.

From: Bas Westerbaan @.> Sent: Wednesday, January 22, 2025 6:06:15 AM To: golang/go @.> Cc: Christopher Bell II @.>; Manual @.> Subject: Re: [golang/go] crypto: obtain a FIPS 140-3 validation (Issue #69536)

— Reply to this email directly, view it on GitHubhttps://github.com/golang/go/issues/69536#issuecomment-2607070074, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AV77ZKAJWMRXSWWF2F5ZW532L6CTPAVCNFSM6AAAAABOQCZ2HSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGA3TAMBXGQ. You are receiving this because you are subscribed to this thread.Message ID: @.***>

Comment From: tsuna

Does anyone know which processors / OS are being tested by the CMVP lab?

Comment From: sfc-gh-ptabor

Hi,

@FiloSottile Could you, please, comment on status of CMVP certification:

https://go.dev/doc/security/fips140 says:

Go Cryptographic Module version v1.0.0 is currently under test with a CMVP-accredited laboratory.

But it's not on the NIST list of validations in progress:

https://csrc.nist.gov/Projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list

Comment From: FiloSottile

Modules get on the In Process list after they complete lab testing. You can find the module on the Implementation Under Test List.

@tsuna we’re testing and vendor affirming a wide range of platforms to support most ecosystem users. We’ll publish the list once the module reaches the In Process list. If you have specific commercial requirements, you can contact me via email.

Comment From: gramidt

Happy Wednesday, @FiloSottile!

Thank you so much for all of your hard work on this! I know the community sincerely appreciates it.

After a conversation with a couple of CSTLs, I learned that the CMVP queue is estimated to be 12-24 months long for new submissions. Given that the module is on the IUT list, would it be safe to say that the community shouldn't expect a certificate before the middle of 2026 at the earliest?

Also, could you share the CSTL chosen to perform the validation?

Thanks again!

Comment From: arashnikoo

I'm really excited about this! Honestly, we're all eager to move on from the "experimental" BoringCrypto module.

I have a question regarding the FIPS certification process—once it's approved, how will new version releases be handled? Will we need to submit the entire project for validation each time?

Also, it would be helpful to share the Security Policy with the community before submitting it to NIST so we can review and provide feedback.

Comment From: AlexRuzin

Hello everyone, I am really excited that crypto is going through FIPS-140-3, and at an interesting time too!

Does anyone know what the timeline is for this certification, though? Is it release-dependent? Or if there's any way to discuss a way to move forward? Any options or suggestions to get the ball rolling would be welcome.

Thanks in advance guys and I appreciate all the work.

Comment From: juburr

It just disappeared from the "Implementation Under Test List". Does that mean it will soon be transitioning to the "Modules In Process List"?

Comment From: FiloSottile

It just disappeared from the "Implementation Under Test List". Does that mean it will soon be transitioning to the "Modules In Process List"?

Great eye! :) Indeed, we expect it should appear on the Modules In Process list any day now.

As for the other queries, we (Geomys) went out of our way to make this validation as useful for the community as possible: the module is part of the tree under the same open source license as the rest of Go, the Security Policy will apply no commercial restrictions on its use, and we even paid out of pocket to test some Operating Environments we figured might be helpful.

However, we are not going to answer questions about the validation process or about compliance on the issue tracker, nor do we plan to share documents such as the Security Policy before they are published by NIST. First, these are nuanced topics with liability implications that we prefer to discuss under appropriate agreements. Second, as everyone who works with it knows, FIPS 140-3 is not a security feature but a compliance target needed to sell to the US Government (and others). To be direct, we don't feel it is either necessary or appropriate to offer compliance consulting services for free. I hope that makes sense!

We do offer commercial services now, through customized invoicing or self-serve subscriptions, which provide email support and preview access to documents, among other things. I'll refrain from advertising those further on the issue tracker, but I will link to this comment when declining to answer FIPS 140-3 related questions ✨

Golang crypto: obtain a FIPS 140-3 validation

Background

The Go FIPS module

Further planning details

69521