FIPS-140 Compliance

[atheriel]

There is some interest in FIPS-140 compliance, which would likely involve:

• An alternative encryption algorithm, hopefully AES-256-GCM since it's in the standard library. NaCL Secretbox is not FIPS-compliant, even though it is widely regarded as better in every way. Well-regarded cryptographers seem to think AES-256-GCM in Go is an OK alternative, though.

• Building the CLI tool with the BoringSSL fork of Go, because Go's crypto package is not FIPS-140 compliant. This fork is gaining popularity in the Kubernetes to create FIPS-compliant builds of popular projects (Calico, k8s itself, Contour, etc.). Moreover, this approach was formally verified for Rancher's enterprise Kubernetes distribution.

• Providing FIPS-compliant binary releases. Note, however, that GoReleaser does not easily support custom binaries, unless run in Docker. Another option would be to provide Docker images using two-stage builds and the official BoringSSL fork image, as is done by Contour.

• Investigating whether downstream users of the bundled crypt package can be built with the BoringSSL fork, too.

Some notes:

• There are a few possible API choices here, including a build-time decision (using build tags) and a runtime "I want FIPS" decision. The build-time decision seems more consistent with FIPS in general, even if it's more opaque to users.

• I've discovered that Docker Swarm used a runtime FIPS flag to select AES-128-CBC, but from a casual reading of that package this approach would not be FIPS-compliant by itself, since it uses Go's (non-compliant) crypto under the hood.

• I don't want to guess whether these changes would make us compliant. We'll have to get a more formal opinion on the matter.