Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

crypto: Understanding lack of FIPS validation #45188

Closed
gen0cide opened this issue Mar 23, 2021 · 3 comments
Closed

crypto: Understanding lack of FIPS validation #45188

gen0cide opened this issue Mar 23, 2021 · 3 comments
Labels
FrozenDueToAge

Comments

@gen0cide
Copy link

gen0cide commented Mar 23, 2021 •
edited

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!
@gen0cide gen0cide changed the title crypto: Understanding lack of FIPS compliance crypto: Understanding lack of FIPS validation Mar 23, 2021
@ianlancetaylor
Copy link
Contributor

CC @FiloSottile @katiehockman

@agl
Copy link
Contributor

agl commented Mar 24, 2021

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
Copy link
Contributor

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.

@golang golang locked and limited conversation to collaborators Mar 31, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@agl @cagedmantis @gen0cide @ianlancetaylor @gopherbot