proposal: crypto/md5: deprecated cryptography used for security purposes or in security sensitive codepaths

[xnox]

Proposal Details

Goals:

• 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.
• For 2030+ same issue will apply to sha1 as well

Successful changes:

• recently it was successfully updated coverage framework from using md5 to using FNV-1a https://go-review.googlesource.com/c/go/+/617360

Minimal proposal:

• 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.

Code references:

• https://github.com/golang/go/blob/master/src/cmd/go/internal/modcmd/verify.go
• https://github.com/golang/mod/blob/master/sumdb/dirhash/hash.go
• https://github.com/golang/go/blob/master/src/cmd/internal/hash/hash.go
• https://github.com/golang/go/blob/master/src/net/smtp/auth.go
• https://go-review.googlesource.com/c/go/+/617360
• https://github.com/golang/go/commit/092d18b31824d35a07f796c90380d5e607b61681

Sample toolchains that operate in FIPS mode, including the go toolchain itself:

• https://images.chainguard.dev/directory/image/go-msft-fips/overview

[gabyhelp]

Related Issues and Documentation

• boringcrypto: Not using FIPS compliant calls for SHA functions (also should we add md5? for easy proof of FIPS mode on) #66513 (closed)

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