Re: [saag] Algorithms/modes requested by users/customers

["Santosh Chokhani" <SChokhani at cygnacom.com>]

Ben,

1.  In terms of Coverity, it complements what FIPS does.  Coverity is a
good tool for looking at code complexity and possible soft spots.  Note
that FIPS scrutiny is not very deep.  It does not even perform full
functional or interface testing.  It is more akin to demonstration
testing at EAL 2 for Common Criteria.  For Common Criteria, for
vulnerability analysis and testing, we do recommend that the developers
use automated tools for static code analysis and test coverage analysis.

2.  On the PRNG, I see FIPS having some cogent requirements.  The basic
requirements are that the entropy of the seed by commensurate with the
entropy for the key being generated and the seed be pseudo randomized.
I have myself worked with the developer to successfully obtain NIST
approval when the PRNG algorithm has varied from FIPS approved methods.

3.  I do not know what happened in your case.  A wild stab is that may
be the you were going for level 1 only for the operating environment
also and multi-threading was not permitted.  That is not an excuse.  I
do not know enough to suggest how U would handle this.

4.  As to extra code, I do not know what you are specifically concerned
with.  I have for about 8-9 years unsuccessfully advocated to NIST to do
away with self-tests.  They were meaningful in old days of truly
hardware crypto.  Now, most hardware crypto is on some generic
processor, and POST for the processor are sufficient as opposed to
crypto specific tests. 

-----Original Message-----
From: saag-bounces at mit.edu [mailto:saag-bounces at mit.edu] On Behalf Of
Ben Laurie
Sent: Thursday, March 06, 2008 4:43 AM
To: Peter Gutmann
Cc: saag at mit.edu; rja at extremenetworks.com; mcgrew at cisco.com
Subject: Re: [saag] Algorithms/modes requested by users/customers

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
_______________________________________________
saag mailing list
saag at mit.edu
http://mailman.mit.edu/mailman/listinfo/saag