Re: Building a 64-bit version of the FIPS-capable OpenSSL on Mac OS X 10.6.7

2011-05-24 Thread ciphertexto 
On May 24, 2011, at 4:18 AM, Dr. Stephen Henson wrote:
 On Mon, May 23, 2011, ciphertexto wrote:
 
 On May 23, 2011, at 7:20 PM, Dr. Stephen Henson wrote:
 On Sun, May 22, 2011, Bill Durant wrote:
 
 Hello,
 
 Has anyone been able to build a working 64-bit version of the 
 FIPS-capable OpenSSL  on Mac OS X 10.6.7 (SnowLeopard)?
 
 I have built a 64-bit version of the fipscanister from openssl-fips-1.2.3 
 on Mac OS X 10.6.7.
 
 But fips_shatest and the openssl command are core dumping when I do a 
 'make test'
 
 For example:
 
 ./config fipscanisterbuild
 make
 make test (fips_shatest and openssl core dump at this step)
 
 
 Does fips_test_suite run OK?
 
 
 I ran fips_test_suite and it has been pegged for almost two hours on the 
 following:
 
 =
 $ ./fips_test_suite
  FIPS-mode test application
 
 1. Non-Approved cryptographic operation test...
 =
 
 The CPU is at 100% on fips_test_suite.  It does not get past that.  
 
 Any ideas?
 
 
 It can take a long time to execute sometimes as it performs two slow DH
 parameter generation operations. Retry it a few times. If it still doesn't
 complete try:
 
 OPENSSL_FIPS=1 util/shlib_wrap.sh apps/openssl version -a
 
 Note that the utilities in the 1.2.3 build come from an ancient version of
 OpenSSL 0.9.8 and to get a usable library you must build an FIPS capable
 OpenSSL using the 1.2.3 fipscanister.o and a recent 0.9.8 version.


fips_test_suite hangs (stayed there for more than 24 hours).  So I tried 
shlib_wrap.sh as you suggest and I got a core dump from openssl.

I am testing with a FIPS-capable OpenSSL using the 1.2.3 fipscanister.o with 
0.9.8r (the most recent version).

$ apps/openssl version
OpenSSL 0.9.8r-fips 8 Feb 2011

$ OPENSSL_FIPS=1 util/shlib_wrap.sh apps/openssl version -a
Segmentation fault (core dumped)

$ otool -c /cores/core.97244 | head -4
/cores/core.97244:
Argument strings on the stack at: 7fff5fc0

/Users/foo/svn/mac_crypto_64/Crypto/OSX/build_openssl_fips_capable/openssl-0.9.8r/apps/openssl

$ gdb apps/openssl /cores/core.97244 
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as x86_64-apple-darwin...Reading symbols for shared 
libraries  done

Reading symbols for shared libraries . done
Reading symbols for shared libraries  done
#0  0x3f61 in ?? ()
(gdb) bt
#0  0x3f61 in ?? ()
Cannot access memory at address 0x3f61
#1  0x092ff8bb in ?? ()
(gdb) quit

So does it look like the 64-bit version of the FIPS-capable OpenSSL on 
SnowLeopard is officially broken?

Thanks,

Bill

 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

Re: Building a 64-bit version of the FIPS-capable OpenSSL on Mac OS X 10.6.7

2011-05-23 Thread ciphertexto 
On May 23, 2011, at 7:20 PM, Dr. Stephen Henson wrote:
 On Sun, May 22, 2011, Bill Durant wrote:
 
 Hello,
 
 Has anyone been able to build a working 64-bit version of the FIPS-capable 
 OpenSSL  on Mac OS X 10.6.7 (SnowLeopard)?
 
 I have built a 64-bit version of the fipscanister from openssl-fips-1.2.3 on 
 Mac OS X 10.6.7.
 
 But fips_shatest and the openssl command are core dumping when I do a 'make 
 test'
 
 For example:
 
 ./config fipscanisterbuild
 make
 make test (fips_shatest and openssl core dump at this step)
 
 
 Does fips_test_suite run OK?


I ran fips_test_suite and it has been pegged for almost two hours on the 
following:

=
$ ./fips_test_suite
FIPS-mode test application

1. Non-Approved cryptographic operation test...
=

The CPU is at 100% on fips_test_suite.  It does not get past that.  

Any ideas?

Thanks,

Bill

 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org
 __
 OpenSSL Project http://www.openssl.org
 User Support Mailing Listopenssl-users@openssl.org
 Automated List Manager   majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org

FIPS-capable OpenSSL stops working sporadically

2011-05-23 Thread ciphertexto 
Hello,

Does any one know how can any application work 100% reliably with a 
FIPS-capable OpenSSL given the following requirement from page 33 of the 
OpenSSL UserGuide at http://www.openssl.org/docs/fips/UserGuide.pdf:

===
The standard OpenSSL build with the fips option will use a base address for 
libeay32.dll of 0xFB0 by default.  This value was chosen because it is 
unlikely to conflict with other dynamically loaded libraries. In the event of a 
clash with another dynamically loaded library which will trigger runtime 
relocation of libeay32.dll the integrity check will fail with the error

FIPS_R_FINGERPRINT_DOES_NOT_MATCH_NONPIC_RELATED

A base address conflict can be resolved by shuffling the other DLLs or re 
compiling OpenSSL with an alternative base address specified with the with 
baseaddr= option.

Note that the developer can identify which DLLs are relocated with the Process 
Explorer utility 
fromhttp://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/ProcessExplorer.mspx.;
=

I am hitting this problem sporadically with my application on various Windows 
flavors.  The dynamic loader on Windows changes the base address of 
libeay32.dll whenever it wants to.

As a result, my application stops working because FIPS_mode_set() fails.  So I 
am ending up with an unreliable application.

I have no control on all of the dynamically loaded libraries in a system so I 
unable shuffle the other DLLs as suggested in the user guide.  

And changing the base address at build time is also not guaranteed to work 100% 
reliably because it could also conflict with some other DLL's base address.

So what to do?  Is there some trick/workaround to make this work?

Thanks,

Bill