Currently with go fips toolchain binaries appear to be universal - i.e. on linux, when fips is enabled, openssl fips is attempted, otherwise regular golang crypto is in use.
Specifically, ideally any given project that imports golang.org/x/crypto/sha3 and uses it either directly or via crypto APIs, utilises the regular golang crypto.
I am not sure how to design and implement this, hence opening this issue to explore possibilities.
at the very least I hope that hash registration can be highjacked and prevented overrides using x/crypto when in Fips mode.
### Tasks
- [ ] upgrade go-crypto-openssl / openssl to SHA3 capable one
- [ ] register SHA3 hashes with crypto APIs when available at runtime
- [ ] possibly prevent re-registration of FIPS hashes
- [ ] possibly highjack and replace imports of x/crypto/sha3 with internal/vendor/openssl/sha3
i wonder if sha3 package in golang-fips/openssl is sort of pointless. as really crypto/sha3 should be exposed by the toolchain and golang.org/x/crypto/sha3 should be patched to know how to use it.
Currently with go fips toolchain binaries appear to be universal - i.e. on linux, when fips is enabled, openssl fips is attempted, otherwise regular golang crypto is in use.
With newly contributed SHA3 implementation (https://github.com/microsoft/go-crypto-openssl/pull/58 or https://github.com/golang-fips/openssl/pull/88 ) it would be nice to preserve the same capability for SHA3 imports.
Specifically, ideally any given project that imports
golang.org/x/crypto/sha3
and uses it either directly or via crypto APIs, utilises the regular golang crypto.I am not sure how to design and implement this, hence opening this issue to explore possibilities.
at the very least I hope that hash registration can be highjacked and prevented overrides using x/crypto when in Fips mode.