On Tue, Dec 23, 2008, Steve Marquess wrote: > >> Q3. If the above function call(s) needs to be added, how about other >> changes like looking for the return code for ciphers now blocked by >> fips_mode so the app deals with it? Probably a good idea. > > An excellent idea, though if you stick to the conventional EVP level calls > that job is done for you. However, many applications allow a ciphersuite > to be specified as a runtime configuration option. You may want to > gracefully catch and report any non-allowed algorithm selections as the > config options are parsed instead of failing much later as the algorithm > invocation fails. Also many apps have a default ciphersuite that contains > non-allowed algorithms. >
Just as an additional comment. If an application previously only used software only ciphers and digests it may not even check the return codes. The EVP interface in FIPS mode traps such behaviour in a specific way. If you call EVP_CipherInit(), EVP_DigestInit() or similar with a non-FIPS algorithm you get an error code. If an application ignores that error code and continues to attempt to use that context in EVP_DigestUpdat() or EVP_CipherUpdate() et al a hard error will occur which will terminate the application. Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Homepage: http://www.drh-consultancy.demon.co.uk ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
