Hi. We are experimenting with the FIPS 2.0 Object Module RC1 and the recent GA of OpenSSL 1.0.1. We have a successful FIPS-capable build of OpenSSL and we've verified it with the openssl CLI with OPENSSL_FIPS=1 set. Our experiments are currently limited to Linux X86_64, and we are not using assembler optimizations
We are able to build FIPS into our application shared library in two scenarios: 1. Where our shared library links against the libcrypto.so and libssl.so (and fipscanister.o obviously). 2. Where our shared library links statically with libcrypto.a and libssl.a (and fipscanister.o obviously). The reasons we want to do this are too messy for this mail. When the application calls FIPS_mode_set(), in Case 1 above (shared), it is successful. In Case 2 (static), FIPS_mode_set() returns "fingerprint mistmatch" . The User Guide implies both in sections 5.3 and 5.4 that linking FIPS OM/OpenSSL into an application shared library is permitted and acceptable. THE MAIN QUESTION IS: is Case #2 supported? Should we be able to create an application shared library with a statically linked libcrypto.a (and fipscanister.o)? If the answer is YES, then we'll return to our drawing board. If the answer is NO, then we move to a different drawing board. Thanks for a simple YES or NO, but other explanatory details are welcome. Dave +-+-+-+-+-+-+ Dave McLellan, Symmetrix Software Engineering EMC Corporation, 176 South St, Hopkinton MA Mail Stop 176-B1 1/P-36 office 508-249-1257, fax 508-497-8027 cell 978-500-2546 +-+-+-+-+-+-+
