[mrweasel]

A question if I may: Could you "accidentally" make a FIPS compliant library? Assuming that the LibreSSL fork where to include ONLY the FIPS approved ciphers and hashing algorithms, it should be possible to have a library that could be passed of a compliant.

If I understand you correctly, the issue with FIPS is that you would have to be able to disable all but a subset of the features, regardless of these feature being worse or better than what is defined in the FIPS documents?

That's a bit more that one question, but I would like to know. Thanks.

[X-Istence]

It is not just that the library can only contain those specific approved ciphers and hashing algorithms, they also have to be certified through a lab, then that lab has to sign off on it (this costs thousands of dollars). You have to build in a self-test system that verifies the integrity of the FIPS components using known answer tests, and the FIPS module itself has to be able to self-check itself against a known hash, so your linker has to be nice enough to put the FIPS module at a known location (making exploitation simpler).

The whole FIPS canister thing in OpenSSL is a HUGE pain in the behind when you are building a library/product using it, and overall doesn't increase security one single bit. Yes your crypto is now FIPS 140 certified, big whoop.

[Note: I am going off the OpenSSL FIPS canister implementation details here...]

[ctz]

> Could you "accidentally" make a FIPS compliant library?

Let's differentiate between "FIPS compliant" and "FIPS certified".

FIPS complaint: you could get a FIPS certified product if you wanted, without changing your product.

FIPS certified: you paid NIST and a FIPS test lab some money, the lab tested your module, submitted a test report to NIST, and NIST published certificates saying that a certain version of your product (running on a particular OS and CPU architecture, for software modules) is FIPS certified.

So, yes, you could accidentally come up with a FIPS compliant crypto module. But getting certified costs actual money (last time I did it, as I recall just shy of $100k).

> the issue with FIPS is that you would have to be able to disable > all but a subset of the features, regardless of these feature > being worse or better than what is defined in the FIPS documents?

To some extent it depends what you mean by 'feature' here. If it's a crypto algorithm offered by your module for external use, there is quite little leeway. If it's a fundamental feature of your product that internally uses exotic crypto, you can often convince your test lab to gloss over it.