Go 1.24 FIPS module support

[hxtk]

Is your feature request related to a problem?

Many of the cryptographic primitives supported by Tink are FIPS-compliant, and using Tink in a FIPS mode is officially supported for the C++ implementation by linking it against the FIPS-certified BoringSSL cryptographic module.

However, using this library with Go 1.24 GODEBUG=fips140=only crashes for a number of reasons, plainly reproduced by cloning this repository and running GODEBUG=fips140=only go test ./....

In particular, AES-GCM is a FIPS-compliant primitive that does not work in FIPS-only mode because they are not initialized in the way that is required by the FIPS-only mode: Tink explicitly generates a random nonce, but the FIPS module requires that AES-GCM be initialized using crypto/cipher.NewGCMWithRandomNonce so that the cryptographic module can verify nonces are being generated in a way that conforms to FIPS140-3 Annex C.H. Section 2

What sort of feature would you like to see?

In many cases, getting these tests to pass again is simple and from what I can see there's basically one obvious way to do it: nearly all uses of crypto/cipher.NewGCM can be safely replaced with crypto/cipher.NewGCMWithRandomNonce, which was introduced in 1.24. In practice, this would mean extracting it into a separate file and using a //go:build go1.24///go:build !go1.24 build tag pair so that things continue to work in the current way in order to compile with Go 1.23.

However, that does not address the algorithms can be made to work, but are not FIPS-approved. In GODEBUG=fips140=on, I would expect these to work, but with GODEBUG=fips140=only, it would guard against developer error if they would error in initialization.

Have you considered any alternative solutions?

Without this change, Tink Go remains unusable in FIPS-required environments, which was already the status quo.

[hxtk]

I've begun making progress on this in my fork: https://github.com/hxtk/tink-go

Modules whose tests fail in FIPS mode which have been fixed in the fork:

• aead/...
• hybrid/...
• insecurecleartextkeyset/...
• mac/...
• prf/...
• signature/rsassapss
• streamingaead/...
• subtle/...
• testutil

One open question is how to test this systematically in CI: my fork has differing behaviors across Go versions and across FIPS-enabled vs disabled. Ideally, tests would be run against both, but also between the two versions (i.e., ensuring data encrypted with the Go 1.23 implementation can be decrypted with the Go 1.24 implementation and vis versa).

Technically, running the tests with GODEBUG=fips140 being on or only only has the effect of disabling some tests, so it would not be necessary to test across that axis unless testing for well-defined unhappy paths such as returning the expected error values at the expected stages for non-FIPS algorithms in FIPS modes, but I do not plan on adding such tests in my fork at this time.