Peter Gutmann wrote:
mcgrew <mcgrew at cisco.com> writes:Winston Churchill said that democracy is the worst form of government, except for all of the others. I think that the same is true for the FIPS-140 cryptomodule validation process ;-)I think it's more a case of the Politician's Fallacy: 1. Something must be done. 2. This is something. 3. This must be done. It'd be interesting to see a study of the effectiveness in terms of finding security and interop problems of: A. A FIPS 140 eval. B. Running the code through Fortify/Coverity/whatever and completing a crypto exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is that's being used). in particular in terms of return for effort-involved.
Having done both of these, I can give you an impromptu answer, and also comment on some other themes I've seen on this thread. The background here is I did most of the initial work for the FIPS-140 eval of OpenSSL. I also have access to Coverity runs over OpenSSL.
There's no doubt that Coverity gives far more return on effort. It actually found problems. FIPS-140 did not (though it did create some, see below). Coverity took only a few days of investment. FIPS-140 took months (and years of elapsed time).
Other themes...Silly modes: FIPS-140 doesn't introduce silly modes that are available to client s/w, but it does introduce some really quite complex silliness for the tests, involving repeated encryption of a block, extracting some of the output and using it to create new keys and data for more repeated encryptions. Getting those right was really very painful - and, as far as I can see, no more useful than standard test vectors.
Fixed input to PRNGs: someone observed that this is worrisome from a security point of view. The fact that OpenSSL got certified and yet had a huge security hole because it accidentally left the PRNG seeded from the self-test supports this concern (http://openssl.org/news/secadv_20071129.txt).
Weak PRNGs: no-one mentioned this, I don't think, but one of the things that bugged me most was having to replace OpenSSL's PRNG with a much weaker one, as required by FIPS-140.
Enforced security holes: again, not mentioned, but one of the problems with PRNGs under Unix is that after a fork, both copies will produce the same randomness. OpenSSL protects against this by detecting a fork and mixing in different stuff in the two processes. I replicated this behaviour for FIPS-140 and was forced to remove it. The result is that if you use FIPS-140 mode and you fork, if you don't reseed the PRNG yourself, you have made a big mistake.
Cost: Peter Gutmann points out that the total cost of an eval vastly exceeds the cost of the testing lab. He's right. There's a huge amount of paperwork and pointless code to write.
Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.