Then the EVP routines would just check to see if EVP_FIPS_MD or EVP_FIPS_CIPHER is set in the flags field in FIPS mode.
Which EVP routines need to be visited? I could leave out the non-FIPS
algorithms in OpenSSL_add_all_{ciphers|digests} as you suggested in an
earlier msg. EVP_add_{cipher|digest} I already have in my first patch.
EVP_{Encrypt|Digest}Init_ex, ditto. EVP_get_{cipher|digest}byname? What else would you recommend for more or less graceful coverage for an end
user like me with a weak grasp of the API who just wants to be sure he
didn't accidentally invoke any forbidden algorithms?
Well my personal perference would be to give a hard assertion error in EVP_DigestInit_ex() and EVP_CipherInit_ex() because a non-FIPS algorithm will only appear in there due to an application source error.
That's horribly unfriendly for (for example) interactive programs that could just tell the user they chose badly and to choose again.
The more subtle cases involve things like the S/MIME signing code. This advertises the supported encryption algorithms to the receiving party. It will currently include, among other things RC2. With no changes to the code everything would appear to work fine except that recipients might send S/MIME email back which can't be decrypted because an algorithm is being advertised which can't be supported.
Note that it was explicitly not an aim of the FIPS project to make all known applications of OpenSSL work in FIPS mode. Which is not to say that it wouldn't be nice if they did.
Cheers,
Ben.
-- http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"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 ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
