On Wednesday, June 23, 2004 1:36 PM Dr. Stephen Henson wrote:
>> Note we do not need to disable all possible uses of non-FIPS
>> algorithms in all circumstances, just catch the typical usages on
>> a good faith basis.
>
>There are all manner of potential issues which can arise when algorithms are
>disabled and applications (including OpenSSL internal code) don't expect it.
>
>In fact for OpenSSL 0.9.6 and earlier EVP_CipherInit() and EVP_DigestInit()
>couldn't return an error at all because they were void types.
>
>Even in 0.9.7 and later errors would only occur if memory allocation errors
>occured or a hardware ENGINE error. That is sufficiently rare than an
>application silently assuming such calls would succeed would appear to work
>fine.
>
>As a result many applications calling EVP_CipherInit etc may not even check for
>an error condition and have totally undefined behaviour when EVP_CipherUpdate()
>is called later. Some kind of controlled hard error such as an assertion
>failure might be in order to cover this case.
I won't argue with any of the problems you note. FIPS 140 can be a PITA.
However, there is one reason and one reason alone to use FPS 140 validated
cryptography -- you work for (or sell to) the U.S. or Canadian governments
and have to (I believe the U.K. may be headed there too).
If you use non-FIPS algorithms your application, by definition, is *not*
using FIPS 140 validated cryptography. If you are in a position to use
non-FIPS algorithms then FIPS mode shouldn't be used at all, there's no
point to it.
There is a User Guide for FIPS mode which will be released when the
validation is complete. When we the mechanisms for disabling non-FIPS mode
are known (such as a bad return code from EVP_CipherInit) I will document
them there. Note that source code modifications are necessary to convert an
application to use FIPS mode, those mods can include checking the return
codes that might have been ignored before.
>There are other problems which might occur. For example disabling RC2
>will mean that PKCS#12 files can't be parsed from many implementations.
>Disabling MD5 will stop verification of some certificates (including VeriSign
>ones) and so on.
MD5 is a problem because it is so pervasive. But, it's a no-no for
FIPS 140. If it's essential for VeriSign certs then the special hook
Ben created to allow use of MD5 with TLS could be used, but the product
will then have to be advertised as using FIPS 140 validated crypto _except_
for VeriSign certificate verification.
In the patch I created for OpenSSH I likewise had to enable MD5 for the
shadow login password check.
>OpenSSL also uses (for historical reasons) MD5 for its directory based
>certificate lookup. That would also fail.
Yes, same problem with OpenSSH and key passphrases. As it is OpenSSH
keys will have to be converted using ssh-keygen in non-FIPS mode to
remove the passphrases, and then again in FIPS mode to reset them using
SHA1 instead of MD5.
-Steve M.
