crypto: Understanding lack of FIPS validation

[gen0cide]

Go's crypto is not FIPS 140 validated and I'm afraid that there is no possibility of that happening in the future either. I think Ian's suggestion of using cgo to call out to an existing, certified library is probably your best bet. However, we would not be interested in patches to add hook points all over the Go library, so you would need to carry that work yourself.

Originally posted by @agl in #11658 (comment)

Hey Go team,

This is not another Issue asking you for FIPS. Totally understand current best practices is to CGO to invoke a certified library, or using the BoringCrypto route.

My issue is this:

While that is very well documented, the question doesn't seem to have ever been answered about why Go has "no possibility" of getting FIPS certification. I was wondering what the challenge here is. I can only assume it's one of the following:

• Technical limitation in FIPS specification that Go fundamentally cannot implement
• Disagreement among Go maintainers about implementing specific algos into stdlib that FIPS requires to be implemented
• No bandwidth for the Go maintainers to facilitate a formal FIPS verification process
• Lack of organization support for other reasons unknown?

Is it one of these? No one really knows. I've asked around and generally the answer is that we all know to use BoringCrypto, but no one really knows why. Given Go's incredible penetration of the Infrastructure tooling market, it seems like a formal FIPS verification that didn't require completely recompiling every tool would ultimately help Go become even more adopted in this space.

Really interested to simply learn more about the reasons here, and maybe can inspire some thoughtful discussion amongst the community.

Thanks!

[ianlancetaylor]

CC @FiloSottile @katiehockman

[agl]

I won't go into a full breakdown of all the work involved, but I'll touch on one FIPS requirement that might be illustrative:

FIPS modules are required to find all their code and data in memory at “power on” time, HMAC it all, and compare that against a stored value. That means that all packages included in the FIPS module have to be known by the linker and, somehow, their bounds (in terms of memory addresses) have to be exposed to the module for hashing. It means that the module code can't have any relocations in it otherwise the hash will change every execution. That's why FIPS modules are nearly always in shared libraries: a shared object has very similar requirements in order to allow memory pages to be shared. BoringCrypto might be the only general FIPS module that supports static linking and that involves a vortex of crazy where it's compiled to textual assembly so that a 2000-line Go program can rewrite the assembly in order to build something similar to a shared library inside a static object.

It's been years since I've looked at the Go linker but I suspect that would need lots of custom code to support this. If we secreted Russ away for a couple of weeks then I've no doubt it could be done, but it would be a weird special mode of the Go linker to carry forward forever. It would slow down linking and process startup so we would probably need a -fips flag plumbed all the way up to go build and the like.

That's not to mention that the effort of establishing and maintaining a FIPS certification is high in terms of engineering time and money paid to NIST and labs.

Thus the incentive to just use an external FIPS module.

[cagedmantis]

This is a question which has been answered. Please feel free to follow this question up with one of the forums listed at https://golang.org/wiki/Questions.