David Schwartz wrote: > In many cases, FIPS actually results in (you might reasonably think, at > least) reduced security. ... > > C) Quasi-FIPS. All FIPS rules are followed, except where it is genuinely > believed that these rules reduce security or are unreasonably impractical. > For example, obvious bugfixes might be allowed, even if the code hadn't been > re-FIPS checked. In the case of OpenSSL, you might allow changes to > optimization or code generation flags. An "obviously correct" optimized SHA1 > algorithm might be used, even if it hasn't been approved yet. (Or if it > wasn't selected for the platform due to a detection bug.) > IMHO it's hard to argue that FIPS *validated* software isn't clearly less secure in a real world sense, simply due to the fact that the validation process by its very nature provides heavy disincentives to the aggressive and proactive pursuit of suspected security vulnerabilities.
Frankly you shouldn't use FIPS validated software unless specifically required to for formal policy compliance reasons. Use of FIPS *compliant* cryptography (strong crypto and FIPS approved algorithms) is another matter, but then you're not artificially constraining your options for identifying and correcting implementation vulnerabilities. -Steve M. -- Steve Marquess Open Source Software institute [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
