I've been working on getting a FIPS Capable OpenSSL into OpenSolaris. Due to the way the FIPS Capable OpenSSL is built it ends up with older implementations of ciphers (all the ones that fipscanister.o implements). These cipher implementations are used regardless of being in FIPS mode or not. As the ciphers from fipscanister.o (FIPS object module 1.2) come from an older release of OpenSSL they do not perform as well as the current implementations (e.g. AES is *much* slower on Intel Core 2 CPUs). The net result of this is that we'll probably deliver two versions of libcrypto. One using the latest cipher implementations (0.9.8k) but not FIPS enabled and the other FIPS enabled with the more poorly performing cipher implementations. This is seems to be an inherent problem as certification always takes some time - the FIPS certified cipher implementations will always lag the latest and greatest stable version. Is this something we just have to live with or is there a plan to somehow get the best of both worlds (speed and FIPS in one library)?
A consequence of delivering two libcryptos is that one will have the FIPS_* symbols and the other will not. This makes building applications which support the FIPS mode problematic if they are to run with both libcrypto versions. They could be patched to use dlsym() but it would be nice to avoid such hackery. Is there any reason the regular non-FIPS Capable OpenSSL couldn't contain the FIPS_* symbols (which would always fail when called) ? I'm new to the list so if these things have been discussed before feel free to send me to an archive of that previous discussion. Thanks, -M ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
