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

[Ben Laurie <[e-mail]>]

Peter Gutmann wrote:
> mcgrew <[e-mail]> 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