allow building compiler, building applications (go build), running applications (go run) without deprecated cryptographic algorithms compiled-in or relied upon
extreme goal is to be able to do that in FIPS-approved only mode with one of the popular goexperiment forks (systemcrypto opensslcrypto boringcrypto)
Issues:
/usr/bin/go uses cryptography for security & non-security purposes.
Examples of security related purposes is the go get functionality, computing and verifying h1: go module hashes
Examples of non-security sensitive purposes are ./src/cmd/internal/hash/hash.go Size16 Size20 Size32
In src/cmd/dist/build.go CGO_ENABLED=0 is set that prevents using FIPS-certified cryptography, as so far gocrypto has not been through certification
It means that non-FIPS certified implementations are used for security sensitive purposes and are available for go get functionality
Hopes & Dreams:
Enable building go get functionality with CGO with FIPS-approved/certified cryptographic implementation. However, I am not confident it if it possible to split go get and h1 calculation out of the go binary into one of the tools binaries like for example pkg/tool/$arch/nm is a standalone program. As that would allow using non-fips-certified hashes in cmd/internal/hash/hash.go whilst the security sensitive tool that does TLS and h1: for go get is using strong and optionally certified cryptography.
it would be very nice if GoDEBUG features could be introduced that potentially moves md5 from crypto/md5 to hash/md5; or doesn't register it as a valid hash in md5; or disables md5 usage from TLS, crypto and net/smtp/auth.
Similarly for other internal non-cryptographically secure usage it would make sense to also use FNV-1a or switch to more performant non-cryptographically secure hashes https://xxhash.com/ for example for internal-only usage
Work towards splitting go get and h1 calculation functionality into a separate tool binary or a separate plugin
Introduce opt-in, off by default, GoDEBUG that prevent md5 from registring into the crypto sub system
Introduce opt-in, off by default, GoDEBUG that blocks client TLS md5
Use strong cryptography even for non-security purposes (?!) but that's like a never ending change, md5 is old now, sha1 will be old in 2030, and PQC standards seem to be advocated to use KECCAK based hashes and XOFs.
I hope the above reasoning and goals are reasonable, the path to resolving all of the above is open-ended however, so not sure if this issue will simply end up being locked for future reference. Or if smaller items get resolved, such that it is 80% done.
Proposal Details
Goals:
Issues:
go get
functionality, computing and verifying h1: go module hashesgo get
functionalityHopes & Dreams:
go get
functionality with CGO with FIPS-approved/certified cryptographic implementation. However, I am not confident it if it possible to splitgo get
andh1
calculation out of thego
binary into one of thetools
binaries like for examplepkg/tool/$arch/nm
is a standalone program. As that would allow using non-fips-certified hashes in cmd/internal/hash/hash.go whilst the security sensitive tool that does TLS and h1: forgo get
is using strong and optionally certified cryptography.Successful changes:
Minimal proposal:
go get
and h1 calculation functionality into a separate tool binary or a separate pluginI hope the above reasoning and goals are reasonable, the path to resolving all of the above is open-ended however, so not sure if this issue will simply end up being locked for future reference. Or if smaller items get resolved, such that it is 80% done.
Code references:
Sample toolchains that operate in FIPS mode, including the go toolchain itself: