Most projects that compile against OpenSSL can be forced into FIPS mode by setting a flag that the OpenSSL library uses to force enable FIPS mode when it is loaded.
Golang projects however don't compile against OpenSSL instead using the internal cryptography. In many cases rebuilding and repackaging a Golang based tool is a no-no since now you are accepting ownership of it in an audit, when instead you want to point to an upstream vendor, or source code is not available.
So in many cases in production while the system itself is in FIPS mode (Linux kernel), and applications using system crypto libraries (OpenSSL primarily) are in FIPS mode, Go binaries are not in FIPS mode and may end up using algorithms that are explicitly disallowed by the FIPS standards.
We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure.
It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: not FIPS-2 compliant.
So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.
FIPS and "be secure" aren't necessarily a full overlap: there's plenty of ways to be secure that isn't even allowed in FIPS, so you need to actively disable that set if you run FIPS mode (depending on libraries used, this may e.g. disqualify hardware intrinsics because it was not covered by CMVP, creating potentially material performance consequences).
If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.
In some cases that's true, but not all. We have customers who require that our software supports running in a FIPS compliant mode, but never actually end up enabling it in production. But they wouldn't have bought our software without the option of enabling FIPS mode.
ArchOversight|1 year ago
Golang projects however don't compile against OpenSSL instead using the internal cryptography. In many cases rebuilding and repackaging a Golang based tool is a no-no since now you are accepting ownership of it in an audit, when instead you want to point to an upstream vendor, or source code is not available.
So in many cases in production while the system itself is in FIPS mode (Linux kernel), and applications using system crypto libraries (OpenSSL primarily) are in FIPS mode, Go binaries are not in FIPS mode and may end up using algorithms that are explicitly disallowed by the FIPS standards.
prerok|1 year ago
We created software and we wanted it to be secure (by ourselves). When it came to FIPS compliance, we had to pay for certification, but we were already compliant anyway, so it was only procedure.
It's definitely not as strict as the latest developments in crypto would demand, but it does cover the product in its entirety. Like, oh, you have encryption, but you have a backdoor here: not FIPS-2 compliant.
So, yes, plenty of software and products are FIPS compliant. And if it's mandated, then the provider is not chosen.
lantastic|1 year ago
If you're already compliant (implying you are using FIPS compliant crypto in all situations), the matter is tautological.
tptacek|1 year ago
treesknees|1 year ago