crypto: upgrade to BoringCrypto fips-20230428 [freeze exception]

[xnox]

This only affects GOEXPERIMENT=boringcrypto

Previous BoringCrypto upgrade was at #64717

CMVP #4953 was issued on 1/27/2025 and should have been upgraded in go but hasn't.

It doesn't remove any services, but has the following new validated services in approved mode:

• AES-GMAC
• KAS-FFC-SSC
• KDA HDKF
• TLS v1.2 KDF RFC7627
• TLS v1.3 KDF

The TLS v1.2 KDF RFC7627 is important, because almost all other FIPS operating system now require it - RHEL 9, Amazon Linux 2023, Ubuntu 22.04, Chainguard among many others.

The first step of getting access to these algorithms in approved mode is to actually upgrade the boringcrypto module used in the build.

I have prepared and submitted this change at https://go-review.googlesource.com/c/go/+/681675
All tests pass in GOEXPERIMENT=boringcrypto mode.

Once the module upgrade lands, and if there is time additional work can be done to wire up access to boringcrypto implementation of those algorithms.

[gopherbot]

Change https://go.dev/cl/681675 mentions this issue: crypto/internal/boring: upgrade module to fips-2023042800 / CMVP #4953

[gabyhelp]

Related Issues

• crypto: upgrade to BoringCrypto fips-20220613 and enable TLS 1.3 [freeze exception] #64717 (closed)
• crypto: rollback BoringCrypto fips-20220613 update #65321 (closed)
• crypto/tls: Permit recently FIPS-approved protocols/algorithms #62372 (closed)
• crypto: upgrade to BoringCrypto fips-20220613 and enable TLS 1.3 [1.20 backport] #64718 (closed)
• crypto: upgrade to BoringCrypto fips-20220613 and enable TLS 1.3 [1.21 backport] #64719 (closed)
• proposal: dev.boringcrypto: use boringcrypto for HKDF in x/crypto/hkdf #47234 (closed)

Related Code Changes

• crypto/internal/boring: upgrade module to fips-2023042800 / CMVP #4953
• [dev.boringcrypto] all: merge commit 9d0819b27c (CL 314609) into dev.boringcrypto
• crypto/internal/boring: add dev.boringcrypto README.md text
• [dev.boringcrypto] crypto/tls: permit P-521 in FIPS mode

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

[ALTree]

Note:

The previous, unsupported mechanism to use the BoringCrypto module for certain FIPS 140-3 approved algorithms is currently still available, but it is meant to be removed and replaced with the mechanism described in this page in a future release.

https://go.dev/doc/security/fips140#goboringcrypto

[ALTree]

cc @golang/security

[xnox]

Note:

The previous, unsupported mechanism to use the BoringCrypto module for certain FIPS 140-3 approved algorithms is currently still available, but it is meant to be removed and replaced with the mechanism described in this page in a future release.

https://go.dev/doc/security/fips140#goboringcrypto

Yes, but we don't want to loose certification status. The new implementation is on the modules in progress list here, and it has status of "Review Pending (5/8/2025)".

The current statistics for queue speeds indicate that certification might be issued sometime before November 2026 (see CMUF linux crystal ball like projections by Amazon), or earlier (review speeds have been improving). Which will be retroactive - meaning all golang releases that have this module will gain certification from that point onwards.

Different procurement requirements can have different needs, and those doing self-retesting for Common Criteria, or doing Fedramp moderate, or having POAM might be already able to use the new module. But those that have active authroisation, or are doing Fedramp high, or have specific deployment needs may need the certified module only.

Thus like during 1.28 development the alternative module will gain certifiction. And boringcrypto experiment can likely be dropped instantly. As users will have 1.27 & 1.26 releases with supported boringcrypto, and simultaneous retroactive availability of certified new module in second half of 2026.

But this also means we should keep maintaining and updating the boringcrypto module in golang until the new-style module receives certification.

Hence this upgrade, and possibly one or two more updates of the boringcrypto module, until the new-style module is certified. As there are 2 boringcrypto submissions, ahead of the new-style module in the queue.

[FiloSottile]

Note that the currently in use BoringCrypto module has Sunset Date 7/22/2029.

As we've reiterated many times, Go+BoringCrypto is an unsupported mode that exists to address a Google-internal requirement. I don't know if Google will feel the need to update the module, I defer to the Google team on that. As a maintainer, I don't plan to proactively do any Go+BoringCrypto changes or to support it in any new features. This is not to be difficult: a big motivation for the native FIPS module was precisely to reduce the maintenance burden of updating and introducing cgo bindings all over the place, bindings that introduced the only security vulnerability found in the recent security audit.

I understand the native module (which is a supported setup) is not yet a solution for deployments that don't accept In Process modules, and that that's painful. Such is NIST's CMVP. Things will get better soon, hopefully.

[xnox]

Yes, current module still has active certification, but it also lacks features in approved mode that new golang toolchain demands. Specifically TLS v1.2 KDF RFC7627, so for me motivation of the upgrade is to gain additional services in approved mode, instead of using unvalidated implementations.

Can I step up maintaining Go+Boringcrypto then for now? Cause I still want to keep updating it, whilst awaiting the new-implementation certification. Across all stable branches, point releases, any audit or security issues.

Thank you for the pointer to the security audit report, I will go through the findings there.

Separately I should check, because I bet there must be a goboring experiment using aws-lc builds too somewhere out there. Which in many aspects has improvements over boringcrypto, and specifically in FIPS.

There were other upgrades to newer boringcrypto modules elsewhere. cc @kyessenov

[kyessenov]

AFAIK Google policy for crypto modules in Go is the same as for Envoy - it's always a relatively recent boringssl (and likely ahead of the publicly issued CMVP certificates). While this satisfies Google's compliance needs, it does not imply this setup works for everybody else.

[rolandshoemaker]

It's been already stated, but as the person at Google responsible for this let me just restate: the Go+BoringCrypto mode is entirely unsupported for usage outside of Google (as has always been the case). Determinations about when and why to update the module are made at the sole discretion of Google.

We plan, once the native module is certified, to deprecate and remove the Go+BoringCrypto mode. We currently have no plans to update the BoringCrypto module before then unless there is a compelling reason that affects Google's usage of the mode.

Modifications to the BoringCrypto integration have historically been more complex than they first appear, and have a non-insignificant chance to introduce security relevant issues.

[FiloSottile]

Can I step up maintaining Go+Boringcrypto then for now? Cause I still want to keep updating it, whilst awaiting the new-implementation certification. Across all stable branches, point releases, any audit or security issues.

That's a generous offer, but as context for our reticence to accept it, even if the primary maintenance work is done by someone else, the rest of the team still has to do reviews, navigate the complexity of the new cgo integrations when working on the relevant parts of the code, deal with the fallout of bugs and build breakages and vulnerabilities, and ultimately be responsible for its security.