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
• 092d18b

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.)}

[seankhliao]

FIPS is #69536

h1 is sha256, not md5

[xnox]

FIPS is #69536

h1 is sha256, not md5

But TLS prf imports md5, and so does SMTP, and so does internal/hash, and also sha1.

Whilst FIPS is one angle of this request, I also want to advocate to not use weak or inefficient cryptography for non-fips use case alone.

Regular users also deserve better.

[xnox]

I will double check but it seems that FIPS is #69536 is for the compiled applications. Not for the compiler itself, which has no capability right now to be compiled in a supported and compliant configuration.

Note this is w.r.t. compiler itself.

[seankhliao]

I don't see any specific proposal here, you may get what you want after #69536 and building the go toolchain with fips enabled.

[xnox]

and building the go toolchain with fips enabled.

Yeah, there are improvements to be made here. As this portion of the tasks has gaps. I will create individual small code commits to explain the small issues that add to this being harder than it could be.

[FiloSottile]

A reminder that the Go+BoringCrypto GOEXPERIMENT is not a supported mode, and its forks are definitely not supported.

Note that TLS 1.0 requires MD5+SHA1 for its KDF, and removing TLS 1.0 support is a major change that should be approached with more motivation than just "it makes FIPS forks easier", if that's what you're asking.

[xnox]

A reminder that the Go+BoringCrypto GOEXPERIMENT is not a supported mode, and its forks are definitely not supported.

Note that TLS 1.0 requires MD5+SHA1 for its KDF, and removing TLS 1.0 support is a major change that should be approached with more motivation than just "it makes FIPS forks easier", if that's what you're asking.

True. And we also have forever go 1 backwards compat.

I think what I am asking for a symetrical godebug to what tls10server is but for client. I.e. tls10client defaults to 1; but allows to set it at application compile time to 0; such that even if client tls version is requested below 1.2, it gets blocked.

Also something similar, to block import of crypto/md5 side-effects => as importing it registers it as a valid hash with the crypto subsystem, and can enable code that didn't import md5 to be able to process md5.

Such that there is backwards compat for client tls below 1.2; but it is possible to opt out of it; even when not using FIPS-forks. As regular non-fips users should have ability to only support strong cryptography as well (without the need to forcing FIPS usage onto themselves).