Re: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance

[Imran Ali]

Thanks Steve,

I cannot find any certificate that can use 2.0.12 under Windows Operating 
System which suggests to me that we will have to revert back to 2.0.10 which is 
listed under #1747 and use G.5 (user affirmation) to leverage new platforms.

Is there no plans to include Windows platforms for 2.0.12 and newer version?

Regards,
Imran

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Steve Marquess
Sent: 19 August 2016 14:31
To: openssl-users@openssl.org
Subject: Re: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance

On 08/19/2016 07:20 AM, Imran Ali wrote:
> Hi Guys,
> 
>  
> 
> I need some help. I am looking for some evidence which I can provide 
> to my auditor for FOM 2.0.12 is FIPS-140 compliance when compiled and 
> used in Windows environment. When I look at the NIST web site under
> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#17
> 47
> I cannot see 2.0.12 version.
> 
>  
> 
> Is there something I am missing?

Yes, it's rather confusing.

The one and only OpenSSL FIPS module ("OpenSSL FIPS Object Module 2.0") is -- 
for perverse bureaucratic reasons[*] -- covered by three separate[**] FIPS-140 
validations:

  #1747 (revisions 2.0, 2.0.1, ..., 2.0.10)
  #2389 (revisions 2.0.9, ..., 2.0.13)
  #2473 (revisions 2.0.9, 2.0.10)

As always the latest revision (for a given validation) subsumes all tested 
platforms listed for that validation. So for instance, 2.0.13 can be used for 
all 33 platforms currently listed for validation #2398.
There are about 200 distinct platforms now across all validations.

So you need to look at the listed platforms for all validations[**], and find 
which of them cover your platform (possibly more than one). Then use the latest 
revision of the module for that validation.

If you only find your platform(s) of interest on a validation ending at 
revision 2.0.10 (#1747, #2473), then you're forced to use revision
2.0.10 even though 2.0.13 (and future revisions) are completely backward 
compatible. From a technical perspective 2.0.N is completely functionally 
equivalent to all previous revisions < N, but down in the
FIPS-140 rabbit hole you're limited to the latest revision for the relevant 
validation(s)[***].

The easy way to remember it is "one real-world module, multiple FIPS-land 
validations". Or as one of my colleagues would put it, "...multiple flavors of 
FIPS-140 magical pixie dust". The choice of validation certificate number is a 
paper-chase exercise.

-Steve M.

[*] Obscenely perverse, I'm not even going to try and explain it. In fact IMHO 
no rational explanation is possible.

[**] Technically speaking more than three; validations #2391, #2422, #2454, 
#2575, #2631, #2676, and possibly others are "copycat" clones done by third 
parties that introduce yet more platforms. Since these validations are for the 
same OpenSSL FIPS module they are also accessible to all under the OpenSSL 
license.

[***] OTOH note the later revisions aren't "better" than the earlier ones in 
any meaningful sense, as we're not allowed to do feature enhancements or 
bug-fixes (not even vulnerability mitigations). With most software it's prudent 
to always use the latest revision to pick up bugfixes and refinements; for the 
FIPS module it doesn't matter.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marqu...@openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86)

[Scott Ware]

On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm  wrote:

> On 22/08/2016 22:33, Scott Ware wrote:
>
>>
>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm > >wrote:
>>
>> On 22/08/2016 20:09, Scott Ware wrote:
>>
>> We use libeay32.dll and ssleay32.dll from
>> https://slproweb.com/products/Win32OpenSSL.htmlin
>> our
>> applications and we recently moved from version 1.0.2a to
>> 1.0.2g and now on a few machines running a AMD Geode processor
>> we are getting "Unhandled exception at 0x005904dc
>> (libeay32.dll) in Test.exe: 0xC01D: Illegal Instruction".
>> We ended up building OpennSSL so we could debug into it and
>> found it is failing on "movsd xmm0,mmword" (see below) which
>> the AMD Geode does not seem to support. I have tried "SET
>> OPENSSL_ia32cap=~0x100", "SET OPENSSL_ia32cap=~0x200",
>> and "SET OPENSSL_ia32cap=~0x700"; and nothing seems to
>> change. I may not be using OPENSSL_ia32cap correctly. This
>> happens when calling SSL_CTX_new which then calls RAND_add.
>>
>> Any ideas on the best thing to do? We don't want to have to
>> manage different compiled versions of libeay32.dll and
>> ssleay32.dll if we can help it.
>>
>> Your disassembly looks like the C compiler was invoked with
>> options that caused regular C floating point code (in this
>> case, the passing of 45.0 as an argument to RAND_add()) to
>> be compiled into MMX/SSE instructions instead of backwards
>> compatible 80x87 floating point instructions or (for simple
>> cases like this) regular integer unit data movement
>> instructions (such as two pushes of 32 bit constants that
>> contain the halves of the 64 bit double constant, which
>> would have been more efficient on every x86 CPU).
>>
>> Did the build scripts or other source code contain any
>> differences from the official source code that can be
>> downloaded from openssl.org ?
>>
>> How did you invoke the build scripts (command sequence,
>> special build environment, special environment variables
>> etc.)?
>>
>> Which compiler and compiler version/edition did you use?
>>
>> It would be interesting to know if one of the common Windows
>> compilers does this unconditionally, making it unsuitable
>> for use in programs that need to be backwards compatible.
>>
>>
>>
>> I compiled using this process and seem to be getting the same result as
>> the .dll I downloaded from slproweb.com 
>> I downloaded the 1.0.2g source from openssl.com and
>> didn't change anything.
>>
>> From the "Developer Command Promt for VS2013"
>> perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg
>> ms\do_ms
>> nmake -f ms\ntdll.mak
>> nmake -f ms\ntdll.mak install
>>
> According to the following page
>
> https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx
>
> Visual Studio 2012 and later requires the following compiler
> option to generate code compatible with older CPUs (this is the
> default in Visual Studio 2010, and VS2010 does not support the
> option):
>
> /arch:IA32
>
>
> This compiler gotcha is specific to the 32 bit x86 architecture,
> the default looks like it is still sane for x86_64.
>
> Note to the FIPS team: Please check if this affects the FIPS
> module building procedure.


Jakob! Thank you so much! That was the issue.I added /arch:IA32 to the
APP_CFLAG and LIB_CFLAG in ms\ntdll.mak and I was able to compile a new
build that works on the problem machine. Is it worth doing a bug report on
so they might add that to the build scripts? Without it it seems like the
whole OPENSSL_ia32cap system is broken.

Before I had found this answer I had also installed nasm so I didn't have
to do the no-asm. So My current build process is:

>From the "Developer Command Promt for VS2013"
perl Configure VC-WIN32  --prefix=C:\OpenSSL-VC-32-DLL
ms\do_ms
ms\do_nasm.bat
(Edit ms\ntdll.mak to add /arch:IA32 to the APP_CFLAG and LIB_CFLAG)
nmake -f ms\ntdll.mak
nmake -f ms\ntdll.mak install

Thank you Jakob and the OpenSSL mailing list for the quick answers!
- Scott Ware
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users