Re: [openssl-users] [External] Re: Correct the check of RSA_FLAG_SIGN_VER

[Eichenberger, John]

Knowing now that RSA_new_method() copies the RSA_METHOD flags field to the RSA 
flags field I modified my instance of wpa_supplicant such that it works even 
without changing OpenSSL.
However, I still say that this is a bug with OpenSSL.  Let me tell you the 
short story that leads me to that conclusion.

wpa_supplicant has a bit of code that
1.  Allocates and defines a RSA_METHOD structure.
2. calls RSA_new();
3. calls RSA_set_method().

In that code the rsa_sign and rsa_verify members of the RSA_METHOD structure 
are not defined, thus making it compatible with the really old versions of 
OpenSSL.
But I need to change that and use the rsa_sign method, so I set the 
RSA_FLAG_SIGN_VER bit of the RSA_METHOD structure to indicate that I need to 
use that.
But my rsa_sign method was never called.

My "fix" is to set that same bit in the RSA flags field before calling 
RSA_set_method.
rsa->flags |= RSA_FLAG_SIGN_VER;

But shouldn't OpenSSL work without me having to do that?
Perhaps RSA_set_method() should also copy the flags field to match what 
RSA_new_method does?

Either that, or the meth->flags field should be tested.
Which is it?

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Eichenberger, John
Sent: Wednesday, April 04, 2018 9:07 AM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] [External] Re: Correct the check of 
RSA_FLAG_SIGN_VER

Honeywell Internal

Your answer #1 below presumes that RSA_new_method() is called AFTER 
RSA_set_method().  Is that a valid presumption?  How is that documented as a 
requirement?

When the flag is set in a call to RSA_set_method() after a call to RSA_new(), 
the flag gets ignored with the current implementation.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Richard Levitte
Sent: Tuesday, April 03, 2018 7:43 PM
To: openssl-users@openssl.org
Subject: [External] Re: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER

In message 
<bn6pr07mb3553b5b834436f685450d434f6...@bn6pr07mb3553.namprd07.prod.outlook.com>
 on Tue, 3 Apr 2018 22:55:06 +0000, "Eichenberger, John" 
<john.eichenber...@honeywell.com> said:

John.Eichenberger> Honeywell Internal
John.Eichenberger>
John.Eichenberger> I think I have an answer for why this commit needed to be 
reverted:
John.Eichenberger>
John.Eichenberger> Author: Dr. Stephen Henson <st...@openssl.org> 
John.Eichenberger> Author date: 2 years ago (12/20/2015 10:18:43 AM) 
John.Eichenberger> Commit date: 2 years ago (12/20/2015 11:27:03 AM) 
John.Eichenberger> Commit hash: 6656ba7152dfe4bba865e327dd362ea08544aa80
John.Eichenberger> Children: 1c7de36f62
John.Eichenberger> Parent(s): 17592f323a John.Eichenberger> John.Eichenberger> 
Don't check RSA_FLAG_SIGN_VER.
John.Eichenberger>
John.Eichenberger> Reviewed-by: Richard Levitte <levi...@openssl.org> 
John.Eichenberger> John.Eichenberger> The change made in that commit was to 
simply remove John.Eichenberger> the attempt to check for the RSA_FLAG_SIGN_VER 
flag.
John.Eichenberger> But that's not what is wrong with this code that 
John.Eichenberger> required changing. The change should be to add 
John.Eichenberger> "meth" prior to flags:

Well, not quite, actually.  We can easily study the code prior to this change 
by looking at the 1.0.2 source.

1. in RSA_new_method(), which is used to create new instances of the
   RSA structure, there's this line:

ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;

   So that makes the check of rsa->flags valid, no need to go via
   rsa->meth

2. In rsa.h (crypto/rsa/rsa.h in 1.0.2), you'll find this comment in
   the middle of the definition of rsa_meth_st

/*
 * New sign and verify functions: some libraries don't allow arbitrary
 * data to be signed/verified: this allows them to be used. Note: for
 * this to work the RSA_public_decrypt() and RSA_private_encrypt() should
 * *NOT* be used RSA_sign(), RSA_verify() should be used instead. Note:
 * for backwards compatibility this functionality is only enabled if the
 * RSA_FLAG_SIGN_VER option is set in 'flags'.
 */

   Do note the note on backward compatibility...  you see, there were
   versions of OpenSSL where the fields 'rsa_sign' and 'rsa_verify'
   didn't exist (they appeared in OpenSSL 0.9.5), so for the sake of
   allowing older applications to work with the newer OpenSSL without
   recompilation, we required all new RSA method implementations to
   use that flag to have the 'rsa_sign' and 'rsa_verify' functions
   used.  Without that flag, those functions were assumed not to
   e

Re: [openssl-users] [External] Re: Correct the check of RSA_FLAG_SIGN_VER

[Eichenberger, John]

Honeywell Internal

Your answer #1 below presumes that RSA_new_method() is called AFTER 
RSA_set_method().  Is that a valid presumption?  How is that documented as a 
requirement?

When the flag is set in a call to RSA_set_method() after a call to RSA_new(), 
the flag gets ignored with the current implementation.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Richard Levitte
Sent: Tuesday, April 03, 2018 7:43 PM
To: openssl-users@openssl.org
Subject: [External] Re: [openssl-users] Correct the check of RSA_FLAG_SIGN_VER

In message 
<bn6pr07mb3553b5b834436f685450d434f6...@bn6pr07mb3553.namprd07.prod.outlook.com>
 on Tue, 3 Apr 2018 22:55:06 +0000, "Eichenberger, John" 
<john.eichenber...@honeywell.com> said:

John.Eichenberger> Honeywell Internal
John.Eichenberger>
John.Eichenberger> I think I have an answer for why this commit needed to be 
reverted:
John.Eichenberger>
John.Eichenberger> Author: Dr. Stephen Henson <st...@openssl.org> 
John.Eichenberger> Author date: 2 years ago (12/20/2015 10:18:43 AM) 
John.Eichenberger> Commit date: 2 years ago (12/20/2015 11:27:03 AM) 
John.Eichenberger> Commit hash: 6656ba7152dfe4bba865e327dd362ea08544aa80
John.Eichenberger> Children: 1c7de36f62
John.Eichenberger> Parent(s): 17592f323a John.Eichenberger> John.Eichenberger> 
Don't check RSA_FLAG_SIGN_VER.
John.Eichenberger>
John.Eichenberger> Reviewed-by: Richard Levitte <levi...@openssl.org> 
John.Eichenberger> John.Eichenberger> The change made in that commit was to 
simply remove John.Eichenberger> the attempt to check for the RSA_FLAG_SIGN_VER 
flag.
John.Eichenberger> But that's not what is wrong with this code that 
John.Eichenberger> required changing. The change should be to add 
John.Eichenberger> "meth" prior to flags:

Well, not quite, actually.  We can easily study the code prior to this change 
by looking at the 1.0.2 source.

1. in RSA_new_method(), which is used to create new instances of the
   RSA structure, there's this line:

ret->flags = ret->meth->flags & ~RSA_FLAG_NON_FIPS_ALLOW;

   So that makes the check of rsa->flags valid, no need to go via
   rsa->meth

2. In rsa.h (crypto/rsa/rsa.h in 1.0.2), you'll find this comment in
   the middle of the definition of rsa_meth_st

/*
 * New sign and verify functions: some libraries don't allow arbitrary
 * data to be signed/verified: this allows them to be used. Note: for
 * this to work the RSA_public_decrypt() and RSA_private_encrypt() should
 * *NOT* be used RSA_sign(), RSA_verify() should be used instead. Note:
 * for backwards compatibility this functionality is only enabled if the
 * RSA_FLAG_SIGN_VER option is set in 'flags'.
 */

   Do note the note on backward compatibility...  you see, there were
   versions of OpenSSL where the fields 'rsa_sign' and 'rsa_verify'
   didn't exist (they appeared in OpenSSL 0.9.5), so for the sake of
   allowing older applications to work with the newer OpenSSL without
   recompilation, we required all new RSA method implementations to
   use that flag to have the 'rsa_sign' and 'rsa_verify' functions
   used.  Without that flag, those functions were assumed not to
   exist, that the RSA method structure was pre-0.9.5.  However, this
   was somewhere in 2000.

   Fast forward to 2015, when we were starting to make certain types
   opaque, and someone noticed this flag still hanging around, and we
   figured that 0.9.5 is long gone, and 1.0.1 was a year away from its
   end of life, and we figured that the reason to have this flag at
   all was a matter of years long past, it was time to simply drop its
   use.  It had grown to become irrelevant a long time ago.

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
--
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

[openssl-users] Correct the check of RSA_FLAG_SIGN_VER

[Eichenberger, John]

Honeywell Internal

I think I have an answer for why this commit needed to be reverted:
Author:Dr. Stephen Henson 
Author date:  2 years ago (12/20/2015 10:18:43 AM)
Commit date:2 years ago (12/20/2015 11:27:03 AM)
Commit hash:6656ba7152dfe4bba865e327dd362ea08544aa80
Children:  1c7de36f62
Parent(s):17592f323a

Don't check RSA_FLAG_SIGN_VER.

Reviewed-by: Richard Levitte 

The change made in that commit was to simply remove the attempt to check for 
the RSA_FLAG_SIGN_VER flag. But that’s not what is wrong with this code that 
required changing.
The change should be to add “meth” prior to flags:

@@ -84,7 +89,7 @@ int RSA_sign(int type, const unsigned char *m, unsigned int 
m_len,
 return 0;
 }
#endif
-if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_sign) {
+if ((rsa->meth->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_sign) {
 return rsa->meth->rsa_sign(type, m, m_len, sigret, siglen, rsa);
 }
 /* Special case: SSL signature, just check the length */
@@ -293,7 +298,7 @@ int RSA_verify(int dtype, const unsigned char *m, unsigned 
int m_len,
const unsigned char *sigbuf, unsigned int siglen, RSA *rsa)
{

-if ((rsa->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_verify) {
+if ((rsa->meth->flags & RSA_FLAG_SIGN_VER) && rsa->meth->rsa_verify) {
 return rsa->meth->rsa_verify(dtype, m, m_len, sigbuf, siglen, rsa);
 }

--

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] Can I rename the OpenSSL shared objects for FIPS?

[Eichenberger, John]

I actually submitted a patch set that renames library files during the build 
process once upon a time... but it was summarily rejected without any real 
attention paid to it.  My change was specific to building dynamic libraries for 
Windows/WinCE... but the same idea would apply to other target builds I think.  
One has to get into the perl scripts to make it happen.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Perrow, Graeme
Sent: Thursday, January 12, 2017 12:10 PM
To: openssl-users@openssl.org
Subject: [openssl-users] Can I rename the OpenSSL shared objects for FIPS?

We are shipping OpenSSL (1.0.2j)  shared objects built with FIPS, which are 
automatically loaded when the application starts. But if our software directory 
is in the path (or LD_LIBRARY_PATH or platform equivalent) earlier than the 
system directories, then other applications that load OpenSSL dynamically (eg. 
ssh on some systems) could use our libraries rather than the system ones. This 
is not a huge deal except that we may want to disable certain algorithms that 
we don't use, and we don't want to break system utilities that do use them.

We would like to avoid this by renaming these libraries, i.e. 
libMYcrypto.so.1.0.0 and libMYssl.so.1.0.0, and then we'll know that only our 
application would load them. Simply renaming the files is obviously no good, 
and I've found that renaming them before linking with them does not work either.

It would seem that the names "libcrypto" and "libssl" are hard-coded in a 
million places within Makefiles and scripts and such. Is there a way to solve 
this problem? This would apply to Linux, HP-UX, and Solaris.

Thanks
Graeme Perrow

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k

[Eichenberger, John]

Yes.  The build methods were kept constant at first as I tried to upgrade.  
Currently I am using STANDARDSDK_500 to build for CE50_ARMV4I, or at least that 
is the build target that was tested.  We also build for many other target 
platforms as well, I haven't tested any of them yet.  Details could probably be 
provided if that is of any use.  We use Ant/Ivy and Jenkins in our build 
system.  But most of the builds I performed locally without much of those 
details involved.  Batch files get launched that set up the details of the 
build.  Slight modifications have been made to the Perl scripts to enhance the 
product.  For example, the standard scripts avoid the use of resource files for 
/CE/ builds.  I not only use resource files, but improve the content of those 
files to indicate our build version together with the OpenSSL version tag that 
it is based upon.  We also support FIPS so the resource file can indicate which 
builds are FIPS compatible and which ones are not.

Ultimately I built all of the following versions:
* 1.0.1g -- legacy version that has been working for years
* 1.0.1t -- built without error, failed to authenticate any 802.1x protocol 
such as PEAP with our WPA supplicant.
* 1.0.2h -- built without error even easier than 1.0.1t, failed to authenticate 
any 802.1x protocol such as PEAP with our WPA supplicant.
* 1.0.1n -- failed the same as the others that failed
* 1.0.1i -- works the same as 1.0.1g
* 1.0.1l -- failed the same as the others that failed
* 1.0.1k -- failed to compile until I ported a one-line fix from a later 
version, then  built okay but failed to function correctly
* 1.0.1j -- works

* I tediously sliced up the differences between 1.0.1j and 1.0.1k to discover 
first the file and then the minimum set of changes required to reproduce 
failures.
* Have since then ported that conditional to our 1.0.2j build.  It works and 
that gets us to where we need to be right now.  I realize that the conditional 
I used may be overkill.  But working is good enough for the company.  Even it 
if it not good enough for the open source community.

I further pursued the differences between working and not working, but haven't 
been able to reproduce failure apart from a full OpenSSL build.  In other 
words, in a small test program both methods for computing constant_time_msb 
worked fine.  The assembly language is slightly different from one another 
since the new method uses a logical shift operation whereas the previous method 
uses an arithmetic shift operation, but never the less I was unable to 
reproduce a compiler error using the same version of Microsoft compiler.  I've 
seen issues like this before where compiler errors depend upon more than just 
the lines in question.  Unfortunately I haven't the time to dedicate to 
determining anything more about this issue since I have a working version that 
meets our needs.

As indicated in the original email, the change to compiler switches neither 
fixed nor broke anything.  I only made that change after all of the tests 
above, as an attempt to see if I could forgo changing source code altogether.   
I prefer using the same optimization switches used for Win32 builds so I left 
that change in even though it did not fix the compiler bug.

So ultimately this email is about reporting an issue that perhaps deserves 
nothing more than a comment in source code, I don't know.  I can keep an eye on 
this issue and report any further developments as they are discovered.  But it 
will likely be a long time before we need to revisit work on OpenSSL.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Jakob Bohm
Sent: Monday, November 21, 2016 11:49 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since 
OpenSSL version 1.0.1k

On 21/11/2016 19:52, Eichenberger, John wrote:
>
> I am building both OpenSSL and WPA Supplicant for use on a Windows 
> Mobile 6.5 platform.
>
> The WPA Supplicant version in use is based upon the hostap_2_0 tag 
> from http://w1.fi/hostap.git.
>
> The version of OpenSSL that we have been using until now is based upon 
> the OpenSSL_1_0_1g from https://github.com/openssl/openssl
>
> I can upgrade to OpenSSL_1_0_1j and still succeed.  But when I merge 
> changes from OpenSSL_1_0_1k, all 802.1x authentication fails.
>
> I narrowed this problem down to a single line in 
> crypto/constant_time_locl.h.  Attached is the patch set that I applied 
> to resolve this issue for me.
>
> It is a confusing issue because I can compile that same bit of code in 
> Visual Studio within a different trivial application and see that 
> although the two methods for that bit of code produce slightly 
> different assembly language, both should produce the sam

Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k

[Eichenberger, John]

Possibly.  I haven't scoped it any further than the fact that it fails for my 
build, which happens to use VS 2008.
I am ill equipped to swap in different compiler versions and try again.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507

-Original Message-
From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Salz, Rich
Sent: Monday, November 21, 2016 1:38 PM
To: openssl-users@openssl.org
Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since 
OpenSSL version 1.0.1k

Shouldn't you check for VS 2008 as well as MSC_VER ?

-- 
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

[openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k

[Eichenberger, John]

I am building both OpenSSL and WPA Supplicant for use on a Windows Mobile 6.5 
platform.
The WPA Supplicant version in use is based upon the hostap_2_0 tag from 
http://w1.fi/hostap.git.
The version of OpenSSL that we have been using until now is based upon the 
OpenSSL_1_0_1g from https://github.com/openssl/openssl
I can upgrade to OpenSSL_1_0_1j and still succeed.  But when I merge changes 
from OpenSSL_1_0_1k, all 802.1x authentication fails.

I narrowed this problem down to a single line in crypto/constant_time_locl.h.  
Attached is the patch set that I applied to resolve this issue for me.
It is a confusing issue because I can compile that same bit of code in Visual 
Studio within a different trivial application and see that although the two 
methods for that bit of code produce slightly different assembly language, both 
should produce the same result.  And for that trivial application they do!  So 
why this difference breaks authentication for me when it is all thrown together 
makes no sense.

In my patch set you can see that I also changed what compiler switches are used 
for the WinCE target.  That change did not appear to fix or break anything.

-Ike-
  John Eichenberger
Intermec by Honeywell
Principal Engineer: Sustaining Engineering
425.921.4507



0001-Avoid-the-VS-2008-compiler-bug-that-breaks-1.0.1k-th.patch
Description: 0001-Avoid-the-VS-2008-compiler-bug-that-breaks-1.0.1k-th.patch
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

RE: BUILD OPENSSL in WIN CE 6.0

[Eichenberger, John]

Have you checked out this on the wiki yet?
http://wiki.openssl.org/index.php/FIPS_Library_and_Windows_Mobile_6#Troubleshooting_OpenSSL_builds_for_WM6


-Ike- 
John Eichenberger 
Principal Engineer: Sustaining Engineering: Intermec by Honeywell
425.265.2108  john.eichenber...@intermec.com 

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of RaviVyas
Sent: Thursday, May 15, 2014 6:23 AM
To: openssl-users@openssl.org
Subject: BUILD OPENSSL in WIN CE 6.0

Hello,
Please Help Me To Build OPENSSL on WIN CE 6.0.
I Followed Steps Which are mentioned in INSTALL.WCE Text File.
But Didnt Successed.




--
View this message in context: 
http://openssl.6102.n7.nabble.com/BUILD-OPENSSL-in-WIN-CE-6-0-tp50152.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

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

I've tried several times to subscribe to openssl-...@openssl.org with no success

[Eichenberger, John]

Who can I contact to work through what is going wrong with my request?

-Ike-
John Eichenberger
Principal Engineer: Sustaining Engineering: Intermec by Honeywell
425.265.2108  john.eichenber...@intermec.com

---BeginMessage---
subscribe openssl-dev   john.eichenber...@intermec.com



-Ike-
John Eichenberger
Principal Engineer: Sustaining Engineering: Intermec by Honeywell
425.265.2108  john.eichenber...@intermec.com




This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

---End Message---

RE: OpenSSL v.1.0.1e and MSVC 2013

[Eichenberger, John]

I have been using VS2008, but I have seen the same errors.  Some of the things 
I have done to work around them include:
1. Using a version of wcecompat based upon 
http://www.ohloh.net/p/mauriceks_wcecompat/
2. Pull a few select files from OpenSSL tips to the 1.0.1e branch that I am 
working on.  Including:
   * crypto/bio/bss_fd.c
   * crypto/cryptlib.c
   * crypto/o_str.c
   * e_os.h
   * e_capi.c
   * util/pl/VC-32.pl - I also had to modify this a little to fit our build 
process
  
With the exception of the perl script I've not had to change any openssl source 
files.

-Ike- 
John Eichenberger 
Principal Engineer: Sustaining Engineering: Intermec
425.265.2108  john.eichenber...@intermec.com 

-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Dave Thompson
Sent: Saturday, November 16, 2013 5:37 PM
To: openssl-users@openssl.org
Subject: RE: OpenSSL v.1.0.1e and MSVC 2013

 From: owner-openssl-users On Behalf Of Igor Mironchik
 Sent: Saturday, November 16, 2013 05:09

 I'm trying to compile OpenSSL with MSVC 2013.
 
 First error was that strings.h include file wasn't found, and I 
 comment the next line in crypto/o_str.c
 
 #if !defined(OPENSSL_IMPLEMENTS_strncasecmp)  \
  !defined(OPENSSL_SYSNAME_WIN32)  \
  !defined(NETWARE_CLIB)
 // # include strings.h
 #endif
 
Are you sure you configured correctly? I haven't done 1.0.1e yet, but all 
versions I have built with MSVC define OPENSSL_SYSNAME_WIN32 as one would 
expect, which causes that #if to be skipped.


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

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

RE: Experimental multi-implementation support for FIPS capable OpenSSL

[Eichenberger, John]

I came up with a very simple set of changes to VC-32.pl, mkdef.pl, and 
do_ms.bat that makes it possible to add a prefix to the names used to create 
the libeay and ssleay outputs.  But I'm new here and not sure what procedure to 
follow to share those changes.  Please advise.

With my changes in place the build only uses new names if an environment 
variable is set prior to performing the build.

-Ike- 
John Eichenberger 
Principal Engineer: Sustaining Engineering: Intermec
425.265.2108  john.eichenber...@intermec.com 


-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Vuille, Martin (Martin)
Sent: Tuesday, November 05, 2013 11:04 AM
To: openssl-users@openssl.org
Subject: RE: Experimental multi-implementation support for FIPS capable OpenSSL

On Tue, Nov 5, 2013, Dr. Stephen Henson wrote:

 On Tue, Nov 05, 2013, Vuille, Martin (Martin) wrote:
 
  Hi,
 
  I have some questions about this change:
 
 
 http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=1dded7f7e8e9f7
  37ef9d7e3c3ef165a78fd7fa1d
 
  I am interested in using this functionality and wondering whether it 
  would be feasible and reasonably safe for me to back-port it on top 
  of
 1.0.1e?
 
 
 You can backport it to 1.0.1e but it will never be officially part of 
 the
 1.0.1 release as it includes new features. The first version of 
 OpenSSL it will appear in in 1.0.2.
 
  What is it about this change that makes it experimental?
 
 
 It hasn't been widely tested and the tecnique of having mutiple 
 implementations of the same algorithm in EVP hasn't been used in 
 OpenSSL before. In 1.0.1 the more cautious approach of not having 
 non-FIPS EVP implementations was taken instead.
 

Another approach I am considering is to have both a FIPS-capable and non-FIPS 
capable version of OpenSSL installed on the system (with suitable adjustments 
to .so file names to avoid conflicts) with the application using the former 
when FIPS mode is required and the latter otherwise (perhaps by dynamically 
loading the appropriate one, or by using a different LD_LIBRARY_PATH).

Any thoughts on the viability of that approach?

MV

__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

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

RE: OpenSSL, Windows, Perl

[Eichenberger, John]

Perl is simply used to configure the makefiles that build openssl.

-Ike-
John Eichenberger
Principal Engineer: Sustaining Engineering: Intermec
425.265.2108  john.eichenber...@intermec.com
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] 
On Behalf Of Michael Mueller
Sent: Friday, October 25, 2013 11:50 AM
To: openssl-users@openssl.org
Subject: OpenSSL, Windows, Perl

Happy Linux OpenSSL user here. Moving to Windowsville. Haven't been there in 
over a decade. Read INSTALL.W32 and INSTALL.W64. Read Configure. Read 
crypto/asm/*.pl. Clearly Perl is needed to compile openssl with Visual Studio - 
which we will be using.

Does OpenSSL need Perl at runtime?

Thanks,
Mike

This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

How does one use fipstests.sh to generate scripts for use with Windows CE [OpenSSL FIPS]

[Eichenberger, John]

I see that there is a -win32 command line value.  But I would have thought 
that should not necessarily be the same as what one uses for Windows-CE.
I've tried a few thing at random, I was hoping for someone who had done this 
before to show me the way?

-Ike-
John Eichenberger
Principal Engineer: Sustaining Engineering: Intermec
425.265.2108  john.eichenber...@intermec.com


This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

How does privatekey ever get defined?

[Eichenberger, John]

I have been looking at OpenSSL version 1.0.0a source code in order to
determine how to use it in an application where EAP TLS is used.  It
seems like this application would be working correctly if only the
privatekey field would be defined as it gets checked within
ssl3_send_client_certificate (ssl\s3_clnt.c).  

 

Specifically, in this sequence of code, the privatekey field is NULL
whenever this procedure executes.

  if (s-state ==   SSL3_ST_CW_CERT_A)
{
if ((s-cert == NULL) ||
  (s-cert-key-x509 == NULL) ||
  (s-cert-key-privatekey == NULL))
{



But in scanning through the OpenSSL code, I an unable to find any code
that ever defines that privatekey value.  What am I missing?

-Ike- 
John Eichenberger 
Principal Engineer, Sustaining Engineering 
Intermec 
tel: 425.265.2108 
fax: 425.348.2661
john.eichenber...@intermec.com 

 


This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

RE: How does privatekey ever get defined?

[Eichenberger, John]

I am planning on adding code to call SSL_CTX_use_PrivateKey.  I do not
have a key file to supply, so I cannot use SSL_CTX_use_PrivateKey_file.

However, I thought I would ask about this because I've reviewed the code
for both of those procedures and still see no place where the privatekey
member variable would be defined.  So it seems like a useless endeavor.


Again... what am I missing?  Where does that member get defined?

-Ike- 
John Eichenberger 
Principal Engineer, Sustaining Engineering 
Intermec 
tel: 425.265.2108 
fax: 425.348.2661
john.eichenber...@intermec.com 


-Original Message-
From: owner-openssl-us...@openssl.org
[mailto:owner-openssl-us...@openssl.org] On Behalf Of Victor Duchovni
Sent: Monday, November 01, 2010 11:28 AM
To: openssl-users@openssl.org
Subject: Re: How does privatekey ever get defined?

On Mon, Nov 01, 2010 at 01:06:50PM -0500, Eichenberger, John wrote:

 I have been looking at OpenSSL version 1.0.0a source code in order to
 determine how to use it in an application where EAP TLS is used.  It
 seems like this application would be working correctly if only the
 privatekey field would be defined as it gets checked within
 ssl3_send_client_certificate (ssl\s3_clnt.c).  

To associate a private key + public key cert (chain) pair with
an SSL context:

if (SSL_CTX_use_certificate_chain_file(ctx, cert_file) = 0) {
/* handle the error */
}
if (SSL_CTX_use_PrivateKey_file(ctx, key_file, SSL_FILETYPE_PEM) =
0) {
/* handle the error */
}

You can associate one key pair for each public key type, currently:

- RSA
- DSA
- ECDSA

If you need to support SNI on the server-side, there are some additional
games with personality-specific SSL contexts that are dynamically
assigned
to the session based on SNI requests from the client.

-- 
Viktor.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager   majord...@openssl.org
This message is intended only for the named recipient. If you are not the 
intended recipient, you are notified that disclosing, copying, distributing or 
taking any action based on the contents of this information is strictly 
prohibited.

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