| > 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. |