From kgoldman at us.ibm.com  Sun Jan  1 00:11:07 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Sat, 31 Dec 2016 19:11:07 -0500
Subject: [openssl-users] Raw EC key to EVP_PKEY to certificate
In-Reply-To: <719641EC-99FC-46D8-B84C-927EF0F0D880@dukhovni.org>
References: <o4714s$l1i$1@blaine.gmane.org>
 <719641EC-99FC-46D8-B84C-927EF0F0D880@dukhovni.org>
Message-ID: <o49hef$crl$1@blaine.gmane.org>

Perfect, thanks.

On 12/30/2016 8:27 PM, Viktor Dukhovni wrote:
>
>> On Dec 30, 2016, at 8:20 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
>>
>> - EC_KEY ecKey = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1)
>> - convert x and y from bin to bignum
>> - EC_KEY_set_public_key_affine_coordinates(ecKey, x, y)
>> - EVP_PUBKEY evpPubkey = EVP_PKEY_new()
>> - EVP_PKEY_set1_EC_KEY(evpPubkey, ecKey);
>> - X509_set_pubkey(x509Certificate, evpPubkey);
>
> Start with:
>
> 	EC_KEY *eckey = EC_KEY_new();
> 	EC_GROUP *group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1);
> 	EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE);
>         EC_KEY_set_group(eckey, group);
> 	...
>



From Michal.Trojnara at stunnel.org  Sun Jan  1 22:43:31 2017
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Sun, 1 Jan 2017 23:43:31 +0100
Subject: [openssl-users] stunnel 5.39 released
Message-ID: <e79577fd-6166-9839-26c6-d5acbe9323a5@stunnel.org>

Dear Users,

I have released version 5.39 of stunnel.

Version 5.39, 2017.01.01, urgency: LOW
* New features
  - PKCS#11 engine (pkcs11.dll) added to the Win32 build.
  - Per-destination TLS session cache added for the client mode.
  - The new "logId" parameter "process" added to log PID values.
  - Added support for the new SSL_set_options() values.
  - Updated the manual page.
  - Obsolete references to "SSL" replaced with "TLS".
* Bugfixes
  - Fixed "logId" parameter to also work in inetd mode.
  - "delay = yes" properly enforces "failover = prio".
  - Fixed fd_set allocation size on Win64.
  - Fixed reloading invalid configuration file on Win32.
  - Fixed resolving addresses with unconfigured network interfaces.

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
288c087a50465390d05508068ac76c8418a21fae7275febcc63f041ec5b04dee
stunnel-5.39.tar.gz
2acacc912d87c4fc8506e70d00ac514526ee80d1996bdf0a56f00383e43a49a9
stunnel-5.39-win32-installer.exe
0a1a5e4c3c30067d9d07f27cd55a2f7d59359770ed751384e374a79cdae57913
stunnel-5.39-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170101/2111cbec/attachment.sig>

From shashank.a at innoviti.com  Mon Jan  2 07:32:25 2017
From: shashank.a at innoviti.com (shashank.a -)
Date: Mon, 2 Jan 2017 13:02:25 +0530
Subject: [openssl-users] TLS v1.1 and v1.2 support in windows XP
Message-ID: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>

Hi,
Please educate me whether TLS v1.1,v1.2 can be supported in windows XP or
not.

Thanks & Regards

Shashank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170102/7877fbae/attachment.html>

From matt at openssl.org  Mon Jan  2 09:50:04 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 2 Jan 2017 09:50:04 +0000
Subject: [openssl-users] TLS v1.1 and v1.2 support in windows XP
In-Reply-To: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
References: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
Message-ID: <fd38158d-bd1f-74eb-c7db-93b94379aa41@openssl.org>



On 02/01/17 07:32, shashank.a - wrote:
> Hi,
> Please educate me whether TLS v1.1,v1.2 can be supported in windows XP
> or not.

As a dev team we don't regularly test on Windows XP (and I don't have
any access at all), but AFAIK it should work for all current OpenSSL
versions.

Matt

From jb-openssl at wisemo.com  Mon Jan  2 10:17:01 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 2 Jan 2017 11:17:01 +0100
Subject: [openssl-users] TLS v1.1 and v1.2 support in windows XP
In-Reply-To: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
References: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
Message-ID: <8bff4293-6429-91be-2648-07a05f0427ba@wisemo.com>

On 02/01/2017 08:32, shashank.a - wrote:
> Hi,
> Please educate me whether TLS v1.1,v1.2 can be supported in windows XP 
> or not.
As for TLS versions in programs that use OpenSSL, this does not
depend on the OS, only on the OpenSSL library version (and possibly
if the program has explicitly told OpenSSL to turn it off).

As for TLS versions in Windows XPs built in programs (such as Internet
Explorer, IIS, "Outlook express", the WinHttp library etc.), this may
depend on the service pack level, but I guess there is simply no support
for TLSv1.1 or later.

Thus OpenSSL based programs (on any OS) needing to talk to native XP
programs will probably have to keep TLSv1.0 (and even SSL 3.0 !) at
least partially enabled until other people stop using XP.

It would be really useful if somebody maintained a public databases of
the SSL/TLS support in various current and old systems, including some
recommended ways to cater to old systems without significantly
weakening security when talking to modern systems.

It can be quite difficult doing this on your own (I try), especially
as publishers of "best practice" configuration guides and tests
completely ignore this, often making draconian rules that won't work
for those needing backwards compatibility with systems that can't easily
be upgraded.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From shashank.a at innoviti.com  Mon Jan  2 10:21:29 2017
From: shashank.a at innoviti.com (shashank.a -)
Date: Mon, 2 Jan 2017 15:51:29 +0530
Subject: [openssl-users] TLS v1.1 and v1.2 support in windows XP
In-Reply-To: <fd38158d-bd1f-74eb-c7db-93b94379aa41@openssl.org>
References: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
 <fd38158d-bd1f-74eb-c7db-93b94379aa41@openssl.org>
Message-ID: <CAMFWc+YyeP7e8orUzKdAPuoPG9nQrg39QmGN8Au9AN4Fv9nAJg@mail.gmail.com>

Hi Matt,
Thanks for the update.
Please guide me on how to build openssl library for windows XP,since
currently we have pre-compiled library for windows 7 only.

Thanks & Regards

Shashank

Innoviti Payment Solutions Pvt. Ltd.

*Mobile : +91-9008802335*



On Mon, Jan 2, 2017 at 3:20 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 02/01/17 07:32, shashank.a - wrote:
> > Hi,
> > Please educate me whether TLS v1.1,v1.2 can be supported in windows XP
> > or not.
>
> As a dev team we don't regularly test on Windows XP (and I don't have
> any access at all), but AFAIK it should work for all current OpenSSL
> versions.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170102/2f3f6ae5/attachment-0001.html>

From matt at openssl.org  Mon Jan  2 10:35:28 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 2 Jan 2017 10:35:28 +0000
Subject: [openssl-users] TLS v1.1 and v1.2 support in windows XP
In-Reply-To: <CAMFWc+YyeP7e8orUzKdAPuoPG9nQrg39QmGN8Au9AN4Fv9nAJg@mail.gmail.com>
References: <CAMFWc+aFvf-yDEkYHnhPjoBezMgq92znF8UX76ZmFSWk71q+wQ@mail.gmail.com>
 <fd38158d-bd1f-74eb-c7db-93b94379aa41@openssl.org>
 <CAMFWc+YyeP7e8orUzKdAPuoPG9nQrg39QmGN8Au9AN4Fv9nAJg@mail.gmail.com>
Message-ID: <376ccb20-501a-517b-e716-053058c10837@openssl.org>



On 02/01/17 10:21, shashank.a - wrote:
> Hi Matt,
> Thanks for the update.
> Please guide me on how to build openssl library for windows XP,since
> currently we have pre-compiled library for windows 7 only.

Decide whether you need version 1.0.2 or 1.1.0 (1.1.0 is the latest but
is not fully source compatible with the 1.0.x releases). Download the
source from here:

https://www.openssl.org/source

Unpack the file and follow the instructions in:

- INSTALL and NOTES.WIN if using version 1.1.0
- INSTALL.W32 if using version 1.0.2

Matt

> 
> Thanks & Regards
> 
> Shashank
> 
> Innoviti Payment Solutions Pvt. Ltd.
> 
> */Mobile : +91-9008802335/*
> 
> */ /*
> 
> 
> On Mon, Jan 2, 2017 at 3:20 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 02/01/17 07:32, shashank.a - wrote:
>     > Hi,
>     > Please educate me whether TLS v1.1,v1.2 can be supported in windows XP
>     > or not.
> 
>     As a dev team we don't regularly test on Windows XP (and I don't have
>     any access at all), but AFAIK it should work for all current OpenSSL
>     versions.
> 
>     Matt
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 

From rjkmurray40 at gmail.com  Tue Jan  3 17:52:53 2017
From: rjkmurray40 at gmail.com (rjkmurray40)
Date: Tue, 03 Jan 2017 14:22:53 -0330
Subject: [openssl-users] Open ssl user
Message-ID: <5b9mm62e4o4cr2i1g2prh57p.1483465973795@email.android.com>

Not able to use ssl


Sent from my Bell Samsung device over Canada's largest network.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170103/8f92a204/attachment.html>

From kgoldman at us.ibm.com  Tue Jan  3 18:41:34 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Tue, 3 Jan 2017 13:41:34 -0500
Subject: [openssl-users] EVP_DigestVerifyFinal with ECDSA signature
Message-ID: <o4gr8q$1c8$1@blaine.gmane.org>

I'm trying to use the EVP interface for signature verification.

However, EVP_DigestVerifyFinal() takes a signature and length as 
parameters.  While I understand this for RSA, ECDSA signatures have R 
and S elements.

Is there a convertor function?

If I must convert by hand, how is it done?  In certificates, I see a 
0x04 followed by R and S arrays.


From kgoldman at us.ibm.com  Tue Jan  3 19:55:35 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Tue, 3 Jan 2017 14:55:35 -0500
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
Message-ID: <o4gvji$s1h$1@blaine.gmane.org>

1 - Is this a bit of a bug?

ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure 
itself.  However, ECDSA_SIG_new() doesn't set r and s to
NULL.  It calls zalloc, which sets them to 0x00 bytes.

OK, in most platforms, the NULL pointer is an all 0x00 bytes value, but 
it's not guaranteed by the C standard.

E.g., http://c-faq.com/null/confusion4.html


2 - It would be nice if the man page advised that ECDSA_SIG_free() frees 
the two r and s BIGNUMs before is frees the structure iteslf


From openssl-users at dukhovni.org  Tue Jan  3 20:26:56 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 3 Jan 2017 15:26:56 -0500
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <o4gvji$s1h$1@blaine.gmane.org>
References: <o4gvji$s1h$1@blaine.gmane.org>
Message-ID: <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>


> On Jan 3, 2017, at 2:55 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
> 
> 1 - Is this a bit of a bug?
> 
> ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure itself.  However, ECDSA_SIG_new() doesn't set r and s to
> NULL.  It calls zalloc, which sets them to 0x00 bytes.
> 
> OK, in most platforms, the NULL pointer is an all 0x00 bytes value, but it's not guaranteed by the C standard.
> 
> E.g., http://c-faq.com/null/confusion4.html

OpenSSL does not support platforms where the memory representation of the
NULL pointer contains non-zero bytes. IIRC there are even tests for this.

> 2 - It would be nice if the man page advised that ECDSA_SIG_free() frees the two r and s BIGNUMs before is frees the structure itself.

Presumably the structure "owns" its R and S values.  If this needs
to be documented, that documentation should be in the "setter"
functions that take control of the values.

-- 
	Viktor.


From rsalz at akamai.com  Tue Jan  3 21:35:22 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Jan 2017 21:35:22 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
Message-ID: <d7c158c370984f4e87cfedd4c914442e@usma1ex-dag1mb1.msg.corp.akamai.com>

> OpenSSL does not support platforms where the memory representation of
> the NULL pointer contains non-zero bytes. IIRC there are even tests for this.

Yes, the basic platform sanity tests, test/sanitytest.c

From rajat.srivastava01 at nagarro.com  Wed Jan  4 11:14:48 2017
From: rajat.srivastava01 at nagarro.com (Rajat Srivastava)
Date: Wed, 4 Jan 2017 11:14:48 +0000
Subject: [openssl-users] Unable to build with dmake
Message-ID: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>

Hi,



I am working on windows 7 Professional Service Pack 1

I downloaded OpenSSL version openssl-1.1.0c and installed Active Perl v5.24.0 built for MSWin32-x64-multi-thread

I installed Text::Template, dmake and MinGW (not sure if I should have installed MinGW)

I ran command "perl configure VC-WIN32" which ran successfully.



When I run dmake command it says:

"dmake.exe:  makefile:  line 51:  Error: -- Expecting macro or rule defn, found neither"



Line 51 in make file is:

!IF "$(DESTDIR)" != ""



Please let me know how to resolve this error.



Regards,

Rajat Srivastava


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170104/9218db10/attachment-0001.html>

From levitte at openssl.org  Wed Jan  4 13:09:21 2017
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 04 Jan 2017 14:09:21 +0100 (CET)
Subject: [openssl-users] Unable to build with dmake
In-Reply-To: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
References: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
Message-ID: <20170104.140921.681589687279987359.levitte@openssl.org>

In message <TY1PR06MB0942DC7B7183B1872BD8D9469E610 at TY1PR06MB0942.apcprd06.prod.outlook.com> on Wed, 4 Jan 2017 11:14:48 +0000, Rajat Srivastava <rajat.srivastava01 at nagarro.com> said:

rajat.srivastava01> Hi,
rajat.srivastava01> 
rajat.srivastava01> I am working on windows 7 Professional Service Pack 1
rajat.srivastava01> 
rajat.srivastava01> I downloaded OpenSSL version openssl-1.1.0c and installed Active Perl
rajat.srivastava01> v5.24.0 built for MSWin32-x64-multi-thread
rajat.srivastava01> 
rajat.srivastava01> I installed Text::Template, dmake and MinGW (not sure if I should have
rajat.srivastava01> installed MinGW)
rajat.srivastava01> 
rajat.srivastava01> I ran command "perl configure VC-WIN32" which ran successfully.
rajat.srivastava01> 
rajat.srivastava01> When I run dmake command it says:
rajat.srivastava01> 
rajat.srivastava01> "dmake.exe: makefile: line 51: Error: -- Expecting macro or rule defn,
rajat.srivastava01> found neither"
rajat.srivastava01> 
rajat.srivastava01> Line 51 in make file is:
rajat.srivastava01> 
rajat.srivastava01> !IF "$(DESTDIR)" != ""
rajat.srivastava01> 
rajat.srivastava01> Please let me know how to resolve this error.

Try with nmake, which comes with Visual Studio.

(I now noticed we haven't made nmake a requirement, while we expect
everyone to use it with the VC-* config targets.  We should be more
explicit about this)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From Michael.Wojcik at microfocus.com  Wed Jan  4 13:31:26 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 4 Jan 2017 13:31:26 +0000
Subject: [openssl-users] Unable to build with dmake
In-Reply-To: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
References: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C40A9D8@prvxmb04.microfocus.com>

Use Microsoft's nmake, not dmake. The VC-WIN32 configuration generates makefiles for use with nmake, which is included with Visual C. You told the OpenSSL build process to configure itself for Visual C (the "VC" part); now you have to use it.

If you want to build OpenSSL using some custom toolchain of your own devising, you'll need to create your own configuration, including all the necessary rules and files. I do not recommend it.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



From bkaduk at akamai.com  Wed Jan  4 18:21:31 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Wed, 4 Jan 2017 12:21:31 -0600
Subject: [openssl-users] Unable to build with dmake
In-Reply-To: <20170104.140921.681589687279987359.levitte@openssl.org>
References: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
 <20170104.140921.681589687279987359.levitte@openssl.org>
Message-ID: <f8764422-40d1-caa7-7b84-73b2fad49528@akamai.com>

On 01/04/2017 07:09 AM, Richard Levitte wrote:
> Try with nmake, which comes with Visual Studio.
>
> (I now noticed we haven't made nmake a requirement, while we expect
> everyone to use it with the VC-* config targets.  We should be more
> explicit about this)
>

Interestingly, having recently configured 1.1.0c on a windows system,
something printed out a warning to the effect of "you seem to not have
nmake.exe on your path; you probably want to install it or dmake to
continue" (even though nmake was usable from that cmd.exe prompt!). 
Searching, though, it seems that this is an artifact of some upstream
perl module rather than Configure itself, so it's unclear how reliably
we can prevent it from appearing or modify it to match our requirements
more closely.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170104/52678fea/attachment.html>

From dheinz at softwarekey.com  Wed Jan  4 23:11:27 2017
From: dheinz at softwarekey.com (Dan Heinz)
Date: Wed, 4 Jan 2017 23:11:27 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not unload
	on win32
Message-ID: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>

Using openssl 1.1.0c.
I have a test application that is a win32 console app that calls a win32 DLL which has the openssl libraries linked in statically.
The test applications uses late-binding to the DLL and calls LoadLibrary for the DLL, one test function in the DLL, and then FreeLibrary on the DLL.

The test function in the DLL does the following:
RSA *rsa = NULL;
rsa = RSA_new();
RSA_free(rsa);
OPENSSL_thread_stop();
OPENSSL_cleanup();
return 0;

When FreeLibrary is called on the DLL, dllmain in never called with any messages.  A subsequent call to LoadLibrary also fails to call dllmain and when the test function is called RSA_new() fails.  This leads me to believe the DLL is never freed.

I have tried building openssl with and without no-threads with the same results.  My build parameters are:
perl Configure %TEMP_ARCHITECTURE% --prefix=%RootPath_ThirdParty%\%OPENSSL_VERSION% -DPURIFY -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm  no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp

What am I missing?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170104/f1ac973d/attachment.html>

From matt at openssl.org  Thu Jan  5 10:53:45 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 5 Jan 2017 10:53:45 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
Message-ID: <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>



On 04/01/17 23:11, Dan Heinz wrote:
> Using openssl 1.1.0c. 
> 
> I have a test application that is a win32 console app that calls a win32
> DLL which has the openssl libraries linked in statically.
> 
> The test applications uses late-binding to the DLL and calls LoadLibrary
> for the DLL, one test function in the DLL, and then FreeLibrary on the DLL.
> 
>  
> 
> The test function in the DLL does the following:
> 
> RSA*rsa = NULL;
> 
> rsa = RSA_new();
> 
> RSA_free(rsa);
> 
> OPENSSL_thread_stop();
> 
> OPENSSL_cleanup();
> 
> return0;
> 
> When FreeLibrary is called on the DLL, dllmain in never called with any
> messages.  A subsequent call to LoadLibrary also fails to call dllmain
> and when the test function is called RSA_new() fails.  This leads me to
> believe the DLL is never freed. 
> 
> I have tried building openssl with and without no-threads with the same
> results.  My build parameters are:
> perl Configure *%TEMP_ARCHITECTURE%*
> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY
> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm 
> no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp
> 
> What am I missing?


OpenSSL does its cleanup at *process* exit. Don't call OPENSSL_cleanup()
explicitly - this is discouraged.

>From this manpage:

https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html

"Typically there should be no need to call this function directly as it
is initiated automatically on application exit...<snip>...

Once OPENSSL_cleanup() has been called the library cannot be reinitialised."

This last sentence is the reason why RSA_new() will fail after you have
previously called OPENSSL_cleanup().

Because cleanup happens on process exit, OpenSSL will keep itself in
memory until that time (otherwise crashes will occur because the cleanup
routines have been unloaded).

If you want to dynamically load and unload your DLL then don't
statically link it to OpenSSL - otherwise OpenSSL will keep your DLL
around until process exit too.

Matt

From jb-openssl at wisemo.com  Thu Jan  5 11:17:36 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 5 Jan 2017 12:17:36 +0100
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
Message-ID: <964e71bb-066a-3e71-b66d-6ea2275a8c54@wisemo.com>

On 05/01/2017 11:53, Matt Caswell wrote:
> On 04/01/17 23:11, Dan Heinz wrote:
>> Using openssl 1.1.0c.
>>
>> I have a test application that is a win32 console app that calls a win32
>> DLL which has the openssl libraries linked in statically.
>>
>> The test applications uses late-binding to the DLL and calls LoadLibrary
>> for the DLL, one test function in the DLL, and then FreeLibrary on the DLL.
>>
>>   
>>
>> The test function in the DLL does the following:
>>
>> RSA*rsa = NULL;
>>
>> rsa = RSA_new();
>>
>> RSA_free(rsa);
>>
>> OPENSSL_thread_stop();
>>
>> OPENSSL_cleanup();
>>
>> return0;
>>
>> When FreeLibrary is called on the DLL, dllmain in never called with any
>> messages.  A subsequent call to LoadLibrary also fails to call dllmain
>> and when the test function is called RSA_new() fails.  This leads me to
>> believe the DLL is never freed.
>>
>> I have tried building openssl with and without no-threads with the same
>> results.  My build parameters are:
>> perl Configure *%TEMP_ARCHITECTURE%*
>> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY
>> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm
>> no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp
>>
>> What am I missing?
> OpenSSL does its cleanup at *process* exit. Don't call OPENSSL_cleanup()
> explicitly - this is discouraged.
>
>  From this manpage:
>
> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
>
> "Typically there should be no need to call this function directly as it
> is initiated automatically on application exit...<snip>...
>
> Once OPENSSL_cleanup() has been called the library cannot be reinitialised."
>
> This last sentence is the reason why RSA_new() will fail after you have
> previously called OPENSSL_cleanup().
>
> Because cleanup happens on process exit, OpenSSL will keep itself in
> memory until that time (otherwise crashes will occur because the cleanup
> routines have been unloaded).
>
> If you want to dynamically load and unload your DLL then don't
> statically link it to OpenSSL - otherwise OpenSSL will keep your DLL
> around until process exit too.
>
> Matt
Which is a horribly broken design by the OpenSSL team, especially if
the surrounding process is extremely long-running.  Otherwise, security
updates to OpenSSL will end up requiring system reboots to ensure that
all OpenSSL-using code actually runs the updated OpenSSL libraries.

Someone needs to go back to the drawing board and make OpenSSL
unloadable again.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From levitte at openssl.org  Thu Jan  5 11:29:40 2017
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 05 Jan 2017 12:29:40 +0100 (CET)
Subject: [openssl-users] Unable to build with dmake
In-Reply-To: <f8764422-40d1-caa7-7b84-73b2fad49528@akamai.com>
References: <TY1PR06MB0942DC7B7183B1872BD8D9469E610@TY1PR06MB0942.apcprd06.prod.outlook.com>
 <20170104.140921.681589687279987359.levitte@openssl.org>
 <f8764422-40d1-caa7-7b84-73b2fad49528@akamai.com>
Message-ID: <20170105.122940.1930681473484428707.levitte@openssl.org>

In message <f8764422-40d1-caa7-7b84-73b2fad49528 at akamai.com> on Wed, 4 Jan 2017 12:21:31 -0600, Benjamin Kaduk <bkaduk at akamai.com> said:

bkaduk> Interestingly, having recently configured 1.1.0c on a windows system,
bkaduk> something printed out a warning to the effect of "you seem to not have
bkaduk> nmake.exe on your path; you probably want to install it or dmake to
bkaduk> continue" (even though nmake was usable from that cmd.exe prompt!).
bkaduk> Searching, though, it seems that this is an artifact of some upstream
bkaduk> perl module rather than Configure itself, so it's unclear how reliably
bkaduk> we can prevent it from appearing or modify it to match our
bkaduk> requirements more closely.

Yes, that happens as part of 'use Config;', unfortunately.  I did look
around to try to see how to prevent this from happening, but couldn't
figure it out.

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From dheinz at softwarekey.com  Fri Jan  6 14:36:49 2017
From: dheinz at softwarekey.com (Dan Heinz)
Date: Fri, 6 Jan 2017 14:36:49 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
Message-ID: <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>

>>On 04/01/17 23:11, Dan Heinz wrote:
>> Using openssl 1.1.0c. 
>> 
>> I have a test application that is a win32 console app that calls a 
>> win32 DLL which has the openssl libraries linked in statically.
>> 
>> The test applications uses late-binding to the DLL and calls 
>> LoadLibrary for the DLL, one test function in the DLL, and then FreeLibrary on the DLL.
>> 
>>  
>> 
>> The test function in the DLL does the following:
>> 
>> RSA*rsa = NULL;
>> 
>> rsa = RSA_new();
>> 
>> RSA_free(rsa);
>> 
>> OPENSSL_thread_stop();
>> 
>> OPENSSL_cleanup();
>> 
>> return0;
>> 
>> When FreeLibrary is called on the DLL, dllmain in never called with 
>> any messages.  A subsequent call to LoadLibrary also fails to call 
>> dllmain and when the test function is called RSA_new() fails.  This 
>> leads me to believe the DLL is never freed.
>> 
>> I have tried building openssl with and without no-threads with the 
>> same results.  My build parameters are:
>> perl Configure *%TEMP_ARCHITECTURE%*
>> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY 
>> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads no-asm 
>> no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp
>> 
>> What am I missing?
>
>
>OpenSSL does its cleanup at *process* exit. Don't call OPENSSL_cleanup() explicitly - this is >discouraged.
>
>From this manpage:
>
>https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
>
>"Typically there should be no need to call this function directly as it is initiated >automatically on application exit...<snip>...
>
>Once OPENSSL_cleanup() has been called the library cannot be reinitialised."
>
>This last sentence is the reason why RSA_new() will fail after you have previously called >OPENSSL_cleanup().
>
>Because cleanup happens on process exit, OpenSSL will keep itself in memory until that time >(otherwise crashes will occur because the cleanup routines have been unloaded).
>
>If you want to dynamically load and unload your DLL then don't statically link it to OpenSSL - >otherwise OpenSSL will keep your DLL around until process exit too.
>
>Matt

That is very disappointing.  As a library vendor we have no control over how our users load and unload our libraries.  We will just have to roll back to 1.0.x and wait to see if this will be addressed.  
Also, as Jakob stated in another post, it really seems like this design will be problematic.  

Thanks,
Dan

From matt at openssl.org  Fri Jan  6 14:54:59 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Jan 2017 14:54:59 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
Message-ID: <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>



On 06/01/17 14:36, Dan Heinz wrote:
>>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c.
>>> 
>>> I have a test application that is a win32 console app that calls
>>> a win32 DLL which has the openssl libraries linked in
>>> statically.
>>> 
>>> The test applications uses late-binding to the DLL and calls 
>>> LoadLibrary for the DLL, one test function in the DLL, and then
>>> FreeLibrary on the DLL.
>>> 
>>> 
>>> 
>>> The test function in the DLL does the following:
>>> 
>>> RSA*rsa = NULL;
>>> 
>>> rsa = RSA_new();
>>> 
>>> RSA_free(rsa);
>>> 
>>> OPENSSL_thread_stop();
>>> 
>>> OPENSSL_cleanup();
>>> 
>>> return0;
>>> 
>>> When FreeLibrary is called on the DLL, dllmain in never called
>>> with any messages.  A subsequent call to LoadLibrary also fails
>>> to call dllmain and when the test function is called RSA_new()
>>> fails.  This leads me to believe the DLL is never freed.
>>> 
>>> I have tried building openssl with and without no-threads with
>>> the same results.  My build parameters are: perl Configure
>>> *%TEMP_ARCHITECTURE%* 
>>> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY 
>>> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads
>>> no-asm no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp
>>> 
>>> What am I missing?
>> 
>> 
>> OpenSSL does its cleanup at *process* exit. Don't call
>> OPENSSL_cleanup() explicitly - this is >discouraged.
>> 
>> From this manpage:
>> 
>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
>>
>>
>> 
"Typically there should be no need to call this function directly as it
is initiated >automatically on application exit...<snip>...
>> 
>> Once OPENSSL_cleanup() has been called the library cannot be
>> reinitialised."
>> 
>> This last sentence is the reason why RSA_new() will fail after you
>> have previously called >OPENSSL_cleanup().
>> 
>> Because cleanup happens on process exit, OpenSSL will keep itself
>> in memory until that time >(otherwise crashes will occur because
>> the cleanup routines have been unloaded).
>> 
>> If you want to dynamically load and unload your DLL then don't
>> statically link it to OpenSSL - >otherwise OpenSSL will keep your
>> DLL around until process exit too.
>> 
>> Matt
> 
> That is very disappointing.  As a library vendor we have no control
> over how our users load and unload our libraries.  We will just have
> to roll back to 1.0.x and wait to see if this will be addressed. 
> Also, as Jakob stated in another post, it really seems like this
> design will be problematic.

Can you not link against the OpenSSL DLLs rather than statically link?
That would avoid the problem.

Matt



From rjkmurray40 at gmail.com  Fri Jan  6 15:22:52 2017
From: rjkmurray40 at gmail.com (Ryan Murray)
Date: Fri, 6 Jan 2017 11:52:52 -0330
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
 <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
Message-ID: <CAJJQvo6ODoAGN0L_=AaRQvnrXu9bC6rWTnFRuO5ZWAHQy6ZLXA@mail.gmail.com>

Do you have a moment to edit or review my error

Ryan Murray

On Jan 6, 2017 10:55 AM, "Matt Caswell" <matt at openssl.org> wrote:

>
>
> On 06/01/17 14:36, Dan Heinz wrote:
> >>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c.
> >>>
> >>> I have a test application that is a win32 console app that calls
> >>> a win32 DLL which has the openssl libraries linked in
> >>> statically.
> >>>
> >>> The test applications uses late-binding to the DLL and calls
> >>> LoadLibrary for the DLL, one test function in the DLL, and then
> >>> FreeLibrary on the DLL.
> >>>
> >>>
> >>>
> >>> The test function in the DLL does the following:
> >>>
> >>> RSA*rsa = NULL;
> >>>
> >>> rsa = RSA_new();
> >>>
> >>> RSA_free(rsa);
> >>>
> >>> OPENSSL_thread_stop();
> >>>
> >>> OPENSSL_cleanup();
> >>>
> >>> return0;
> >>>
> >>> When FreeLibrary is called on the DLL, dllmain in never called
> >>> with any messages.  A subsequent call to LoadLibrary also fails
> >>> to call dllmain and when the test function is called RSA_new()
> >>> fails.  This leads me to believe the DLL is never freed.
> >>>
> >>> I have tried building openssl with and without no-threads with
> >>> the same results.  My build parameters are: perl Configure
> >>> *%TEMP_ARCHITECTURE%*
> >>> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY
> >>> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads
> >>> no-asm no-idea no-mdc2 no-rc5  no-ssl3 no-zlib no-comp
> >>>
> >>> What am I missing?
> >>
> >>
> >> OpenSSL does its cleanup at *process* exit. Don't call
> >> OPENSSL_cleanup() explicitly - this is >discouraged.
> >>
> >> From this manpage:
> >>
> >> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
> >>
> >>
> >>
> "Typically there should be no need to call this function directly as it
> is initiated >automatically on application exit...<snip>...
> >>
> >> Once OPENSSL_cleanup() has been called the library cannot be
> >> reinitialised."
> >>
> >> This last sentence is the reason why RSA_new() will fail after you
> >> have previously called >OPENSSL_cleanup().
> >>
> >> Because cleanup happens on process exit, OpenSSL will keep itself
> >> in memory until that time >(otherwise crashes will occur because
> >> the cleanup routines have been unloaded).
> >>
> >> If you want to dynamically load and unload your DLL then don't
> >> statically link it to OpenSSL - >otherwise OpenSSL will keep your
> >> DLL around until process exit too.
> >>
> >> Matt
> >
> > That is very disappointing.  As a library vendor we have no control
> > over how our users load and unload our libraries.  We will just have
> > to roll back to 1.0.x and wait to see if this will be addressed.
> > Also, as Jakob stated in another post, it really seems like this
> > design will be problematic.
>
> Can you not link against the OpenSSL DLLs rather than statically link?
> That would avoid the problem.
>
> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170106/99acd3ba/attachment.html>

From Michael.Wojcik at microfocus.com  Fri Jan  6 16:37:28 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 6 Jan 2017 16:37:28 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
 <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C412DB3@prvxmb03.microfocus.com>

> 
> Can you not link against the OpenSSL DLLs rather than statically link?
> That would avoid the problem.

It introduces other problems. It means either shipping the OpenSSL DLLs or requiring the customer provide them; the former can have legal implications (cryptographic export licensing, for example), while the latter is a usability issue. It means the calling library no longer controls what version of OpenSSL is used, since the DLLs can be replaced.

I haven't looked at the 1.1.x source to see what OPENSSL_cleanup is doing, but it certainly sounds like a bad idea. What kind of cleanup needs to happen at process exit (in the typical environment in which OpenSSL is used)? I suppose I'll have to take a look at the source, but I'd be very interested to hear the rationale.

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From matt at openssl.org  Fri Jan  6 17:02:53 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 6 Jan 2017 17:02:53 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088018C412DB3@prvxmb03.microfocus.com>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
 <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088018C412DB3@prvxmb03.microfocus.com>
Message-ID: <a2808e6f-6c6a-0d9f-92cd-4bfc891a5fab@openssl.org>



On 06/01/17 16:37, Michael Wojcik wrote:
>> 
>> Can you not link against the OpenSSL DLLs rather than statically
>> link? That would avoid the problem.
> 
> It introduces other problems. It means either shipping the OpenSSL
> DLLs or requiring the customer provide them; the former can have
> legal implications (cryptographic export licensing, for example),
> while the latter is a usability issue. It means the calling library
> no longer controls what version of OpenSSL is used, since the DLLs
> can be replaced.
> 
> I haven't looked at the 1.1.x source to see what OPENSSL_cleanup is
> doing, but it certainly sounds like a bad idea. What kind of cleanup
> needs to happen at process exit (in the typical environment in which
> OpenSSL is used)? I suppose I'll have to take a look at the source,
> but I'd be very interested to hear the rationale.

The problem is that OpenSSL uses global state extensively. Additionally,
you may get more than one component of an application using OpenSSL at
the same time, e.g. the application could use it, as well as libraries
that the application is linked against. In OpenSSL <1.1.0 we had (lots
of) explicit cleanup routines. This was a problem in this scenario
because you could end up with one component cleaning stuff up that
another component was still using.

Initially our atexit cleanup was nicer and got called when the last
reference to OpenSSL got unloaded. However, while this worked nicely on
some platforms, it wasn't portable and caused problems (crashes).
There's a long discussion on the problem and some of the solutions we
looked at here:

https://github.com/openssl/openssl/pull/1693

and more briefly here:

https://github.com/openssl/openssl/pull/1690

An example of the issue we were trying to solve is here:

https://github.com/curl/curl/issues/1055

I'm wondering whether an option to override the default behaviour might
be possible, e.g. an explicit call to OPENSSL_init_crypto() with
something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application
would then have to call OPENSSL_cleanup() explicitly. This brings back
all the same problems with multiple components all using OpenSSL - but
perhaps you know this isn't a problem for your particular application
(especially if you are using static linking).

Matt


From Michael.Wojcik at microfocus.com  Fri Jan  6 17:38:33 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 6 Jan 2017 17:38:33 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <a2808e6f-6c6a-0d9f-92cd-4bfc891a5fab@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
 <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088018C412DB3@prvxmb03.microfocus.com>
 <a2808e6f-6c6a-0d9f-92cd-4bfc891a5fab@openssl.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C412ED9@prvxmb03.microfocus.com>

> 
> I'm wondering whether an option to override the default behaviour might
> be possible, e.g. an explicit call to OPENSSL_init_crypto() with
> something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The
> application would then have to call OPENSSL_cleanup() explicitly.

Or not, because cleaning up resources immediately before process termination is usually a waste of time.

Michael Wojcik 
Distinguished Engineer, Micro Focus 

From freemonj at gmail.com  Fri Jan  6 18:11:44 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Fri, 6 Jan 2017 13:11:44 -0500
Subject: [openssl-users] x509 extension support
Message-ID: <CALD4PSkr9bdDRZEH9EX2PcqysTkprz5GaaMpv36WKPGhCr_oQQ@mail.gmail.com>

Hello,

Can anyone help me in discerning which version of openssl supports
sbgp-autonomousSysNum
and sbgp-ipAddrBlock? If it has been deprecated then providing the
alternative would be greatly appreciated.



A sample openssl.cnf is provided below. When I perform a request for req it
fails because of the objects described above. The version of openssl I am
using when attempting this req generation is version OpenSSL 1.0.2g  1 Mar
2016


[req]default_bits            = 2048default_md              =
sha256distinguished_name      = req_dnprompt                  =
noencrypt_key             = no
[req_dn]CN                      = Testbed RPKI root certificate
[x509v3_extensions]basicConstraints        =
critical,CA:truesubjectKeyIdentifier    = hashkeyUsage
= critical,keyCertSign,cRLSignsubjectInfoAccess       =
@siacertificatePolicies     =
critical,1.3.6.1.5.5.7.14.2sbgp-autonomousSysNum   =
critical, at rfc3779_asnssbgp-ipAddrBlock        =
critical, at rfc3997_addrs
[sia]1.3.6.1.5.5.7.48.5;URI  =
rsync://example.org/rpki/root/1.3.6.1.5.5.7.48.10;URI =
rsync://example.org/rpki/root/root.mft
[rfc3779_asns]AS.0 = 64496-64511AS.1 = 65536-65551
[rfc3997_addrs]IPv4.0 = 192.0.2.0/24IPv4.1 = 198.51.100.0/24IPv4.2 =
203.0.113.0/24 IPv6.0 = 2001:0DB8::/32



Cheers,

Freemon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170106/7c976069/attachment.html>

From freemonj at gmail.com  Fri Jan  6 18:17:08 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Fri, 6 Jan 2017 13:17:08 -0500
Subject: [openssl-users] x509 extension support
Message-ID: <CALD4PS=sXqMmZe9AX2u1PAHcH8QN3WNWe9Bvek4hEEfuMrJ=_Q@mail.gmail.com>

Hello,

Can anyone help me in discerning which version of openssl supports
sbgp-autonomousSysNum
and sbgp-ipAddrBlock? If it has been deprecated then providing the
alternative would be greatly appreciated.



A sample openssl.cnf is provided below. When I perform a request for req it
fails because of the objects described above. The version of openssl I am
using when attempting this req generation is version OpenSSL 1.0.2g  1 Mar
2016


[req]default_bits            = 2048default_md              =
sha256distinguished_name      = req_dnprompt                  =
noencrypt_key             = no
[req_dn]CN                      = Testbed RPKI root certificate
[x509v3_extensions]basicConstraints        =
critical,CA:truesubjectKeyIdentifier    = hashkeyUsage
= critical,keyCertSign,cRLSignsubjectInfoAccess       =
@siacertificatePolicies     =
critical,1.3.6.1.5.5.7.14.2sbgp-autonomousSysNum   =
critical, at rfc3779_asnssbgp-ipAddrBlock        =
critical, at rfc3997_addrs
[sia]1.3.6.1.5.5.7.48.5;URI  =
rsync://example.org/rpki/root/1.3.6.1.5.5.7.48.10;URI =
rsync://example.org/rpki/root/root.mft
[rfc3779_asns]AS.0 = 64496-64511AS.1 = 65536-65551
[rfc3997_addrs]IPv4.0 = 192.0.2.0/24IPv4.1 = 198.51.100.0/24IPv4.2 =
203.0.113.0/24 IPv6.0 = 2001:0DB8::/32



Cheers,

Freemon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170106/f271aa94/attachment.html>

From w.trojan at gmx.de  Sun Jan  8 12:08:13 2017
From: w.trojan at gmx.de (Walter Trojan)
Date: Sun, 8 Jan 2017 13:08:13 +0100
Subject: [openssl-users] Help needed regarding x.509 keys for MQTT/Mosquitto
Message-ID: <0cd0b54c-8f69-602b-9af2-14250d73398b@gmx.de>

Hello,

I try to generate x.509-keys for TLS/SSL operation with MQTT and 
Mosquitto and follow the Mosquitto TLS documentation:

Generate a certificate authority certificate and key.
     openssl req -new -x509 -days 365 -extensions v3_ca -keyout ca.key 
-out ca.crt

Generate a server key.
     openssl genrsa -des3 -out server.key 1024

Generate a certificate signing request to send to the CA.
     openssl req -out server.csr -key server.key -new

Send the CSR to the CA, or sign it with your CA key:
     openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key 
-CAcreateserial -out server.crt -days 365

The first two operations went well, but during the third, the signing 
request to the CA, I got the following error message:

OpenSSL> req -out server.csr -key server.key -new
problem creating object tsa_policy1=1.2.3.4.1
5596:error:08064066:object identifier routines:OBJ_create:oid 
exists:crypto\objects\obj_dat.
c:689:
error in req
OpenSSL>

I have installed Win32OpenSSL 1.1.0, the big package.

It would be great, if somebody could give me a hint in order to solve 
this problem.

Many thanks in advance and best regards
Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170108/75693b34/attachment-0001.html>

From jeffsaremi at hotmail.com  Tue Jan 10 04:04:19 2017
From: jeffsaremi at hotmail.com (jeff saremi)
Date: Tue, 10 Jan 2017 04:04:19 +0000
Subject: [openssl-users] Build problems on Windows
Message-ID: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>

Hello

I downloaded openssl-1.1.0c and i'm trying to build this on Windows 10 using Visual Studio 2015. I'm following the INSTALL and NOTES.WIN instructions however I get stopped rather quickly with file not found issues..

I have also installed nasm. The build fails for 32 or 64 with slightly different paths in the error. Here's the sequence of commands:
1.perl Configure VC-WIN32
2.nmake


output:

D:\repos\openssl-1.1.0c>perl Configure VC-WIN64A
Configuring OpenSSL version 1.1.0c (0x1010003fL)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for VC-WIN64A
CC            =cl
CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =/nologo /debug
PLIB_LFLAG    =
EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ      =win32_init.o ../ms/applink.o
CPUID_OBJ     =x86_64cpuid.o
UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC    =chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =true
ARFLAGS       =/nologo
PERL          =perl

SIXTY_FOUR_BIT mode

Configured for VC-WIN64A.

D:\repos\openssl-1.1.0c>nmake

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        "perl" "-I." -Mconfigdata "util/dofile.pl"  "-omakefile" "crypto/include/internal/bn_conf.h.in" > crypto/include/internal/bn_conf.h
        "perl" "-I." -Mconfigdata "util/dofile.pl"  "-omakefile" "crypto/include/internal/dso_conf.h.in" > crypto/include/internal/dso_conf.h
        "perl" "-I." -Mconfigdata "util/dofile.pl"  "-omakefile" "include/openssl/opensslconf.h.in" > include/openssl/opensslconf.h
        set ASM=nasm
        "perl" "crypto/aes/asm/aes-x86_64.pl" "auto" crypto/aes/aes-x86_64.asm

        nasm -f win64 -DNEAR -Ox -g -ocrypto/aes/aes-x86_64.obj "crypto/aes/aes-x86_64.asm"
nasm: fatal: unable to open input file `crypto/aes/aes-x86_64.asm'
NMAKE : fatal error U1077: 'C:\nasm-2.12.02\nasm.EXE' : return code '0x1'
Stop.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/686b46a4/attachment.html>

From jb-openssl at wisemo.com  Tue Jan 10 05:46:12 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Jan 2017 06:46:12 +0100
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
Message-ID: <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>

On 10/01/2017 05:04, jeff saremi wrote:
>
> Hello
>
> I downloaded openssl-1.1.0c and i'm trying to build this on Windows 10 
> using Visual Studio 2015. I'm following the INSTALL and NOTES.WIN 
> instructions however I get stopped rather quickly with file not found 
> issues..
>
> I have also installed nasm. The build fails for 32 or 64 with slightly 
> different paths in the error. Here's the sequence of commands:
> 1.perl Configure VC-WIN32
> 2.nmake
>
>
> output:
>
> D:\repos\openssl-1.1.0c>perl Configure VC-WIN64A
> Configuring OpenSSL version 1.1.0c (0x1010003fL)
>     no-asan         [default]  OPENSSL_NO_ASAN
>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>     no-crypto-mdebug-backtrace [default] 
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>     no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
>     no-egd          [default]  OPENSSL_NO_EGD
>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>     no-msan         [default]  OPENSSL_NO_MSAN
>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>     no-sctp         [default]  OPENSSL_NO_SCTP
>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>     no-ssl3         [default]  OPENSSL_NO_SSL3
>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>     no-ubsan        [default]  OPENSSL_NO_UBSAN
>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>     no-zlib         [default]
>     no-zlib-dynamic [default]
> Configuring for VC-WIN64A
> CC            =cl
> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 
> -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE 
> -D_UNICODE /MD /O2
> SHARED_CFLAG  =
> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS 
> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 
> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM 
> SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM 
> GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
> LFLAG         =/nologo /debug
> PLIB_LFLAG    =
> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
> APPS_OBJ      =win32_init.o ../ms/applink.o
> CPUID_OBJ     =x86_64cpuid.o
> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC       =des_enc.o fcrypt_b.o
> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o 
> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> BF_ENC        =bf_enc.o
> CAST_ENC      =c_enc.o
> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC       =rc5_enc.o
> MD5_OBJ_ASM   =md5-x86_64.o
> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o 
> sha1-mb-x86_64.o sha256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ   =e_padlock-x86_64.o
> CHACHA_ENC    =chacha-x86_64.o
> POLY1305_OBJ  =poly1305-x86_64.o
> BLAKE2_OBJ    =
> PROCESSOR     =
> RANLIB        =true
> ARFLAGS       =/nologo
> PERL          =perl
>
> SIXTY_FOUR_BIT mode
>
> Configured for VC-WIN64A.
>
> D:\repos\openssl-1.1.0c>nmake
>
> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
> "crypto/include/internal/bn_conf.h.in" > crypto/include/internal/bn_conf.h
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
> "crypto/include/internal/dso_conf.h.in" > 
> crypto/include/internal/dso_conf.h
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
> "include/openssl/opensslconf.h.in" > include/openssl/opensslconf.h
>         set ASM=nasm
>         "perl" "crypto/aes/asm/aes-x86_64.pl" "auto" 
> crypto/aes/aes-x86_64.asm
>
>         nasm -f win64 -DNEAR -Ox -g -ocrypto/aes/aes-x86_64.obj 
> "crypto/aes/aes-x86_64.asm"
> nasm: fatal: unable to open input file `crypto/aes/aes-x86_64.asm'
> NMAKE : fatal error U1077: 'C:\nasm-2.12.02\nasm.EXE' : return code '0x1'
> Stop.
>
>
Check your perl version, with the command perl -V


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From freemonj at gmail.com  Tue Jan 10 14:42:34 2017
From: freemonj at gmail.com (Freemon Johnson)
Date: Tue, 10 Jan 2017 09:42:34 -0500
Subject: [openssl-users]  x509 extension support
Message-ID: <CALD4PSkriuzEji2aHKY5M4WQ2csXtKHuAS52-wYTaRAQTubFQg@mail.gmail.com>

Hello,

Can anyone help me in discerning which version of openssl supports
sbgp-autonomousSysNum
and sbgp-ipAddrBlock? If it has been deprecated then providing the
alternative would be greatly appreciated.



A sample openssl.cnf is provided below. When I perform a request for req it
fails because of the objects described above. The version of openssl I am
using when attempting this req generation is version OpenSSL 1.0.2g  1 Mar
2016


[req]default_bits            = 2048default_md              =
sha256distinguished_name      = req_dnprompt                  =
noencrypt_key             = no
[req_dn]CN                      = Testbed RPKI root certificate
[x509v3_extensions]basicConstraints        =
critical,CA:truesubjectKeyIdentifier    = hashkeyUsage
= critical,keyCertSign,cRLSignsubjectInfoAccess       =
@siacertificatePolicies     =
critical,1.3.6.1.5.5.7.14.2sbgp-autonomousSysNum   =
critical, at rfc3779_asnssbgp-ipAddrBlock        =
critical, at rfc3997_addrs
[sia]1.3.6.1.5.5.7.48.5;URI  =
rsync://example.org/rpki/root/1.3.6.1.5.5.7.48.10;URI =
rsync://example.org/rpki/root/root.mft
[rfc3779_asns]AS.0 = 64496-64511AS.1 = 65536-65551
[rfc3997_addrs]IPv4.0 = 192.0.2.0/24IPv4.1 = 198.51.100.0/24IPv4.2 =
203.0.113.0/24 IPv6.0 = 2001:0DB8::/32



Cheers,

Freemon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/1cb21bea/attachment-0001.html>

From rschm2 at unh.newhaven.edu  Tue Jan 10 16:05:09 2017
From: rschm2 at unh.newhaven.edu (Schmicker, Robert)
Date: Tue, 10 Jan 2017 16:05:09 +0000
Subject: [openssl-users] build.info documentation
Message-ID: <BF657A10-90E4-42AC-A4C7-E2786BE0DBD5@unh.newhaven.edu>

Hello,

Can anyone here point me in the direction to some documentation on build.info<http://build.info> files?

For the most part I?m creating mine using examples from other crypto ciphers but could use some more in depth explanation of what is going on when it is being parsed.

More specifically, I?m attempting to create a build.info<http://build.info> file that will trigger a Makefile in a subdirectory for my new encryption cipher to later include using the INCLUDE[?].

Thank you in advance to any advice or help!
Rob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/53980b12/attachment.html>

From jeffsaremi at hotmail.com  Tue Jan 10 18:34:31 2017
From: jeffsaremi at hotmail.com (jeff saremi)
Date: Tue, 10 Jan 2017 18:34:31 +0000
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>,
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
Message-ID: <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>

D:\repos\openssl2\openssl-1.1.0c>perl -v

This is perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-msys-thread-multi
Copyright 1987-2015, Larry Wall



________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Jakob Bohm <jb-openssl at wisemo.com>
Sent: Monday, January 9, 2017 9:46 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Build problems on Windows

On 10/01/2017 05:04, jeff saremi wrote:
>
> Hello
>
> I downloaded openssl-1.1.0c and i'm trying to build this on Windows 10
> using Visual Studio 2015. I'm following the INSTALL and NOTES.WIN
> instructions however I get stopped rather quickly with file not found
> issues..
>
> I have also installed nasm. The build fails for 32 or 64 with slightly
> different paths in the error. Here's the sequence of commands:
> 1.perl Configure VC-WIN32
> 2.nmake
>
>
> output:
>
> D:\repos\openssl-1.1.0c>perl Configure VC-WIN64A
> Configuring OpenSSL version 1.1.0c (0x1010003fL)
>     no-asan         [default]  OPENSSL_NO_ASAN
>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>     no-crypto-mdebug-backtrace [default]
> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>     no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
>     no-egd          [default]  OPENSSL_NO_EGD
>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>     no-msan         [default]  OPENSSL_NO_MSAN
>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>     no-sctp         [default]  OPENSSL_NO_SCTP
>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>     no-ssl3         [default]  OPENSSL_NO_SSL3
>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>     no-ubsan        [default]  OPENSSL_NO_UBSAN
>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>     no-zlib         [default]
>     no-zlib-dynamic [default]
> Configuring for VC-WIN64A
> CC            =cl
> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32
> -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE
> -D_UNICODE /MD /O2
> SHARED_CFLAG  =
> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS
> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
> SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM
> GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
> LFLAG         =/nologo /debug
> PLIB_LFLAG    =
> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
> APPS_OBJ      =win32_init.o ../ms/applink.o
> CPUID_OBJ     =x86_64cpuid.o
> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
> DES_ENC       =des_enc.o fcrypt_b.o
> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
> BF_ENC        =bf_enc.o
> CAST_ENC      =c_enc.o
> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
> RC5_ENC       =rc5_enc.o
> MD5_OBJ_ASM   =md5-x86_64.o
> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> sha1-mb-x86_64.o sha256-mb-x86_64.o
> RMD160_OBJ_ASM=
> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
> PADLOCK_OBJ   =e_padlock-x86_64.o
> CHACHA_ENC    =chacha-x86_64.o
> POLY1305_OBJ  =poly1305-x86_64.o
> BLAKE2_OBJ    =
> PROCESSOR     =
> RANLIB        =true
> ARFLAGS       =/nologo
> PERL          =perl
>
> SIXTY_FOUR_BIT mode
>
> Configured for VC-WIN64A.
>
> D:\repos\openssl-1.1.0c>nmake
>
> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
> "crypto/include/internal/bn_conf.h.in" > crypto/include/internal/bn_conf.h
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
> "crypto/include/internal/dso_conf.h.in" >
> crypto/include/internal/dso_conf.h
>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
> "include/openssl/opensslconf.h.in" > include/openssl/opensslconf.h
>         set ASM=nasm
>         "perl" "crypto/aes/asm/aes-x86_64.pl" "auto"
> crypto/aes/aes-x86_64.asm
>
>         nasm -f win64 -DNEAR -Ox -g -ocrypto/aes/aes-x86_64.obj
> "crypto/aes/aes-x86_64.asm"
> nasm: fatal: unable to open input file `crypto/aes/aes-x86_64.asm'
> NMAKE : fatal error U1077: 'C:\nasm-2.12.02\nasm.EXE' : return code '0x1'
> Stop.
>
>
Check your perl version, with the command perl -V


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
[https://www.wisemo.com/wp-content/uploads/WMO_03.jpg]<https://www.wisemo.com/>

WiseMo A/S ? Remote desktop control of Smartphones ...<https://www.wisemo.com/>
www.wisemo.com
WiseMo provides remote desktop access from anywhere. Secure, fast and stable remote control software for Tablet, Smartphone and PC


Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
openssl-users Info Page<https://mta.openssl.org/mailman/listinfo/openssl-users>
mta.openssl.org
This mailing list is for discussion among those using the OpenSSL software. To see the collection of prior postings to the list, visit the openssl-users Archives


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/34eadc10/attachment-0001.html>

From matt at openssl.org  Tue Jan 10 18:43:29 2017
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Jan 2017 18:43:29 +0000
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
Message-ID: <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>



On 10/01/17 18:34, jeff saremi wrote:
> D:\repos\openssl2\openssl-1.1.0c>perl -v
> 
> This is perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-msys-thread-multi
> Copyright 1987-2015, Larry Wall

You are using msys perl but doing a VC build.

See this extract from NOTES.PERL in the distribution:

 Notes on Perl on Windows
 ------------------------

 There are a number of build targets that can be viewed as "Windows".
 Indeed, there are VC-* configs targeting VisualStudio C, as well as
 MinGW and Cygwin. The key recommendation is to use "matching" Perl,
 one that matches build environment. For example, if you will build
 on Cygwin be sure to use the Cygwin package manager to install Perl.
 For MSYS builds use the MSYS provided Perl. For VC-* builds we
 recommend ActiveState Perl, available from
 http://www.activestate.com/ActivePerl.


Matt


> 
> 
> 
> ------------------------------------------------------------------------
> *From:* openssl-users <openssl-users-bounces at openssl.org> on behalf of
> Jakob Bohm <jb-openssl at wisemo.com>
> *Sent:* Monday, January 9, 2017 9:46 PM
> *To:* openssl-users at openssl.org
> *Subject:* Re: [openssl-users] Build problems on Windows
>  
> On 10/01/2017 05:04, jeff saremi wrote:
>>
>> Hello
>>
>> I downloaded openssl-1.1.0c and i'm trying to build this on Windows 10 
>> using Visual Studio 2015. I'm following the INSTALL and NOTES.WIN 
>> instructions however I get stopped rather quickly with file not found 
>> issues..
>>
>> I have also installed nasm. The build fails for 32 or 64 with slightly 
>> different paths in the error. Here's the sequence of commands:
>> 1.perl Configure VC-WIN32
>> 2.nmake
>>
>>
>> output:
>>
>> D:\repos\openssl-1.1.0c>perl Configure VC-WIN64A
>> Configuring OpenSSL version 1.1.0c (0x1010003fL)
>>     no-asan         [default]  OPENSSL_NO_ASAN
>>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>>     no-crypto-mdebug-backtrace [default] 
>> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>>     no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
>>     no-egd          [default]  OPENSSL_NO_EGD
>>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>>     no-msan         [default]  OPENSSL_NO_MSAN
>>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>>     no-sctp         [default]  OPENSSL_NO_SCTP
>>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>>     no-ssl3         [default]  OPENSSL_NO_SSL3
>>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>>     no-ubsan        [default]  OPENSSL_NO_UBSAN
>>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>>     no-zlib         [default]
>>     no-zlib-dynamic [default]
>> Configuring for VC-WIN64A
>> CC            =cl
>> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 
>> -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE 
>> -D_UNICODE /MD /O2
>> SHARED_CFLAG  =
>> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS 
>> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2 
>> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM 
>> SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM 
>> GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
>> LFLAG         =/nologo /debug
>> PLIB_LFLAG    =
>> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
>> APPS_OBJ      =win32_init.o ../ms/applink.o
>> CPUID_OBJ     =x86_64cpuid.o
>> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
>> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o 
>> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
>> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
>> DES_ENC       =des_enc.o fcrypt_b.o
>> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o 
>> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
>> BF_ENC        =bf_enc.o
>> CAST_ENC      =c_enc.o
>> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
>> RC5_ENC       =rc5_enc.o
>> MD5_OBJ_ASM   =md5-x86_64.o
>> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o 
>> sha1-mb-x86_64.o sha256-mb-x86_64.o
>> RMD160_OBJ_ASM=
>> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
>> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
>> PADLOCK_OBJ   =e_padlock-x86_64.o
>> CHACHA_ENC    =chacha-x86_64.o
>> POLY1305_OBJ  =poly1305-x86_64.o
>> BLAKE2_OBJ    =
>> PROCESSOR     =
>> RANLIB        =true
>> ARFLAGS       =/nologo
>> PERL          =perl
>>
>> SIXTY_FOUR_BIT mode
>>
>> Configured for VC-WIN64A.
>>
>> D:\repos\openssl-1.1.0c>nmake
>>
>> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
>> "crypto/include/internal/bn_conf.h.in" > crypto/include/internal/bn_conf.h
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
>> "crypto/include/internal/dso_conf.h.in" > 
>> crypto/include/internal/dso_conf.h
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile" 
>> "include/openssl/opensslconf.h.in" > include/openssl/opensslconf.h
>>         set ASM=nasm
>>         "perl" "crypto/aes/asm/aes-x86_64.pl" "auto" 
>> crypto/aes/aes-x86_64.asm
>>
>>         nasm -f win64 -DNEAR -Ox -g -ocrypto/aes/aes-x86_64.obj 
>> "crypto/aes/aes-x86_64.asm"
>> nasm: fatal: unable to open input file `crypto/aes/aes-x86_64.asm'
>> NMAKE : fatal error U1077: 'C:\nasm-2.12.02\nasm.EXE' : return code '0x1'
>> Stop.
>>
>>
> Check your perl version, with the command perl -V
> 
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> <https://www.wisemo.com/>
> 	
> WiseMo A/S ? Remote desktop control of Smartphones ...
> <https://www.wisemo.com/>
> www.wisemo.com
> WiseMo provides remote desktop access from anywhere. Secure, fast and
> stable remote control software for Tablet, Smartphone and PC
> 
> 
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> openssl-users Info Page
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
> mta.openssl.org
> This mailing list is for discussion among those using the OpenSSL
> software. To see the collection of prior postings to the list, visit the
> openssl-users Archives
> 
> 
> 
> 

From jeffsaremi at hotmail.com  Tue Jan 10 18:51:46 2017
From: jeffsaremi at hotmail.com (jeff saremi)
Date: Tue, 10 Jan 2017 18:51:46 +0000
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>,
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
Message-ID: <CY4PR14MB135269E86FF7DC7CF8E44349C1670@CY4PR14MB1352.namprd14.prod.outlook.com>

i was not aware of that. thanks so much. I'll go back and install a proper Perl


________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Matt Caswell <matt at openssl.org>
Sent: Tuesday, January 10, 2017 10:43 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Build problems on Windows



On 10/01/17 18:34, jeff saremi wrote:
> D:\repos\openssl2\openssl-1.1.0c>perl -v
>
> This is perl 5, version 22, subversion 1 (v5.22.1) built for
> x86_64-msys-thread-multi
> Copyright 1987-2015, Larry Wall

You are using msys perl but doing a VC build.

See this extract from NOTES.PERL in the distribution:

 Notes on Perl on Windows
 ------------------------

 There are a number of build targets that can be viewed as "Windows".
 Indeed, there are VC-* configs targeting VisualStudio C, as well as
 MinGW and Cygwin. The key recommendation is to use "matching" Perl,
 one that matches build environment. For example, if you will build
 on Cygwin be sure to use the Cygwin package manager to install Perl.
 For MSYS builds use the MSYS provided Perl. For VC-* builds we
 recommend ActiveState Perl, available from
 http://www.activestate.com/ActivePerl.
ActivePerl | ActiveState<http://www.activestate.com/ActivePerl>
www.activestate.com
ActivePerl Business and Enterprise Editions feature our precompiled, supported, quality-assured Perl distribution used by millions of developers around the world for ...




Matt


>
>
>
> ------------------------------------------------------------------------
> *From:* openssl-users <openssl-users-bounces at openssl.org> on behalf of
> Jakob Bohm <jb-openssl at wisemo.com>
> *Sent:* Monday, January 9, 2017 9:46 PM
> *To:* openssl-users at openssl.org
> *Subject:* Re: [openssl-users] Build problems on Windows
>
> On 10/01/2017 05:04, jeff saremi wrote:
>>
>> Hello
>>
>> I downloaded openssl-1.1.0c and i'm trying to build this on Windows 10
>> using Visual Studio 2015. I'm following the INSTALL and NOTES.WIN
>> instructions however I get stopped rather quickly with file not found
>> issues..
>>
>> I have also installed nasm. The build fails for 32 or 64 with slightly
>> different paths in the error. Here's the sequence of commands:
>> 1.perl Configure VC-WIN32
>> 2.nmake
>>
>>
>> output:
>>
>> D:\repos\openssl-1.1.0c>perl Configure VC-WIN64A
>> Configuring OpenSSL version 1.1.0c (0x1010003fL)
>>     no-asan         [default]  OPENSSL_NO_ASAN
>>     no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
>>     no-crypto-mdebug-backtrace [default]
>> OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>>     no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128
>>     no-egd          [default]  OPENSSL_NO_EGD
>>     no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
>>     no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
>>     no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
>>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>>     no-msan         [default]  OPENSSL_NO_MSAN
>>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>>     no-sctp         [default]  OPENSSL_NO_SCTP
>>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
>>     no-ssl3         [default]  OPENSSL_NO_SSL3
>>     no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
>>     no-ubsan        [default]  OPENSSL_NO_UBSAN
>>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
>>     no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
>>     no-zlib         [default]
>>     no-zlib-dynamic [default]
>> Configuring for VC-WIN64A
>> CC            =cl
>> CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32
>> -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE
>> -D_UNICODE /MD /O2
>> SHARED_CFLAG  =
>> DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS
>> OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
>> OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
>> SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM
>> GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
>> LFLAG         =/nologo /debug
>> PLIB_LFLAG    =
>> EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
>> APPS_OBJ      =win32_init.o ../ms/applink.o
>> CPUID_OBJ     =x86_64cpuid.o
>> UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
>> BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
>> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
>> EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
>> DES_ENC       =des_enc.o fcrypt_b.o
>> AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
>> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o
>> BF_ENC        =bf_enc.o
>> CAST_ENC      =c_enc.o
>> RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
>> RC5_ENC       =rc5_enc.o
>> MD5_OBJ_ASM   =md5-x86_64.o
>> SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
>> sha1-mb-x86_64.o sha256-mb-x86_64.o
>> RMD160_OBJ_ASM=
>> CMLL_ENC      =cmll-x86_64.o cmll_misc.o
>> MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
>> PADLOCK_OBJ   =e_padlock-x86_64.o
>> CHACHA_ENC    =chacha-x86_64.o
>> POLY1305_OBJ  =poly1305-x86_64.o
>> BLAKE2_OBJ    =
>> PROCESSOR     =
>> RANLIB        =true
>> ARFLAGS       =/nologo
>> PERL          =perl
>>
>> SIXTY_FOUR_BIT mode
>>
>> Configured for VC-WIN64A.
>>
>> D:\repos\openssl-1.1.0c>nmake
>>
>> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
>> "crypto/include/internal/bn_conf.h.in" > crypto/include/internal/bn_conf.h
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
>> "crypto/include/internal/dso_conf.h.in" >
>> crypto/include/internal/dso_conf.h
>>         "perl" "-I." -Mconfigdata "util/dofile.pl" "-omakefile"
>> "include/openssl/opensslconf.h.in" > include/openssl/opensslconf.h
>>         set ASM=nasm
>>         "perl" "crypto/aes/asm/aes-x86_64.pl" "auto"
>> crypto/aes/aes-x86_64.asm
>>
>>         nasm -f win64 -DNEAR -Ox -g -ocrypto/aes/aes-x86_64.obj
>> "crypto/aes/aes-x86_64.asm"
>> nasm: fatal: unable to open input file `crypto/aes/aes-x86_64.asm'
>> NMAKE : fatal error U1077: 'C:\nasm-2.12.02\nasm.EXE' : return code '0x1'
>> Stop.
>>
>>
> Check your perl version, with the command perl -V
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
[https://www.wisemo.com/wp-content/uploads/WMO_03.jpg]<https://www.wisemo.com/>

WiseMo A/S ? Remote desktop control of Smartphones ...<https://www.wisemo.com/>
www.wisemo.com
WiseMo provides remote desktop access from anywhere. Secure, fast and stable remote control software for Tablet, Smartphone and PC


> <https://www.wisemo.com/>
>
> WiseMo A/S ? Remote desktop control of Smartphones ...
> <https://www.wisemo.com/>
> www.wisemo.com<http://www.wisemo.com>
> WiseMo provides remote desktop access from anywhere. Secure, fast and
> stable remote control software for Tablet, Smartphone and PC
>
>
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> openssl-users Info Page
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
> mta.openssl.org
> This mailing list is for discussion among those using the OpenSSL
> software. To see the collection of prior postings to the list, visit the
> openssl-users Archives
>
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/3144391c/attachment-0001.html>

From jb-openssl at wisemo.com  Tue Jan 10 19:20:30 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 10 Jan 2017 20:20:30 +0100
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
Message-ID: <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>

On 10/01/2017 19:43, Matt Caswell wrote:
>   Notes on Perl on Windows
>   ------------------------
>
>   There are a number of build targets that can be viewed as "Windows".
>   Indeed, there are VC-* configs targeting VisualStudio C, as well as
>   MinGW and Cygwin. The key recommendation is to use "matching" Perl,
>   one that matches build environment. For example, if you will build
>   on Cygwin be sure to use the Cygwin package manager to install Perl.
>   For MSYS builds use the MSYS provided Perl. For VC-* builds we
>   recommend ActiveState Perl, available from
>   http://www.activestate.com/ActivePerl.
>
Really?, I thought ActiveState ActivePerl was pretty much dead/historic.

While I have not bothered with OpenSSL 1.1.x builds yet, I usually use
Strawberry Perl for VC-related work, and it seems to work fine with the
1.0.2 sources.  Since I have not tested with 1.1.x sources, this is
obviously not intended as advice to people trying to build, more as
something you might consider for an updated version of NOTES.PERL
(after testing it of cause).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From rjkmurray40 at gmail.com  Tue Jan 10 19:25:57 2017
From: rjkmurray40 at gmail.com (rjkmurray40)
Date: Tue, 10 Jan 2017 15:25:57 -0400
Subject: [openssl-users] Build problems on Windows
Message-ID: <q2tdkmeax8rxktnlwvw4wga3.1484076357102@email.android.com>

Can you redirect me in the direction of virtual windows platforms on android tablet


Sent from my Bell Samsung device over Canada's largest network.
-------- Original message --------From: Jakob Bohm <jb-openssl at wisemo.com> Date: 2017-01-10  3:20 PM  (GMT-04:00) To: openssl-users at openssl.org Subject: Re: [openssl-users] Build problems on Windows 
On 10/01/2017 19:43, Matt Caswell wrote:
>?? Notes on Perl on Windows
>?? ------------------------
>
>?? There are a number of build targets that can be viewed as "Windows".
>?? Indeed, there are VC-* configs targeting VisualStudio C, as well as
>?? MinGW and Cygwin. The key recommendation is to use "matching" Perl,
>?? one that matches build environment. For example, if you will build
>?? on Cygwin be sure to use the Cygwin package manager to install Perl.
>?? For MSYS builds use the MSYS provided Perl. For VC-* builds we
>?? recommend ActiveState Perl, available from
>?? http://www.activestate.com/ActivePerl.
>
Really?, I thought ActiveState ActivePerl was pretty much dead/historic.

While I have not bothered with OpenSSL 1.1.x builds yet, I usually use
Strawberry Perl for VC-related work, and it seems to work fine with the
1.0.2 sources.? Since I have not tested with 1.1.x sources, this is
obviously not intended as advice to people trying to build, more as
something you might consider for an updated version of NOTES.PERL
(after testing it of cause).

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.? https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.? Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/cf7f0258/attachment.html>

From jeffsaremi at hotmail.com  Tue Jan 10 19:40:54 2017
From: jeffsaremi at hotmail.com (jeff saremi)
Date: Tue, 10 Jan 2017 19:40:54 +0000
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>,
 <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
Message-ID: <CY4PR14MB13529B788981FFA6183BA742C1670@CY4PR14MB1352.namprd14.prod.outlook.com>

I installed ActivePerl and got a lot further

I now get link errors. Please see below. The commands are the same: perl Configure VS-WIN64A and nmake:


        "C:\Perl64\bin\perl.exe" "util\mkdef.pl" "crypto" 32 > libcrypto-1_1-x64.def
        "C:\Perl64\bin\perl.exe" -i.tmp -pe "s|^LIBRARY\s+crypto32|LIBRARY libcrypto-1_1-x64|;" libcrypto-1_1-x64.def
        DEL libcrypto-1_1-x64.def.tmp
        "C:\Perl64\bin\perl.exe" "util\mkrc.pl" libcrypto-1_1-x64.dll > libcrypto-1_1-x64.rc
        rc /folibcrypto-1_1-x64.res libcrypto-1_1-x64.rc
Microsoft (R) Windows (R) Resource Compiler Version 6.3.9600.17336
Copyright (C) Microsoft Corporation.  All rights reserved.

        IF EXIST libcrypto-1_1-x64.dll.manifest DEL /F /Q libcrypto-1_1-x64.dll.manifest
        link /nologo /debug /dll  /implib:libcrypto.lib /out:libcrypto-1_1-x64.dll /def:libcrypto-1_1-x64.def @C:\Users\jesaremi\AppData\Local\Temp\nm8557.tmp || (DEL /Q libcrypto.* libcrypto-1_1-x64.* && EXIT 1)
crypto\aes\aes_cfb.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.



________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Jakob Bohm <jb-openssl at wisemo.com>
Sent: Tuesday, January 10, 2017 11:20 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Build problems on Windows

On 10/01/2017 19:43, Matt Caswell wrote:
>   Notes on Perl on Windows
>   ------------------------
>
>   There are a number of build targets that can be viewed as "Windows".
>   Indeed, there are VC-* configs targeting VisualStudio C, as well as
>   MinGW and Cygwin. The key recommendation is to use "matching" Perl,
>   one that matches build environment. For example, if you will build
>   on Cygwin be sure to use the Cygwin package manager to install Perl.
>   For MSYS builds use the MSYS provided Perl. For VC-* builds we
>   recommend ActiveState Perl, available from
>   http://www.activestate.com/ActivePerl.
ActivePerl | ActiveState<http://www.activestate.com/ActivePerl>
www.activestate.com
ActivePerl Business and Enterprise Editions feature our precompiled, supported, quality-assured Perl distribution used by millions of developers around the world for ...


>
Really?, I thought ActiveState ActivePerl was pretty much dead/historic.

While I have not bothered with OpenSSL 1.1.x builds yet, I usually use
Strawberry Perl for VC-related work, and it seems to work fine with the
1.0.2 sources.  Since I have not tested with 1.1.x sources, this is
obviously not intended as advice to people trying to build, more as
something you might consider for an updated version of NOTES.PERL
(after testing it of cause).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
[https://www.wisemo.com/wp-content/uploads/WMO_03.jpg]<https://www.wisemo.com/>

WiseMo A/S ? Remote desktop control of Smartphones ...<https://www.wisemo.com/>
www.wisemo.com
WiseMo provides remote desktop access from anywhere. Secure, fast and stable remote control software for Tablet, Smartphone and PC


Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/44152354/attachment-0001.html>

From dheinz at softwarekey.com  Tue Jan 10 18:18:57 2017
From: dheinz at softwarekey.com (Dan Heinz)
Date: Tue, 10 Jan 2017 18:18:57 +0000
Subject: [openssl-users] Openssl static build linked in DLL does not
 unload on win32
In-Reply-To: <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
References: <DM5PR06MB3004799E04D16484B57D9BD0D9610@DM5PR06MB3004.namprd06.prod.outlook.com>
 <ba55522c-e281-ce3a-79aa-08f2a1816177@openssl.org>
 <DM5PR06MB3004D93FFCFE1CC2FA44C9C7D9630@DM5PR06MB3004.namprd06.prod.outlook.com>
 <4eb2a15b-d9fc-fc3d-c982-3aaf0e7b871e@openssl.org>
Message-ID: <DM5PR06MB30043B4812925398A4B979D5D9670@DM5PR06MB3004.namprd06.prod.outlook.com>

>>>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c.
>>>> 
>>>> I have a test application that is a win32 console app that calls a >
>>> win32 DLL which has the openssl libraries linked in statically>.
>>>> 
>>>> The test applications uses late-binding to the DLL and calls 
>>>> LoadLibrary for the DLL, one test function in the DLL, and then 
>>>> FreeLibrary on the DLL.>
>>>> 
>>>> 
>>>> 
>>>> The test function in the DLL does the following:>
>>>> 
>>>> RSA*rsa = NULL;
>>>> 
>>>> rsa = RSA_new();>
>>>> 
>>>> RSA_free(rsa);
>>>> 
>>>> OPENSSL_thread_stop();>
>>>> 
>>>> OPENSSL_cleanup();
>>>> 
>>>> return0;>
>>>> 
>>>> When FreeLibrary is called on the DLL, dllmain in never called with 
>>>> any messages.  A subsequent call to LoadLibrary also fails to call 
>>>> dllmain and when the test function is called RSA_new() fails.  This >
>>> leads me to believe the DLL is never freed>.
>>>> 
>>>> I have tried building openssl with and without no-threads with the 
>>>> same results.  My build parameters are: perl Configure
>>>> *%TEMP_ARCHITECTURE%*>
>>> --prefix=*%RootPath_T>hirdParty%*\*%OPENSSL_VERSION%* -DPURIFY 
>>> -DOPENSSL_NO_COMP -D>_USING_V110_SDK71_ no-shared no-threads no-asm 
>>> no-idea no-mdc2 no->rc5  no-ssl3 no-zlib no-comp
>>>> 
>>>> What am I missing?
>>> 
>>> >
>> >OpenSSL does its cleanup at *process* exit. Don't call
>>> OPENSSL_cleanup() explicitly - this is >discouraged.
>>> 
>>> From this manpage:>
>>> 
>>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html
>>>>
>>>>
>>>>
"Ty>pically there should be no need to call this function directly as it is initiated >a>utomatically on application exit...<snip>...
>>> 
>>> Once OPENSSL_cleanup() has been called the library cannot be >
>>> reinitialised.>"
>>> 
>>> This last sentence is the reason why RSA_new() will fail after you 
>>> have previously called >OPENSSL_cleanup().>
>>> 
>>> Because cleanup happens on process exit, OpenSSL will keep itself in 
>>> memory until that time >(otherwise crashes will occur because the >
>>> cleanup routines have been unloaded)>.
>>> 
>>> If you want to dynamically load and unload your DLL then don't 
>>> statically link it to OpenSSL - >otherwise OpenSSL will keep your DLL >
>>> around until process exit too>.
>>> 
>>> Matt
>>>
>>That is very disappointing.  As a library vendor we have no control 
>> over how our users load and unload our libraries.  We will just have 
>> to roll back to 1.0.x and wait to see if this will be addressed.
>> Also, as Jakob stated in another post, it really seems like this
>> design will be problematic.
>
>Can you not link against the OpenSSL DLLs rather than statically link?
>That would avoid the problem.

Unfortunately, no.  We need to control the version of OpenSSL, and our users generally do not wish to have to distribute another DLL.  In addition, the static link adds a bit more protection from tampering.  I see you posted a link elsewhere to the discussion regarding this decision and I will examine it.  Being able to explicitly initialize and exit the library would certainly fix the issue for us and most likely others who will run into this same issue.

Thanks,
Dan


From noloader at gmail.com  Tue Jan 10 19:52:45 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 10 Jan 2017 14:52:45 -0500
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <CY4PR14MB13529B788981FFA6183BA742C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
 <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
 <CY4PR14MB13529B788981FFA6183BA742C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
Message-ID: <CAH8yC8=ETT9j6ZWCXNOXxe6Otg+iefAXv9drFz3fz5K_Au+kBg@mail.gmail.com>

>         IF EXIST libcrypto-1_1-x64.dll.manifest DEL /F /Q
> libcrypto-1_1-x64.dll.manifest
>         link /nologo /debug /dll  /implib:libcrypto.lib
> /out:libcrypto-1_1-x64.dll /def:libcrypto-1_1-x64.def
> @C:\Users\jesaremi\AppData\Local\Temp\nm8557.tmp || (DEL /Q libcrypto.*
> libcrypto-1_1-x64.* && EXIT 1)
> crypto\aes\aes_cfb.obj : fatal error LNK1112: module machine type 'X86'
> conflicts with target machine type 'x64'
> NMAKE : fatal error U1077: 'link' : return code '0x1'
> Stop.
>

It sounds like the wrong Developer Tools Command Prompt was opened. You can
find them through Start -> Programs -> Visual Studio NNNN -> Developer
Tools. Also see
https://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx .

If you plan on building for x86 and you configure for VC-WIN32, then be
sure you open the x86 command prompt, and not the x64 one.

If you want to build for x64, then be sure to configure with VC-WIN64A, and
be sure to open a x64 developer command prompt.

If you have the correct command prompt open, then perform a clean or
distclean. You may have old artifacts lying around.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/0c0da064/attachment.html>

From jeffsaremi at hotmail.com  Tue Jan 10 19:57:36 2017
From: jeffsaremi at hotmail.com (jeff saremi)
Date: Tue, 10 Jan 2017 19:57:36 +0000
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <CAH8yC8=ETT9j6ZWCXNOXxe6Otg+iefAXv9drFz3fz5K_Au+kBg@mail.gmail.com>
References: <CY4PR14MB135277C73D2D95DD687EF453C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <3a980e9c-b953-cedc-db0f-790181b183d9@wisemo.com>
 <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
 <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
 <CY4PR14MB13529B788981FFA6183BA742C1670@CY4PR14MB1352.namprd14.prod.outlook.com>,
 <CAH8yC8=ETT9j6ZWCXNOXxe6Otg+iefAXv9drFz3fz5K_Au+kBg@mail.gmail.com>
Message-ID: <CY4PR14MB135247237752D9A13072051DC1670@CY4PR14MB1352.namprd14.prod.outlook.com>

thanks a lot. I opened a "VS2015 x64 Native Tools" window as opposed to a "VS2015 x64 x86 Cross Tools" and everything worked amazingly with no issues.

The names are super confusing.

but i'm ok now. thanks

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Jeffrey Walton <noloader at gmail.com>
Sent: Tuesday, January 10, 2017 11:52 AM
To: OpenSSL Users
Subject: Re: [openssl-users] Build problems on Windows


        IF EXIST libcrypto-1_1-x64.dll.manifest DEL /F /Q libcrypto-1_1-x64.dll.manifest
        link /nologo /debug /dll  /implib:libcrypto.lib /out:libcrypto-1_1-x64.dll /def:libcrypto-1_1-x64.def @C:\Users\jesaremi\AppData\Local\Temp\nm8557.tmp || (DEL /Q libcrypto.* libcrypto-1_1-x64.* && EXIT 1)
crypto\aes\aes_cfb.obj : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
NMAKE : fatal error U1077: 'link' : return code '0x1'
Stop.

It sounds like the wrong Developer Tools Command Prompt was opened. You can find them through Start -> Programs -> Visual Studio NNNN -> Developer Tools. Also see https://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx .
Developer Command Prompt for Visual Studio<https://msdn.microsoft.com/en-us/library/ms229859(v=vs.110).aspx>
msdn.microsoft.com
The Developer Command Prompt for Visual Studio automatically sets the environment variables that enable you to easily use .NET Framework tools.



If you plan on building for x86 and you configure for VC-WIN32, then be sure you open the x86 command prompt, and not the x64 one.

If you want to build for x64, then be sure to configure with VC-WIN64A, and be sure to open a x64 developer command prompt.

If you have the correct command prompt open, then perform a clean or distclean. You may have old artifacts lying around.

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170110/331baa8c/attachment-0001.html>

From levitte at openssl.org  Tue Jan 10 22:32:05 2017
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 10 Jan 2017 23:32:05 +0100 (CET)
Subject: [openssl-users] Build problems on Windows
In-Reply-To: <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
References: <CY4PR14MB135213C97169DB18026CDDE4C1670@CY4PR14MB1352.namprd14.prod.outlook.com>
 <adaa9860-66ae-7731-ba21-24e272f2d67c@openssl.org>
 <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5@wisemo.com>
Message-ID: <20170110.233205.855688631686415101.levitte@openssl.org>

In message <39de3d0c-b9f8-6576-b4ed-de4501fcb8d5 at wisemo.com> on Tue, 10 Jan 2017 20:20:30 +0100, Jakob Bohm <jb-openssl at wisemo.com> said:

jb-openssl> On 10/01/2017 19:43, Matt Caswell wrote:
jb-openssl> >   Notes on Perl on Windows
jb-openssl> >   ------------------------
jb-openssl> >
jb-openssl> >   There are a number of build targets that can be viewed as "Windows".
jb-openssl> >   Indeed, there are VC-* configs targeting VisualStudio C, as well as
jb-openssl> >   MinGW and Cygwin. The key recommendation is to use "matching" Perl,
jb-openssl> >   one that matches build environment. For example, if you will build
jb-openssl> >   on Cygwin be sure to use the Cygwin package manager to install Perl.
jb-openssl> >   For MSYS builds use the MSYS provided Perl. For VC-* builds we
jb-openssl> >   recommend ActiveState Perl, available from
jb-openssl> >   http://www.activestate.com/ActivePerl.
jb-openssl> >
jb-openssl> Really?, I thought ActiveState ActivePerl was pretty much
jb-openssl> dead/historic.

Looking at their downloads page, they seem to keep up:

http://www.activestate.com/activeperl/downloads

jb-openssl> While I have not bothered with OpenSSL 1.1.x builds yet, I usually use
jb-openssl> Strawberry Perl for VC-related work, and it seems to work fine with
jb-openssl> the
jb-openssl> 1.0.2 sources.  Since I have not tested with 1.1.x sources, this is
jb-openssl> obviously not intended as advice to people trying to build, more as
jb-openssl> something you might consider for an updated version of NOTES.PERL
jb-openssl> (after testing it of cause).

I've heard of more than one success with Strawberry, we just haven't
tested it ourselves.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From stm at pdflib.com  Wed Jan 11 15:32:10 2017
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 11 Jan 2017 16:32:10 +0100
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
Message-ID: <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>

Am 03.01.17 um 21:26 schrieb Viktor Dukhovni:
>
>> On Jan 3, 2017, at 2:55 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
>>
>> 1 - Is this a bit of a bug?
>>
>> ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the structure itself.  However, ECDSA_SIG_new() doesn't set r and s to
>> NULL.  It calls zalloc, which sets them to 0x00 bytes.
>>
>> OK, in most platforms, the NULL pointer is an all 0x00 bytes value, but it's not guaranteed by the C standard.
>>
>> E.g., http://c-faq.com/null/confusion4.html
>
> OpenSSL does not support platforms where the memory representation of the
> NULL pointer contains non-zero bytes. IIRC there are even tests for this.

Could someone from the OpenSSL team please explain the rationale for 
this decision? What is the problem with using assignments with 0 or NULL 
to initialize pointers?

--
Stephan

From rsalz at akamai.com  Wed Jan 11 16:09:49 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Jan 2017 16:09:49 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
Message-ID: <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>

> > OpenSSL does not support platforms where the memory representation of
> > the NULL pointer contains non-zero bytes. IIRC there are even tests for
> this.
> 
> Could someone from the OpenSSL team please explain the rationale for this
> decision? What is the problem with using assignments with 0 or NULL to
> initialize pointers?

I think you are confused.

There is no problem with what you posted.  The issue is that if NULL != 0, OpenSSL won't necessarily work.

See test/sanitytest.c for what we check.

From noloader at gmail.com  Wed Jan 11 16:18:38 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 11 Jan 2017 11:18:38 -0500
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
Message-ID: <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>

> Could someone from the OpenSSL team please explain the rationale for this
> decision? What is the problem with using assignments with 0 or NULL to
> initialize pointers?

I'm not from the team, so take it for what its worth...

On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
architecture wants it to be. It can be in a high page in memory, too.
One of my instructors in college was telling me about a system he
worked on where NULL was an address in the last page in memory, so it
took a value like `0xffffffff`.

Jeff

From kgoldman at us.ibm.com  Wed Jan 11 16:28:48 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 11 Jan 2017 11:28:48 -0500
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details - NULL
	vs zeros
In-Reply-To: <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
Message-ID: <o55mfq$no8$1@blaine.gmane.org>

On 1/11/2017 10:32 AM, Stephan M?hlstrasser wrote:
>>
>> OpenSSL does not support platforms where the memory representation of the
>> NULL pointer contains non-zero bytes. IIRC there are even tests for this.
>
> Could someone from the OpenSSL team please explain the rationale for
> this decision? What is the problem with using assignments with 0 or NULL
> to initialize pointers?

I suspect that it was a shortcut, where they used memset() on an entire 
structure, and it hopefully set pointers to NULL.

What I pointed out is that if NULL is not all zeros, this breaks.

~~~  BTW ~~~

Compilers know this.  So

	char *ptr = NULL;

and

	char *ptr = 0;

are equivalent, even on platforms where NULL is not all zeros.

It's when you cast the ptr to an integer first that it fails.



From jb-openssl at wisemo.com  Wed Jan 11 16:34:58 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 11 Jan 2017 17:34:58 +0100
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
Message-ID: <147d2271-886a-f316-b3f4-aa08abed24cb@wisemo.com>

On 11/01/2017 16:32, Stephan M?hlstrasser wrote:
> Am 03.01.17 um 21:26 schrieb Viktor Dukhovni:
>>
>>> On Jan 3, 2017, at 2:55 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
>>>
>>> 1 - Is this a bit of a bug?
>>>
>>> ECDSA_SIG_free() frees the r and s BIGNUMs before is frees the 
>>> structure itself.  However, ECDSA_SIG_new() doesn't set r and s to
>>> NULL.  It calls zalloc, which sets them to 0x00 bytes.
>>>
>>> OK, in most platforms, the NULL pointer is an all 0x00 bytes value, 
>>> but it's not guaranteed by the C standard.
>>>
>>> E.g., http://c-faq.com/null/confusion4.html
>>
>> OpenSSL does not support platforms where the memory representation of 
>> the
>> NULL pointer contains non-zero bytes. IIRC there are even tests for 
>> this.
>
> Could someone from the OpenSSL team please explain the rationale for 
> this decision? What is the problem with using assignments with 0 or 
> NULL to initialize pointers?
>
I am not from the OpenSSL team either, but the probable thinking is
like this:

The C (and C++) standard allows a number of things that are very rare
in practice, while providing very few guarantees about important
aspects of semantics.  Therefore most major cross-platform projects
will usually take a number of common-sense aspects that are already
common among the desired platforms and elevate them into "project-
specific" requirements, foregoing the option to port the code to
platforms that differ in those aspects.  This provides a more robust
and usable "dialect" of the C/C++ language, allowing code to not do
things that are clumsy, slow, error-prone or otherwise difficult.

For the specific requirement of NULL pointers being encoded as an
all-0 bit pattern (and the similar requirement for 0 integral values),
this allows the use of zero-initializing memory allocators/handlers to
forego the need to explicitly initialize NULL (and 0) field and array
element values.

Note that C++ has a similar, but weaker, requirements that the source
code literal 0 is a valid syntax for null pointer constants and that
many (but not all) uninitialized pointer and numeric fields should be
implicitly initialized to NULL / 0 by compiler generated code, which
doesn't cover the case of memory blocks that don't get to run the
(implicit) C++ constructor.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From rsalz at akamai.com  Wed Jan 11 17:22:40 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Jan 2017 17:22:40 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details -
	NULL	vs zeros
In-Reply-To: <o55mfq$no8$1@blaine.gmane.org>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <o55mfq$no8$1@blaine.gmane.org>
Message-ID: <2a9e6fb07b5d49ad99e1593e3e1e7408@usma1ex-dag1mb1.msg.corp.akamai.com>

> I suspect that it was a shortcut, where they used memset() on an entire
> structure, and it hopefully set pointers to NULL.
> 
> What I pointed out is that if NULL is not all zeros, this breaks.

And OpenSSL does not work on those platforms.  It is part of the test suite to check for this.  See test/sanitytest.c


From Michael.Wojcik at microfocus.com  Wed Jan 11 17:27:47 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 11 Jan 2017 17:27:47 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C415003@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jeffrey Walton
> Sent: Wednesday, January 11, 2017 11:19
> To: OpenSSL Users
> Subject: Re: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
> 
> > Could someone from the OpenSSL team please explain the rationale for
> this
> > decision? What is the problem with using assignments with 0 or NULL to
> > initialize pointers?
> 
> I'm not from the team, so take it for what its worth...
> 
> On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
> architecture wants it to be. It can be in a high page in memory, too.

This comment is misleading (as was Rich Salz's reply). Jeffrey's question, as phrased, is correct.

The definition of the NULL macro is mandated by the C standard. It is either an integer constant that evaluates to 0, or such a constant cast to void*.

The representation in memory of a null pointer need not be all-bits-zero. (The representation in memory of an integer constant with the value zero can either be all-bits-zero or, in the unlikely case of sign-magnitude integers, a sign bit of 1 followed by all-other-bits-zero.)

In other words, *in C source code* a null pointer is *always* created by assigning the NULL macro, or a literal 0, or such a thing cast to an appropriate pointer type, to a pointer variable. Even if the representation of a null pointer in memory is not all-bits-zero. Similarly, comparing a null pointer to a literal 0 evaluates as true, regardless of the representation of null pointers. That's required by the C standard; if it doesn't work, you're using a language which is almost but not quite entirely unlike C.

However: Operations such as memset(object_pointer, 0, size) may NOT create null pointers, because memset simply sets the underlying bits without any knowledge of types or representations.

And that's why many programs don't work on implementations where the null pointer representation is not all-bits-zero: because they use shortcuts like memset and calloc to "clear" pointers (generally as part of structs containing pointer fields), rather than doing it properly.

Doing it properly, incidentally, looks like this:

   static const struct foo foo0; 	/* implicitly equivalent to ... foo0 = {0} */
   ...
   struct foo *bar = malloc(sizeof *bar);
   *bar = foo0;

Unfortunately writing proper C is a rare skill - relatively few C programmers have ever even read the language specification - and much C code is saddled with lots of ancient technical debt. Also, of course, it often doesn't make economic sense to accommodate rare implementations. How many C programs work correctly on implementations where CHAR_BIT > 8?

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From rsalz at akamai.com  Wed Jan 11 17:32:37 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Jan 2017 17:32:37 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088018C415003@prvxmb03.microfocus.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088018C415003@prvxmb03.microfocus.com>
Message-ID: <a29f8f793db142ce8028f2b197348e71@usma1ex-dag1mb1.msg.corp.akamai.com>

> The representation in memory of a null pointer need not be all-bits-zero.
> (The representation in memory of an integer constant with the value zero
> can either be all-bits-zero or, in the unlikely case of sign-magnitude integers,
> a sign bit of 1 followed by all-other-bits-zero.)

And, again, openssl will not work on those platforms and we have a test to catch it.

> Doing it properly, incidentally, looks like this:

Look at apps/rehash.c :)


From openssl-users at dukhovni.org  Wed Jan 11 17:36:59 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Jan 2017 17:36:59 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088018C415003@prvxmb03.microfocus.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088018C415003@prvxmb03.microfocus.com>
Message-ID: <20170111173659.GA3081@mournblade.imrryr.org>

On Wed, Jan 11, 2017 at 05:27:47PM +0000, Michael Wojcik wrote:

> Unfortunately writing proper C is a rare skill - relatively few C
> programmers have ever even read the language specification - and much C
> code is saddled with lots of ancient technical debt. Also, of course, it
> often doesn't make economic sense to accommodate rare implementations.

In the case of OpenSSL, the issue was well understood, and upon
consideration a decision was made to not support platforms where
the memory representation of NULL is not zero.  A test was written
to make sure that non-conformant platforms are detected.

By way of contrast, the Postfix project supports non-zero NULLs,
and explicitly initializes pointer-valued member fields in structures.

Neither project simply ignores the issue.

-- 
	Viktor.

From nadia at yaymedia.com  Wed Jan 11 20:07:43 2017
From: nadia at yaymedia.com (Nadia Lapkovskaya)
Date: Wed, 11 Jan 2017 23:07:43 +0300
Subject: [openssl-users] ssl_pending returns 0 despite having data to read
In-Reply-To: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
Message-ID: <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>

Hi,

We are using openssl-1.0.2j. Noticed, that for http protocol everything is working fine, but when we are using our own binary protocol ssl_pending returns 0 all the time. We are using blocking socket. Tried with SSL_CTX_set_read_ahead set and unset.

Out test server sends back any info received from the client.

Test code looks like this:
bool write(const uint64_t* data, int count)
{
  int rc = SSL_write(_ssl, data, count * sizeof(uint64_t));
  return rc > 0 ? true : false;
}

bool read(uint64_t* data, int count)
{
  do {
      int rc = SSL_read(_ssl, data, count * sizeof(uint64_t));
      if (rc <= 0) {
          int err = SSL_get_error(_ssl, rc);
          std::string errs = ERR_error_string(err, nullptr);
          return false;
      }
  } while (SSL_pending(_ssl));
  return true;
}

During first ssl_read we received eight bytes, and after that ssl_pending returns 0. If we continue reading despite having no pending data, ssl_read returns the rest of the data. 
Could you please suggest what is wrong here.


Best regards,
Nadia.


From rjkmurray40 at gmail.com  Wed Jan 11 20:14:30 2017
From: rjkmurray40 at gmail.com (Ryan Murray)
Date: Wed, 11 Jan 2017 16:44:30 -0330
Subject: [openssl-users] ssl_pending returns 0 despite having data to
	read
In-Reply-To: <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
 <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
Message-ID: <CAJJQvo6EnyiairMnZC6GnNnOn0ficZTqUZTc3KtOcEFGnUmqLw@mail.gmail.com>

Could you give me a hand on a issue I've seem to of picked up with my
device . You and the colleagues if possible. My SamsungGalaxy s2 tablet not
responding.  Power button and display goes black and does not turn on for a
period of time.  I believe the programs running in background or in a
rooted format has been making the device malfunction. Is there a remote
interface we could link up and establish what the heck is happening.  Lol
Your truly
Ryan

Ryan Murray

On Jan 11, 2017 4:08 PM, "Nadia Lapkovskaya" <nadia at yaymedia.com> wrote:

> Hi,
>
> We are using openssl-1.0.2j. Noticed, that for http protocol everything is
> working fine, but when we are using our own binary protocol ssl_pending
> returns 0 all the time. We are using blocking socket. Tried with
> SSL_CTX_set_read_ahead set and unset.
>
> Out test server sends back any info received from the client.
>
> Test code looks like this:
> bool write(const uint64_t* data, int count)
> {
>   int rc = SSL_write(_ssl, data, count * sizeof(uint64_t));
>   return rc > 0 ? true : false;
> }
>
> bool read(uint64_t* data, int count)
> {
>   do {
>       int rc = SSL_read(_ssl, data, count * sizeof(uint64_t));
>       if (rc <= 0) {
>           int err = SSL_get_error(_ssl, rc);
>           std::string errs = ERR_error_string(err, nullptr);
>           return false;
>       }
>   } while (SSL_pending(_ssl));
>   return true;
> }
>
> During first ssl_read we received eight bytes, and after that ssl_pending
> returns 0. If we continue reading despite having no pending data, ssl_read
> returns the rest of the data.
> Could you please suggest what is wrong here.
>
>
> Best regards,
> Nadia.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170111/81184306/attachment.html>

From rjkmurray40 at gmail.com  Wed Jan 11 20:15:34 2017
From: rjkmurray40 at gmail.com (Ryan Murray)
Date: Wed, 11 Jan 2017 16:45:34 -0330
Subject: [openssl-users] ssl_pending returns 0 despite having data to
	read
In-Reply-To: <CAJJQvo6EnyiairMnZC6GnNnOn0ficZTqUZTc3KtOcEFGnUmqLw@mail.gmail.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
 <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
 <CAJJQvo6EnyiairMnZC6GnNnOn0ficZTqUZTc3KtOcEFGnUmqLw@mail.gmail.com>
Message-ID: <CAJJQvo4tNqkwxd_9AaUbKMu2EKm2m57=90qjGst6NhGsWk8WuQ@mail.gmail.com>

Situation maybe a security issue

Ryan Murray

On Jan 11, 2017 4:14 PM, "Ryan Murray" <rjkmurray40 at gmail.com> wrote:

> Could you give me a hand on a issue I've seem to of picked up with my
> device . You and the colleagues if possible. My SamsungGalaxy s2 tablet not
> responding.  Power button and display goes black and does not turn on for a
> period of time.  I believe the programs running in background or in a
> rooted format has been making the device malfunction. Is there a remote
> interface we could link up and establish what the heck is happening.  Lol
> Your truly
> Ryan
>
> Ryan Murray
>
> On Jan 11, 2017 4:08 PM, "Nadia Lapkovskaya" <nadia at yaymedia.com> wrote:
>
>> Hi,
>>
>> We are using openssl-1.0.2j. Noticed, that for http protocol everything
>> is working fine, but when we are using our own binary protocol ssl_pending
>> returns 0 all the time. We are using blocking socket. Tried with
>> SSL_CTX_set_read_ahead set and unset.
>>
>> Out test server sends back any info received from the client.
>>
>> Test code looks like this:
>> bool write(const uint64_t* data, int count)
>> {
>>   int rc = SSL_write(_ssl, data, count * sizeof(uint64_t));
>>   return rc > 0 ? true : false;
>> }
>>
>> bool read(uint64_t* data, int count)
>> {
>>   do {
>>       int rc = SSL_read(_ssl, data, count * sizeof(uint64_t));
>>       if (rc <= 0) {
>>           int err = SSL_get_error(_ssl, rc);
>>           std::string errs = ERR_error_string(err, nullptr);
>>           return false;
>>       }
>>   } while (SSL_pending(_ssl));
>>   return true;
>> }
>>
>> During first ssl_read we received eight bytes, and after that ssl_pending
>> returns 0. If we continue reading despite having no pending data, ssl_read
>> returns the rest of the data.
>> Could you please suggest what is wrong here.
>>
>>
>> Best regards,
>> Nadia.
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170111/9d452b31/attachment.html>

From rsalz at akamai.com  Wed Jan 11 20:25:29 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Jan 2017 20:25:29 +0000
Subject: [openssl-users] ssl_pending returns 0 despite having data to
	read
In-Reply-To: <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
 <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
Message-ID: <d42ec4b5656d40469d09f6f5cd84fea6@usma1ex-dag1mb1.msg.corp.akamai.com>

> During first ssl_read we received eight bytes, and after that ssl_pending
> returns 0. If we continue reading despite having no pending data, ssl_read
> returns the rest of the data.
> Could you please suggest what is wrong here.

Pending is an indication that there is unread data *on the local host.*  It has no idea of what the network is doing, buffering or delaying, and so on.

You'll have to look at adding bytecounts or other "framing" techniques to your protocol to know when enough data has been read.

From Michael.Wojcik at microfocus.com  Wed Jan 11 20:45:01 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 11 Jan 2017 20:45:01 +0000
Subject: [openssl-users] ssl_pending returns 0 despite having data to
 read
In-Reply-To: <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
 <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C415162@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Nadia Lapkovskaya
> Sent: Wednesday, January 11, 2017 15:08
> 
> During first ssl_read we received eight bytes, and after that ssl_pending
> returns 0. If we continue reading despite having no pending data, ssl_read
> returns the rest of the data.

Are you setting SSL_CTRL_SET_READ_AHEAD? SSL_pending doesn't work if read-ahead is set. See the comment in the definition of SSL_pending in ssl_lib.c


Did the client send a TLS record with more than 8 bytes of application data?

SSL_pending returns true if there's more application data to be read from the current record. (At least that's my interpretation from a quick glance at the source.)

TLS is a record-oriented protocol, but the API is not strictly record-oriented. TLS segments outbound application data into "fragments", with one fragment for each TLS record. If the application makes a single call to SSL_write with a data length that fits in a single fragment, that *should* go out as a single TLS record (I believe); but if the application makes multiple calls to SSL_write or sends a chunk of data that's bigger than the maximum fragment size for the connection, then the partitioning of application data into records is harder to predict.

If you want to know whether there might be additional records waiting, query the socket directly with an API such as select or poll. (If the records haven't made it into the socket's receive buffer yet, you're out of luck; there's no way for the application to tell that more data might arrive some time in the future.)

This isn't an issue for HTTP because HTTP is a self-delimiting protocol. The application can continue to issue receives, parsing what it's received so far, until it knows that it has the entire message. SSL_pending isn't particularly useful for such a protocol, unless it's doing non-blocking I/O - in which case the typical pattern is to loop calling SSL_read as long as either SSL_pending is true or the socket is readable. (Or until OpenSSL returns SSL_WANT_WRITE, in which case you have to wait until the socket is writable instead, because you're renegotiating.)

That's all off the top of my head, so I may have gone wrong there somewhere - in which case no doubt someone will correct me shortly.

Michael Wojcik 
Distinguished Engineer, Micro Focus 



From Erwann.Abalea at docusign.com  Wed Jan 11 17:54:49 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Wed, 11 Jan 2017 17:54:49 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <CAH8yC8=TVEttcKB=w2uU95k=kMwDvex04Y5aVeQ=UCe-4COM+Q@mail.gmail.com>
Message-ID: <32567E14-18F3-492F-8B81-D71C5C970973@docusign.com>

ISO/C 2011, clause 6.3.2.3:
----
An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to any object or function.

Conversion of a null pointer to another pointer type yields a null pointer of that type. Any two null pointers shall compare equal.
----

int *var1 = 0;
int *var2 = (void*)0;

result in var1 and var2 to both be null pointers (the null pointer constant being ? 0 ? or ? (void*)0 ?).

This doesn?t matter if your specific machine encodes null pointers as ?0xffffffff'.

On your specific machine, however:

int *var1;
int *var2 = 0;
memset(var1, 0, sizeof(var1));

won?t make var1 be a null pointer, but var2 will internally contain this 0xffffffff, and will be a null pointer.


Cordialement,
Erwann Abalea

> Le 11 janv. 2017 ? 17:18, Jeffrey Walton <noloader at gmail.com> a ?crit :
> 
>> Could someone from the OpenSSL team please explain the rationale for this
>> decision? What is the problem with using assignments with 0 or NULL to
>> initialize pointers?
> 
> I'm not from the team, so take it for what its worth...
> 
> On some systems, NULL is _not_ 0. NULL can be anywhere in memory the
> architecture wants it to be. It can be in a high page in memory, too.
> One of my instructors in college was telling me about a system he
> worked on where NULL was an address in the last page in memory, so it
> took a value like `0xffffffff`.
> 
> Jeff
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 


From matt at openssl.org  Wed Jan 11 23:39:25 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 11 Jan 2017 23:39:25 +0000
Subject: [openssl-users] ssl_pending returns 0 despite having data to
	read
In-Reply-To: <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
References: <A4129F6A-2257-4F2D-9577-90DA4B988628@yaymedia.com>
 <950B611E-C5BF-4E10-8BF2-D809D1660C46@yaymedia.com>
Message-ID: <4493192b-1ca5-7edb-0234-3516631305d0@openssl.org>



On 11/01/17 20:07, Nadia Lapkovskaya wrote:
> Hi,
> 
> We are using openssl-1.0.2j. Noticed, that for http protocol everything is working fine, but when we are using our own binary protocol ssl_pending returns 0 all the time. We are using blocking socket. Tried with SSL_CTX_set_read_ahead set and unset.
> 
> Out test server sends back any info received from the client.
> 
> Test code looks like this:
> bool write(const uint64_t* data, int count)
> {
>   int rc = SSL_write(_ssl, data, count * sizeof(uint64_t));
>   return rc > 0 ? true : false;
> }
> 
> bool read(uint64_t* data, int count)
> {
>   do {
>       int rc = SSL_read(_ssl, data, count * sizeof(uint64_t));
>       if (rc <= 0) {
>           int err = SSL_get_error(_ssl, rc);
>           std::string errs = ERR_error_string(err, nullptr);
>           return false;
>       }
>   } while (SSL_pending(_ssl));
>   return true;
> }
> 
> During first ssl_read we received eight bytes, and after that ssl_pending returns 0. If we continue reading despite having no pending data, ssl_read returns the rest of the data. 
> Could you please suggest what is wrong here.

There are three levels of buffered data that you need to consider:

- Data that is buffered at the network level
- Data that is buffered in OpenSSL but not yet processed (i.e. decrypted)
- Data that is buffered in OpenSSL that has been processed

SSL_pending() only tells you about the last type of data. TLS delivers
blocks of data in records and OpenSSL will decrypt an entire record in
one go. If your application only then reads some of that record then
SSL_pending() will tell you how many bytes of data it still has
available. If you always read an entire record in one go (i.e. if the
size of the buffer that you pass to SSL_read() is equal to or greater
than the amount of data in the record) then SSL_pending() will always
return 0.

Normally OpenSSL will only read one record at a time, so there isn't any
data of the second type. However if you set read_ahead then it will
attempt to read as much data as the network can give it, until the
internal buffer is filled. If that means it has read more than one
record (which could include partial records) then you will get data of
the second type. In 1.0.2 there is no way to get OpenSSL to tell you
whether it has any of that data buffered. In 1.1.0 you can find out
about this data using the new function SSL_has_pending():

https://www.openssl.org/docs/man1.1.0/ssl/SSL_pending.html

For data buffered at the network level you should query this yourself
using something like select() or poll().

Matt

From stm at pdflib.com  Thu Jan 12 08:01:00 2017
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Thu, 12 Jan 2017 09:01:00 +0100
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>

Am 11.01.17 um 17:09 schrieb Salz, Rich:
>>> OpenSSL does not support platforms where the memory representation of
>>> the NULL pointer contains non-zero bytes. IIRC there are even tests for
>> this.
>>
>> Could someone from the OpenSSL team please explain the rationale for this
>> decision? What is the problem with using assignments with 0 or NULL to
>> initialize pointers?
>
> I think you are confused.
>
> There is no problem with what you posted.  The issue is that if NULL != 0, OpenSSL won't necessarily work.
>
> See test/sanitytest.c for what we check.

I'm not confused. The other answers in the thread already explained in 
detail that NULL and 0 are equivalent for initializing pointers and that 
memset() is not a portable way to initialize pointers, and I am aware of 
that.

My question was meant to ask why the pointers are initialized with 
memset() instead of initializing them by an assignment with NULL or 0. 
Was this a deliberate decision for some reason, or did it just creep in 
and no one cares now to fix it? Would the OpenSSL team accept pull 
requests that fix this?

-- 
Stephan

From rsalz at akamai.com  Thu Jan 12 12:19:46 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 12 Jan 2017 12:19:46 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>
Message-ID: <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>

> My question was meant to ask why the pointers are initialized with
> memset() instead of initializing them by an assignment with NULL or 0.
> Was this a deliberate decision for some reason, or did it just creep in and no
> one cares now to fix it? Would the OpenSSL team accept pull requests that
> fix this?

It was a mix of what was done, and then a conscious decision to do things that way.

As for the PR, well, maybe...  We'd need to know details of which machine "test/sanitytest.c" fails on, and how popular it is to see if it's worthwhile.

From stm at pdflib.com  Thu Jan 12 12:50:25 2017
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Thu, 12 Jan 2017 13:50:25 +0100
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>
 <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <6e1d952f-6ffb-e758-20ec-0270434d24f5@pdflib.com>

Am 12.01.17 um 13:19 schrieb Salz, Rich:
>> My question was meant to ask why the pointers are initialized with
>> memset() instead of initializing them by an assignment with NULL or 0.
>> Was this a deliberate decision for some reason, or did it just creep in and no
>> one cares now to fix it? Would the OpenSSL team accept pull requests that
>> fix this?
>
> It was a mix of what was done, and then a conscious decision to do things that way.
>
> As for the PR, well, maybe...  We'd need to know details of which machine "test/sanitytest.c" fails on, and how popular it is to see if it's worthwhile.
>

Thanks for the clarification.

I think IBM iSeries is affected by this, but I still have to verify this.

-- 
Stephan

From Michael.Wojcik at microfocus.com  Thu Jan 12 14:07:36 2017
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 12 Jan 2017 14:07:36 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <6e1d952f-6ffb-e758-20ec-0270434d24f5@pdflib.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>
 <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>
 <6e1d952f-6ffb-e758-20ec-0270434d24f5@pdflib.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088018C41562D@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Stephan M?hlstrasser
> Sent: Thursday, January 12, 2017 07:50
> 
> I think IBM iSeries is affected by this, but I still have to verify this.

It's been years since I worked on the iSeries (in fact, it was mostly prior to the rename, so it was still OS/400 then); but IIRC the null-pointer representation was all-bits-zero for all of the IBM C implementations (EPM C, System/C, and ILE C).

The '400 / iSeries has an interesting pointer representation - 16 bytes, with a validity bit that can't be altered by user-mode code, to prevent constructing arbitrary pointers. It's a capabiltiy architecture, more or less. But in order to improve compatibility with pre-standard and poor C code, the C implementations recognize all-bits-zero in a pointer-type object as a null pointer. And attempting to dereference (via the MI MATPTR instruction) such an object raises the appropriate machine check (or program check? it's been a while).


In my experience, the real problems caused by non-conforming C code are more subtle. One thing that definitely *will* bite C programs on iSeries, for example, is failing to correctly declare a function that returns a pointer type, such as malloc - because an undeclared function is assumed to return int, and sizeof(int) < sizeof(void*) in those implementations.

And don't even get me started on calling undeclared functions on Itanium-based implementations...

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From jeremy.farrell at oracle.com  Thu Jan 12 16:54:45 2017
From: jeremy.farrell at oracle.com (J. J. Farrell)
Date: Thu, 12 Jan 2017 16:54:45 +0000
Subject: [openssl-users] ECDSA_SIG_new and ECDSA_SIG_free details
In-Reply-To: <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <o4gvji$s1h$1@blaine.gmane.org>
 <F00C2653-3F29-4DB4-8489-5ADEB1BAD8B2@dukhovni.org>
 <a35e84be-ffb0-2811-fce1-d38d98b86a97@pdflib.com>
 <d56c7e83eb8c4730822a151df54a973c@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5cd71b45-7c2c-51eb-1e90-4eece50467eb@pdflib.com>
 <bcadc7f4e49b49ab8032a7adf2aa9c76@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <17950ccc-496b-7b76-4a79-3293d3dcdfbf@oracle.com>

On 12/01/2017 12:19, Salz, Rich wrote:
> It was a mix of what was done, and then a conscious decision to do things that way.
>
> As for the PR, well, maybe...  We'd need to know details of which machine "test/sanitytest.c" fails on, and how popular it is to see if it's worthwhile.

That would be inefficient churning given the number of changes to 
replace conforming null pointer initialization with memset/calloc that 
have gone in since this decision was made. The decision sticks in the 
throat a bit for us standard nerds and old-timers who remember machines 
where the null pointer was not all-bits-zero, but it's decades since I 
heard of such a machine at large in the real world.

-- 
J. J. Farrell
Not speaking for Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170112/4740a5b9/attachment.html>

From graeme.perrow at sap.com  Thu Jan 12 20:10:07 2017
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Thu, 12 Jan 2017 20:10:07 +0000
Subject: [openssl-users] Can I rename the OpenSSL shared objects for FIPS?
Message-ID: <dd30cbd17c8f4628a8df3838b003252f@DEWDFE13DE08.global.corp.sap>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170112/c13c8dae/attachment.html>

From bkaduk at akamai.com  Thu Jan 12 22:13:30 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 12 Jan 2017 16:13:30 -0600
Subject: [openssl-users] Can I rename the OpenSSL shared objects for
	FIPS?
In-Reply-To: <dd30cbd17c8f4628a8df3838b003252f@DEWDFE13DE08.global.corp.sap>
References: <dd30cbd17c8f4628a8df3838b003252f@DEWDFE13DE08.global.corp.sap>
Message-ID: <17ca4c81-dbec-c791-4329-72b4a61fe005@akamai.com>

On 01/12/2017 02:10 PM, Perrow, Graeme wrote:
>
> 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.
>
>  
>

The full SONAME is used at runtime linking to locate the correct library
to use, so you may have an easier time just setting the library version
number to something unlikely to conflict with an official release --
that's just a one-line change in crypto/opensslv.h, SHLIB_VERSION_NUMBER.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170112/0657f1fa/attachment.html>

From kgoldman at us.ibm.com  Thu Jan 12 22:34:24 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 12 Jan 2017 17:34:24 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
Message-ID: <o59096$tv9$1@blaine.gmane.org>

On 7/20/2016 10:26 AM, Jakob Bohm wrote:
> On 20/07/2016 16:21, Ken Goldman wrote:
>> From these web pages:
>>
>> https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations
>>
>> https://www.openssl.org/docs/manmaster/apps/ecparam.html
>>
>> the "openssl ecparam -genkey" command does not accept a password. The
>> (perhaps) equivalent "openssl genrsa" command does.
>>
>> Is there a openssl command that can generate an ECC key pair where the
>> output file is password protected?
>>
> openssl genpkey

My latest attempt is this.  It gives me a usage error.  Any hints?

openssl genpkey -out cakeyecc.pem -outform pem  -pass pass:rrrr 
aes-256-cbc -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text





From openssl-users at dukhovni.org  Thu Jan 12 22:47:29 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 12 Jan 2017 17:47:29 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o59096$tv9$1@blaine.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
Message-ID: <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>


> On Jan 12, 2017, at 5:34 PM, Ken Goldman <kgoldman at us.ibm.com> wrote:
> 
>>> Is there a openssl command that can generate an ECC key pair where the
>>> output file is password protected?
>> openssl genpkey
> 
> My latest attempt is this.  It gives me a usage error.  Any hints?
> 
> openssl genpkey -out cakeyecc.pem -outform pem  -pass pass:rrrr aes-256-cbc -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text

The "aes-256-cbc" argument is wrong.  Try "-aes256".

Also, take a look at test/certs/mkcert.sh:

key() {
    local key=$1; shift
    
    local alg=rsa
    if [ -n "$OPENSSL_KEYALG" ]; then
        alg=$OPENSSL_KEYALG
    fi
    
    local bits=2048
    if [ -n "$OPENSSL_KEYBITS" ]; then
        bits=$OPENSSL_KEYBITS
    fi
    
    if [ ! -f "${key}.pem" ]; then
        args=(-algorithm "$alg")
        case $alg in
        rsa) args=("${args[@]}" -pkeyopt rsa_keygen_bits:$bits );;
        ec)  args=("${args[@]}" -pkeyopt "ec_paramgen_curve:$bits")
               args=("${args[@]}" -pkeyopt ec_param_enc:named_curve);; 
        *) printf "Unsupported key algorithm: %s\n" "$alg" >&2; return 1;;
        esac
        stderr_onerror \
            openssl genpkey "${args[@]}" -out "${key}.pem"
    fi
}

-- 
	Viktor.


From John.Eichenberger at Honeywell.com  Thu Jan 12 20:55:45 2017
From: John.Eichenberger at Honeywell.com (Eichenberger, John)
Date: Thu, 12 Jan 2017 20:55:45 +0000
Subject: [openssl-users] Can I rename the OpenSSL shared objects for
	FIPS?
In-Reply-To: <dd30cbd17c8f4628a8df3838b003252f@DEWDFE13DE08.global.corp.sap>
References: <dd30cbd17c8f4628a8df3838b003252f@DEWDFE13DE08.global.corp.sap>
Message-ID: <BLUPR0701MB210067D629866EF12A07981EF6790@BLUPR0701MB2100.namprd07.prod.outlook.com>

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-bounces at openssl.org] On Behalf Of Perrow, Graeme
Sent: Thursday, January 12, 2017 12:10 PM
To: openssl-users at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170112/f3009ace/attachment.html>

From thierry.parmentelat at inria.fr  Fri Jan 13 10:28:40 2017
From: thierry.parmentelat at inria.fr (Thierry Parmentelat)
Date: Fri, 13 Jan 2017 11:28:40 +0100
Subject: [openssl-users] troubleshooting a puzzling issue
Message-ID: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>

Hey


I am facing a problem that I have narrowed down to this:

I have two certificates, one being signed by the other
the attached code is a python code that uses M2Crypto to check for that fact

and it turns out, on some boxes x509_verify() returns 1 as expected, while on some others I am getting -1


---
I apologize that I am not able to write a pure C code that would reproduce the issue (I?m afraid that me trying to achieve that would just lead to more artificial problems than be actually helpful in any way :)

the m2crypto guys tell me they are essentially just passing stuff along to openssl?s function
X509_verify
as described here
https://www.openssl.org/docs/man1.1.0/crypto/X509_verify.html

---
and this says, I quote:

X509_verify(), X509_REQ_verify() and X509_CRL_verify() return 1 if the signature is valid and 0 if the signature check fails. If the signature could not be checked at all because it was invalid or some other error occurred then -1 is returned.


So my question here is, how do I go about figuring out what ?some other error? might be in my case ?

I was wondering, for example, if it could just be a missing library or something along this line, as my understanding is that the range of algorithms, ciphers, and other hashes can be configured at build-time
what tools can I use to look in this direction ?

---
So far it looks like the problems happens on fedora installations, while the code behaves as expected on macos and ubuntus
I have not yet been able to assess that on a wide variety of installations yet


Thanks for any hint 




-------------- next part --------------
A non-text attachment was scrubbed...
Name: m2.py
Type: text/x-python-script
Size: 1833 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170113/323959a0/attachment.bin>
-------------- next part --------------






From openssl-users at dukhovni.org  Fri Jan 13 14:26:35 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 09:26:35 -0500
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
Message-ID: <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>


> On Jan 13, 2017, at 5:28 AM, Thierry Parmentelat <thierry.parmentelat at inria.fr> wrote:
> 
> I have two certificates, one being signed by the other
> the attached code is a python code that uses M2Crypto to check for that fact

Your current problem is failure to post the two certificates along with
the anecdotal description.  You're also not reporting which versions of
the various O/S distributions you were using, and more importantly which
versions of OpenSSL were linked into Python's M2Crypto.

Real answers require real data.

-- 
-- 
	Viktor.


From kgoldman at us.ibm.com  Fri Jan 13 14:32:01 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 13 Jan 2017 09:32:01 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
Message-ID: <o5aocn$k1r$1@blaine.gmane.org>

Thanks, getting closer ...

On 1/12/2017 5:47 PM, Viktor Dukhovni wrote:
>> My latest attempt is this.  It gives me a usage error.  Any hints?
>>
>> openssl genpkey -out cakeyecc.pem -outform pem  -pass pass:rrrr aes-256-cbc -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text
>
> The "aes-256-cbc" argument is wrong.  Try "-aes256".

BTW, I got aes-256-cbc from

https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations

and > openssl list-cipher-commands

>
> Also, take a look at test/certs/mkcert.sh:

I looked at that, but what is $bits?

I got prime256v1, the curve I want, from

openssl ecparam -list_curves

My next tries:

openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256 
-algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text

openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256 
-algorithm ec pkeyopt ec_paramgen_curve:prime256v1 pkeyopt 
ec_param_enc:named_curve -text

openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256 
-algorithm ec pkeyopt ec_paramgen_curve:prime256v1 pkeyopt 
ec_param_enc:explicit -text

I get:

Error generating key
140529942484808:error:100C708B:elliptic curve routines:PKEY_EC_KEYGEN:no 
parameters set:ec_pmeth.c:294:

It's probably this LOC, but what am I missing?

     if (ctx->pkey == NULL && dctx->gen_group == NULL) {
         ECerr(EC_F_PKEY_EC_KEYGEN, EC_R_NO_PARAMETERS_SET);
         return 0;
     }



From matt at openssl.org  Fri Jan 13 14:38:15 2017
From: matt at openssl.org (Matt Caswell)
Date: Fri, 13 Jan 2017 14:38:15 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o5aocn$k1r$1@blaine.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
Message-ID: <aa5f10dd-b39d-65a3-e7f5-d08ed6fb14e0@openssl.org>



On 13/01/17 14:32, Ken Goldman wrote:
> Thanks, getting closer ...
> 
> On 1/12/2017 5:47 PM, Viktor Dukhovni wrote:
>>> My latest attempt is this.  It gives me a usage error.  Any hints?
>>>
>>> openssl genpkey -out cakeyecc.pem -outform pem  -pass pass:rrrr
>>> aes-256-cbc -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text
>>
>> The "aes-256-cbc" argument is wrong.  Try "-aes256".
> 
> BTW, I got aes-256-cbc from
> 
> https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations
> 
> and > openssl list-cipher-commands
> 
>>
>> Also, take a look at test/certs/mkcert.sh:
> 
> I looked at that, but what is $bits?
> 
> I got prime256v1, the curve I want, from
> 
> openssl ecparam -list_curves
> 
> My next tries:
> 
> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text

Try it with a "-" in front of "pkeyopt"!!!

Matt



> 
> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 pkeyopt
> ec_param_enc:named_curve -text
> 
> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 pkeyopt
> ec_param_enc:explicit -text
> 
> I get:
> 
> Error generating key
> 140529942484808:error:100C708B:elliptic curve routines:PKEY_EC_KEYGEN:no
> parameters set:ec_pmeth.c:294:
> 
> It's probably this LOC, but what am I missing?
> 
>     if (ctx->pkey == NULL && dctx->gen_group == NULL) {
>         ECerr(EC_F_PKEY_EC_KEYGEN, EC_R_NO_PARAMETERS_SET);
>         return 0;
>     }
> 
> 

From openssl-users at dukhovni.org  Fri Jan 13 14:44:57 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 14:44:57 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o5aocn$k1r$1@blaine.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
Message-ID: <20170113144457.GK3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 09:32:01AM -0500, Ken Goldman wrote:

> > The "aes-256-cbc" argument is wrong.  Try "-aes256".
> 
> BTW, I got aes-256-cbc from
> 
> https://wiki.openssl.org/index.php/Command_Line_Elliptic_Curve_Operations
> 
> and > openssl list-cipher-commands

When cipher names are used as options, they need a leading "-".

> > Also, take a look at test/certs/mkcert.sh:
> 
> I looked at that, but what is $bits?

The curve name.

> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 -text

You're sure fond of leaving off the leading "-" in option names.
You'll also really want the "ec_param_enc" option when you get
the rest of the syntax right.

> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec pkeyopt ec_paramgen_curve:prime256v1 pkeyopt
> ec_param_enc:named_curve -text

So this one is much closer, but now has two missing "-"s in "pkeyopt".

-- 
	Viktor.

From thierry.parmentelat at inria.fr  Fri Jan 13 15:17:14 2017
From: thierry.parmentelat at inria.fr (Thierry Parmentelat)
Date: Fri, 13 Jan 2017 16:17:14 +0100
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
Message-ID: <EEF6E1F3-F516-48ED-8211-6EB053AD7289@inria.fr>

Thanks Viktor for your feedback


Well, the 2 certificates are embedded in the python code as PEM; I am attaching them again here as plain files if that helps

-------------- next part --------------
A non-text attachment was scrubbed...
Name: p1
Type: application/octet-stream
Size: 834 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170113/67d37814/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p2
Type: application/octet-stream
Size: 786 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170113/67d37814/attachment-0001.obj>
-------------- next part --------------



In terms of versioning, on one box that exhibits the issue of returning -1, I have this:

# cat /etc/fedora-release
Fedora release 24 (Twenty Four)

both openssl and m2crypto installed from fedora?s stock repos:

# rpm -q m2crypto openssl-libs
m2crypto-0.23.0-2.fc24.x86_64
openssl-libs-1.0.2j-3.fc24.x86_64

# uname -a
Linux r2labsfa.pl.sophia.inria.fr 4.8.15-300.fc25.x86_64 #1 SMP Thu Dec 15 23:10:23 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux


I hope it clarifies ? thanks for looking into this ? Thierry


> On 13 Jan 2017, at 15:26, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> 
>> On Jan 13, 2017, at 5:28 AM, Thierry Parmentelat <thierry.parmentelat at inria.fr> wrote:
>> 
>> I have two certificates, one being signed by the other
>> the attached code is a python code that uses M2Crypto to check for that fact
> 
> Your current problem is failure to post the two certificates along with
> the anecdotal description.  You're also not reporting which versions of
> the various O/S distributions you were using, and more importantly which
> versions of OpenSSL were linked into Python's M2Crypto.
> 
> Real answers require real data.
> 
> -- 
> -- 
> 	Viktor.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From levitte at openssl.org  Fri Jan 13 15:37:18 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 13 Jan 2017 16:37:18 +0100 (CET)
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
Message-ID: <20170113.163718.1498855054591690568.levitte@openssl.org>

In message <41A36A7F-FF5D-4190-9178-E9FF11AFF712 at inria.fr> on Fri, 13 Jan 2017 11:28:40 +0100, Thierry Parmentelat <thierry.parmentelat at inria.fr> said:

thierry.parmentelat> I am facing a problem that I have narrowed down to this:
thierry.parmentelat> 
thierry.parmentelat> I have two certificates, one being signed by the other
thierry.parmentelat> the attached code is a python code that uses M2Crypto to check for that fact
thierry.parmentelat> 
thierry.parmentelat> and it turns out, on some boxes x509_verify() returns 1 as expected, while on some others I am getting -1
thierry.parmentelat> 
thierry.parmentelat> 
thierry.parmentelat> ---
thierry.parmentelat> I apologize that I am not able to write a pure C code that would reproduce the issue (I?m afraid that me trying to achieve that would just lead to more artificial problems than be actually helpful in any way :)
thierry.parmentelat> 
thierry.parmentelat> the m2crypto guys tell me they are essentially just passing stuff along to openssl?s function
thierry.parmentelat> X509_verify
thierry.parmentelat> as described here
thierry.parmentelat> https://www.openssl.org/docs/man1.1.0/crypto/X509_verify.html

Considering both certs in the attached script use the signature
algorithm md5WithRSAEncryption, you could get that kind of error with
an OpenSSL installation where MD5 has been disabled.  'openssl help'
will show you what's enabled, or 'openssl list -disabled' (with
OpenSSL 1.1.0) to see what's disabled.

There are other things that can give you a -1 as well...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From levitte at openssl.org  Fri Jan 13 15:38:14 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 13 Jan 2017 16:38:14 +0100 (CET)
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
Message-ID: <20170113.163814.907498527809634350.levitte@openssl.org>

In message <B5DA4D63-30E2-4A0E-B031-451F67F6392F at dukhovni.org> on Fri, 13 Jan 2017 09:26:35 -0500, Viktor Dukhovni <openssl-users at dukhovni.org> said:

openssl-users> 
openssl-users> > On Jan 13, 2017, at 5:28 AM, Thierry Parmentelat <thierry.parmentelat at inria.fr> wrote:
openssl-users> > 
openssl-users> > I have two certificates, one being signed by the other
openssl-users> > the attached code is a python code that uses M2Crypto to check for that fact
openssl-users> 
openssl-users> Your current problem is failure to post the two certificates along with
openssl-users> the anecdotal description.  You're also not reporting which versions of
openssl-users> the various O/S distributions you were using, and more importantly which
openssl-users> versions of OpenSSL were linked into Python's M2Crypto.
openssl-users> 
openssl-users> Real answers require real data.

Errrr...  there's a script attached to the original post.  It contains
all the data you need, including two certs.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From thierry.parmentelat at inria.fr  Fri Jan 13 15:46:59 2017
From: thierry.parmentelat at inria.fr (Thierry Parmentelat)
Date: Fri, 13 Jan 2017 16:46:59 +0100
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <20170113.163718.1498855054591690568.levitte@openssl.org>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <20170113.163718.1498855054591690568.levitte@openssl.org>
Message-ID: <8DF59EE9-2677-47D3-B9F6-69904B3EAE63@inria.fr>

Hey Richard

here?s what I see

# openssl help
openssl:Error: 'help' is an invalid command.

Standard commands
asn1parse         ca                ciphers           cms
crl               crl2pkcs7         dgst              dh
dhparam           dsa               dsaparam          ec
ecparam           enc               engine            errstr
gendh             gendsa            genpkey           genrsa
nseq              ocsp              passwd            pkcs12
pkcs7             pkcs8             pkey              pkeyparam
pkeyutl           prime             rand              req
rsa               rsautl            s_client          s_server
s_time            sess_id           smime             speed
spkac             ts                verify            version
x509

Message Digest commands (see the `dgst' command for more details)
md2               md4               md5               rmd160
sha               sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc       aes-128-ecb       aes-192-cbc       aes-192-ecb
aes-256-cbc       aes-256-ecb       base64            bf
bf-cbc            bf-cfb            bf-ecb            bf-ofb
camellia-128-cbc  camellia-128-ecb  camellia-192-cbc  camellia-192-ecb
camellia-256-cbc  camellia-256-ecb  cast              cast-cbc
cast5-cbc         cast5-cfb         cast5-ecb         cast5-ofb
des               des-cbc           des-cfb           des-ecb
des-ede           des-ede-cbc       des-ede-cfb       des-ede-ofb
des-ede3          des-ede3-cbc      des-ede3-cfb      des-ede3-ofb
des-ofb           des3              desx              idea
idea-cbc          idea-cfb          idea-ecb          idea-ofb
rc2               rc2-40-cbc        rc2-64-cbc        rc2-cbc
rc2-cfb           rc2-ecb           rc2-ofb           rc4
rc4-40            rc5               rc5-cbc           rc5-cfb
rc5-ecb           rc5-ofb           seed              seed-cbc
seed-cfb          seed-ecb          seed-ofb          zlib


so I do see md5 in the list of digests

what else should I be looking at ? 
is there a way to get some sort of error code or something that would at least hint at a direction..

thanks ? Thierry

> On 13 Jan 2017, at 16:37, Richard Levitte <levitte at openssl.org> wrote:
> 
> In message <41A36A7F-FF5D-4190-9178-E9FF11AFF712 at inria.fr> on Fri, 13 Jan 2017 11:28:40 +0100, Thierry Parmentelat <thierry.parmentelat at inria.fr> said:
> 
> thierry.parmentelat> I am facing a problem that I have narrowed down to this:
> thierry.parmentelat> 
> thierry.parmentelat> I have two certificates, one being signed by the other
> thierry.parmentelat> the attached code is a python code that uses M2Crypto to check for that fact
> thierry.parmentelat> 
> thierry.parmentelat> and it turns out, on some boxes x509_verify() returns 1 as expected, while on some others I am getting -1
> thierry.parmentelat> 
> thierry.parmentelat> 
> thierry.parmentelat> ---
> thierry.parmentelat> I apologize that I am not able to write a pure C code that would reproduce the issue (I?m afraid that me trying to achieve that would just lead to more artificial problems than be actually helpful in any way :)
> thierry.parmentelat> 
> thierry.parmentelat> the m2crypto guys tell me they are essentially just passing stuff along to openssl?s function
> thierry.parmentelat> X509_verify
> thierry.parmentelat> as described here
> thierry.parmentelat> https://www.openssl.org/docs/man1.1.0/crypto/X509_verify.html
> 
> Considering both certs in the attached script use the signature
> algorithm md5WithRSAEncryption, you could get that kind of error with
> an OpenSSL installation where MD5 has been disabled.  'openssl help'
> will show you what's enabled, or 'openssl list -disabled' (with
> OpenSSL 1.1.0) to see what's disabled.
> 
> There are other things that can give you a -1 as well...
> 
> Cheers,
> Richard
> 
> -- 
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/


From openssl-users at dukhovni.org  Fri Jan 13 15:47:34 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 15:47:34 +0000
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <EEF6E1F3-F516-48ED-8211-6EB053AD7289@inria.fr>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
 <EEF6E1F3-F516-48ED-8211-6EB053AD7289@inria.fr>
Message-ID: <20170113154734.GM3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 04:17:14PM +0100, Thierry Parmentelat wrote:

> Thanks Viktor for your feedback
> 
> Well, the 2 certificates are embedded in the python code as PEM; I am
> attaching them again here as plain files if that helps

The leaf certificate is signed with RSA+MD5:

    $ openssl x509 -in /tmp/p1 -noout -text | egrep -v '^ *..:'
    Certificate:
	Data:
	    Version: 3 (0x2)
	    Serial Number: 3 (0x3)
	Signature Algorithm: md5WithRSAEncryption
	    Issuer: CN=onelab.inria
	    Validity
		Not Before: Aug 18 13:30:49 2014 GMT
		Not After : Aug 17 13:30:49 2019 GMT
	    Subject: CN=onelab.inria.thierry_parmentelat
	    Subject Public Key Info:
		Public Key Algorithm: rsaEncryption
		    Public-Key: (1024 bit)
		    Modulus:
		    Exponent: 35 (0x23)
	    X509v3 extensions:
		X509v3 Basic Constraints: critical
		X509v3 Subject Alternative Name:
		    URI:urn:publicid:IDN+onelab:inria+user+thierry_parmentelat, URI:urn:uuid:8ee5aabe-5a16-4ac5-a18f-7ca145af285a
	Signature Algorithm: md5WithRSAEncryption

> In terms of versioning, on one box that exhibits the issue of returning -1, I have this:
> 
> # cat /etc/fedora-release
> Fedora release 24 (Twenty Four)

Redhat is removing support for MD5 signatures from their OpenSSL
builds.  From a recent email from them to the OpenSSL team:

    We (Red Hat Enterprise Linux developers) decided to disable
    support for verification of signatures with MD4, MD5, and SHA0
    hashes in openssl library in Red Hat Enterprise Linux 6 and
    newer and in Fedora. ...

Your 5 year MD5 certificate is getting stale, time to use something
a bit more current.  Also its rather small exponent (35) is very
unwise.  While not quite as bad as 3, it may be open to attack.

-- 
	Viktor.

From thierry.parmentelat at inria.fr  Fri Jan 13 15:52:05 2017
From: thierry.parmentelat at inria.fr (Thierry Parmentelat)
Date: Fri, 13 Jan 2017 16:52:05 +0100
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <20170113154734.GM3081@mournblade.imrryr.org>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <B5DA4D63-30E2-4A0E-B031-451F67F6392F@dukhovni.org>
 <EEF6E1F3-F516-48ED-8211-6EB053AD7289@inria.fr>
 <20170113154734.GM3081@mournblade.imrryr.org>
Message-ID: <5729747D-D2E6-4F17-ADEA-57C030437CBC@inria.fr>

ooookkkk; it explains it all :)

Thanks so much for your time looking into this, it is very helpful ? Thierry 


> On 13 Jan 2017, at 16:47, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> On Fri, Jan 13, 2017 at 04:17:14PM +0100, Thierry Parmentelat wrote:
> 
>> Thanks Viktor for your feedback
>> 
>> Well, the 2 certificates are embedded in the python code as PEM; I am
>> attaching them again here as plain files if that helps
> 
> The leaf certificate is signed with RSA+MD5:
> 
>    $ openssl x509 -in /tmp/p1 -noout -text | egrep -v '^ *..:'
>    Certificate:
> 	Data:
> 	    Version: 3 (0x2)
> 	    Serial Number: 3 (0x3)
> 	Signature Algorithm: md5WithRSAEncryption
> 	    Issuer: CN=onelab.inria
> 	    Validity
> 		Not Before: Aug 18 13:30:49 2014 GMT
> 		Not After : Aug 17 13:30:49 2019 GMT
> 	    Subject: CN=onelab.inria.thierry_parmentelat
> 	    Subject Public Key Info:
> 		Public Key Algorithm: rsaEncryption
> 		    Public-Key: (1024 bit)
> 		    Modulus:
> 		    Exponent: 35 (0x23)
> 	    X509v3 extensions:
> 		X509v3 Basic Constraints: critical
> 		X509v3 Subject Alternative Name:
> 		    URI:urn:publicid:IDN+onelab:inria+user+thierry_parmentelat, URI:urn:uuid:8ee5aabe-5a16-4ac5-a18f-7ca145af285a
> 	Signature Algorithm: md5WithRSAEncryption
> 
>> In terms of versioning, on one box that exhibits the issue of returning -1, I have this:
>> 
>> # cat /etc/fedora-release
>> Fedora release 24 (Twenty Four)
> 
> Redhat is removing support for MD5 signatures from their OpenSSL
> builds.  From a recent email from them to the OpenSSL team:
> 
>    We (Red Hat Enterprise Linux developers) decided to disable
>    support for verification of signatures with MD4, MD5, and SHA0
>    hashes in openssl library in Red Hat Enterprise Linux 6 and
>    newer and in Fedora. ...
> 
> Your 5 year MD5 certificate is getting stale, time to use something
> a bit more current.  Also its rather small exponent (35) is very
> unwise.  While not quite as bad as 3, it may be open to attack.
> 
> -- 
> 	Viktor.
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From levitte at openssl.org  Fri Jan 13 17:20:20 2017
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 13 Jan 2017 18:20:20 +0100 (CET)
Subject: [openssl-users] troubleshooting a puzzling issue
In-Reply-To: <8DF59EE9-2677-47D3-B9F6-69904B3EAE63@inria.fr>
References: <41A36A7F-FF5D-4190-9178-E9FF11AFF712@inria.fr>
 <20170113.163718.1498855054591690568.levitte@openssl.org>
 <8DF59EE9-2677-47D3-B9F6-69904B3EAE63@inria.fr>
Message-ID: <20170113.182020.2006763794227694163.levitte@openssl.org>

In message <8DF59EE9-2677-47D3-B9F6-69904B3EAE63 at inria.fr> on Fri, 13 Jan 2017 16:46:59 +0100, Thierry Parmentelat <thierry.parmentelat at inria.fr> said:

thierry.parmentelat> so I do see md5 in the list of digests

Ok

thierry.parmentelat> 
thierry.parmentelat> what else should I be looking at ? 
thierry.parmentelat> is there a way to get some sort of error code or something that would at least hint at a direction..

I found that M2Crypto has an Err package, so add this to your script:

    if v <= 0:
        print(M2Crypto.Err.get_error());
    else:
        print("v = {}".format(v))

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From kgoldman at us.ibm.com  Fri Jan 13 18:06:10 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 13 Jan 2017 13:06:10 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <20170113144457.GK3081@mournblade.imrryr.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org> <20170113144457.GK3081@mournblade.imrryr.org>
Message-ID: <o5b4u8$gdb$1@blaine.gmane.org>

Thanks for the help.  Am I getting closer?

On 1/13/2017 9:44 AM, Viktor Dukhovni wrote:
>>> Also, take a look at test/certs/mkcert.sh:
>>
>> I looked at that, but what is $bits?
>
> The curve name.
>
> You're sure fond of leaving off the leading "-" in option names.
> You'll also really want the "ec_param_enc" option when you get
> the rest of the syntax right.

OK, sorry, hyphen-o-phobia.

I gather now that there are two -pkeyopt:

ec_paramgen_curve
ec_param_enc

I tried prime256v1 for each, and also named_curve and explicit
for the second, in many combinations.

It's also not 100% clear whether I specify -pkeyopt each time, or once 
and then pairs of opt:value.

In all combinations, I now get:

openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256 
-algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 
ec_param_enc:explicit -text

parameter setting error
140171547424584:error:06089094:digital envelope 
routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:





From openssl-users at dukhovni.org  Fri Jan 13 18:18:51 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 18:18:51 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o5b4u8$gdb$1@blaine.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
 <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org>
Message-ID: <20170113181851.GO3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 01:06:10PM -0500, Ken Goldman wrote:

> I gather now that there are two -pkeyopt:

Yes.

> ec_paramgen_curve
> ec_param_enc
> 
> I tried prime256v1 for each, and also named_curve and explicit
> for the second, in many combinations.

Easier to read the documentation and use the appropriate value.

> It's also not 100% clear whether I specify -pkeyopt each time, or once and
> then pairs of opt:value.

Each time.

> In all combinations, I now get:
> 
> openssl genpkey -out cakeyecc.pem -outform pem -pass pass:rrrr -aes256
> -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 ec_param_enc:explicit
> -text

The explicit "-outform PEM" argument is not needed, but harmless:

    $ openssl genpkey -out cakeyecc.pem -outform PEM -pass pass:rrrr \
       -aes256 -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 \
	-pkeyopt ec_param_enc:named_curve -text

    $ cat cakeyecc.pem
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAhn8FHW0643QQICCAAw
    HQYJYIZIAWUDBAEqBBCtTYP4h4/2PTEfN1fVJnpHBIGQ3RHX/KUQwncg9MK5aF7H
    p0qQplxOKtfCOYp0iqx15IQCEv5N4SXIIKnRjvaKPHgFQN0d8x1Et0pBOaYLqIre
    zwch3VGRvvHH//qhXiYGay9xzZXraGwFFatNt9R8gyBKR7zMn/BQVWUtA8woCB//
    D/R9GGYJVr3afeay4Vr4U/kHtRUkTrkGZxRZvM2EIAsr
    -----END ENCRYPTED PRIVATE KEY-----
    Private-Key: (256 bit)
    priv:
	39:32:f7:c6:cf:fa:57:7f:9f:b0:d7:87:92:c0:93:
	36:33:9e:19:75:0c:58:f7:a0:ec:29:01:1f:c2:17:
	6a:9f
    pub:
	04:a2:2a:47:02:a3:ed:6c:e0:af:85:9f:f3:9e:f9:
	e7:e4:19:5a:49:05:09:2e:1e:40:d8:89:88:5a:2c:
	fc:dc:59:5b:27:9f:9d:00:78:d7:3d:16:68:b9:81:
	42:db:db:02:98:42:08:d9:2f:6f:e5:1d:a4:70:4f:
	1a:4e:2b:69:2f
    ASN1 OID: prime256v1
    NIST CURVE: P-256

As you can see the combination of "-aes256" and "-text" is unwise.
The "-text" form is not encrypted.

-- 
	Viktor.

From openssl-users at dukhovni.org  Fri Jan 13 18:21:59 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 18:21:59 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <20170113181851.GO3081@mournblade.imrryr.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
 <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org>
 <20170113181851.GO3081@mournblade.imrryr.org>
Message-ID: <20170113182159.GP3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 06:18:51PM +0000, Viktor Dukhovni wrote:

> Easier to read the documentation and use the appropriate value.

    https://www.openssl.org/docs/man1.1.0/apps/genpkey.html

-- 
	Viktor.

From kgoldman at us.ibm.com  Fri Jan 13 18:49:14 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 13 Jan 2017 13:49:14 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <20170113182159.GP3081@mournblade.imrryr.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org> <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org> <20170113181851.GO3081@mournblade.imrryr.org>
 <20170113182159.GP3081@mournblade.imrryr.org>
Message-ID: <o5b7f0$hfk$1@blaine.gmane.org>

On 1/13/2017 1:21 PM, Viktor Dukhovni wrote:
> On Fri, Jan 13, 2017 at 06:18:51PM +0000, Viktor Dukhovni wrote:

Still no success.  I think this is exactly what you suggested, and 
something I had already tried.

openssl genpkey -out cakeyecc.pem -outform PEM -pass pass:rrrr -aes256 
-algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt 
ec_param_enc:named_curve -text

parameter setting error
139854491113288:error:06089094:digital envelope 
routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:

>> Easier to read the documentation and use the appropriate value.
>
>     https://www.openssl.org/docs/man1.1.0/apps/genpkey.html

Yikes.  That's not in the  1.0.2 documentation at

https://www.openssl.org/docs/man1.0.2/apps/genpkey.html

Could it be that 1.0.2 doesn't support creation of EC keys?

Or, if the syntax is different, where can I find it?



From openssl-users at dukhovni.org  Fri Jan 13 19:02:12 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 19:02:12 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o5b7f0$hfk$1@blaine.gmane.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
 <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org>
 <20170113181851.GO3081@mournblade.imrryr.org>
 <20170113182159.GP3081@mournblade.imrryr.org>
 <o5b7f0$hfk$1@blaine.gmane.org>
Message-ID: <20170113190212.GQ3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 01:49:14PM -0500, Ken Goldman wrote:

> On 1/13/2017 1:21 PM, Viktor Dukhovni wrote:
> > On Fri, Jan 13, 2017 at 06:18:51PM +0000, Viktor Dukhovni wrote:
> 
> Still no success.  I think this is exactly what you suggested, and something
> I had already tried.
> 
> openssl genpkey -out cakeyecc.pem -outform PEM -pass pass:rrrr -aes256
> -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt
> ec_param_enc:named_curve -text
> 
> parameter setting error
> 139854491113288:error:06089094:digital envelope
> routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:

In that case, your OpenSSL library is broken, or was built without
EC support.  Perhaps you're running the wrong openssl(1) binary.

> https://www.openssl.org/docs/man1.0.2/apps/genpkey.html
> 
> Could it be that 1.0.2 doesn't support creation of EC keys?

EC key creation is supported in 1.0.2:

    $ openssl version -a; openssl genpkey -out cakeyecc.pem -outform PEM -pass pass:rrrr -aes256 -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -text; cat cakeyecc.pem
    OpenSSL 1.0.2j  26 Sep 2016
    built on: reproducible build, date unspecified
    platform: NetBSD-x86_64
    options:  bn(64,64) md2(int) rc4(8x,int) des(idx,cisc,16,int) blowfish(ptr2)
    compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H
    -O2 -I/usr/include -Wa,--noexecstack -DTERMIOS -DL_ENDIAN -DMD32_REG_T=int -O2 -DOPENSSL_IA32_SSE2
    -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM
    -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM
    OPENSSLDIR: "/usr/pkg/etc/openssl"
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAj2P6Eun6xu+QICCAAw
    HQYJYIZIAWUDBAEqBBCLkrjwPqdzyGUnq+FZmAXKBIGQYc6Ug3yc5JbhkUmNmtPm
    8An/0hE1ErvedRQFk0yyfUTiX/cHcuTkm5S5ZJlE4jtDJRidc3TxX59yTa6blZbp
    EilWzrACBO0POWeUsN0SnYAwHfaQ7dRKfoK0xmZJMRclzd9C62f64e/0Q2v1xdvj
    oMyg7aiK2fa1DdXdkDeB0j3Cnpo4x24ZY1De870LOkd/
    -----END ENCRYPTED PRIVATE KEY-----
    Private-Key: (256 bit)
    priv:
	63:c2:97:81:a3:bc:4f:10:cc:ca:68:70:bf:a3:fa:
	da:e3:fd:7d:d2:9f:88:b9:4b:bf:11:ac:4b:9c:b5:
	d4:c2
    pub:
	04:96:5d:78:a2:7b:60:b3:9c:67:7d:d7:19:68:4e:
	4e:7b:a4:75:46:31:b1:f6:76:28:86:fe:9a:56:9c:
	bc:3c:4b:37:0b:3b:0c:24:ed:2b:d1:8f:85:92:0f:
	6e:48:9d:49:2c:7b:e7:7c:df:94:8a:9d:4b:f8:bc:
	25:82:cb:50:22
    ASN1 OID: prime256v1
    NIST CURVE: P-256

The documentation of genpkey(1) was improved in 1.1.0, perhaps some
of the improvements should be backported. Pull requests welcome.

-- 
	Viktor.

From kgoldman at us.ibm.com  Fri Jan 13 20:26:08 2017
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 13 Jan 2017 15:26:08 -0500
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <20170113190212.GQ3081@mournblade.imrryr.org>
References: <nmo1cg$9qn$1@ger.gmane.org>
 <ff3c5a86-f537-2037-fcf2-35ced62072f5@wisemo.com>
 <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org> <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org> <20170113181851.GO3081@mournblade.imrryr.org>
 <20170113182159.GP3081@mournblade.imrryr.org> <o5b7f0$hfk$1@blaine.gmane.org>
 <20170113190212.GQ3081@mournblade.imrryr.org>
Message-ID: <o5bd4m$31n$1@blaine.gmane.org>

On 1/13/2017 2:02 PM, Viktor Dukhovni wrote:
>> parameter setting error
>> 139854491113288:error:06089094:digital envelope
>> routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:
>
> In that case, your OpenSSL library is broken, or was built without
> EC support.  Perhaps you're running the wrong openssl(1) binary.

Perhaps++.  The command ran on a 1.0.2 platform.

> EC key creation is supported in 1.0.2:

openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

The C API's seem to support EC.  Perhaps the openssl binary does not?

RHEL 6.7 is still at 1.0.1.

Can I create the key and certificates on the 1.0.2 platform and use them 
with the C API on 1.0.1?





From openssl-users at dukhovni.org  Fri Jan 13 20:48:32 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Jan 2017 20:48:32 +0000
Subject: [openssl-users] Generate ECC key with password protection
In-Reply-To: <o5bd4m$31n$1@blaine.gmane.org>
References: <o59096$tv9$1@blaine.gmane.org>
 <A9BC4C68-436A-4ED6-AFA2-9703A5C90491@dukhovni.org>
 <o5aocn$k1r$1@blaine.gmane.org>
 <20170113144457.GK3081@mournblade.imrryr.org>
 <o5b4u8$gdb$1@blaine.gmane.org>
 <20170113181851.GO3081@mournblade.imrryr.org>
 <20170113182159.GP3081@mournblade.imrryr.org>
 <o5b7f0$hfk$1@blaine.gmane.org>
 <20170113190212.GQ3081@mournblade.imrryr.org>
 <o5bd4m$31n$1@blaine.gmane.org>
Message-ID: <20170113204832.GS3081@mournblade.imrryr.org>

On Fri, Jan 13, 2017 at 03:26:08PM -0500, Ken Goldman wrote:

> On 1/13/2017 2:02 PM, Viktor Dukhovni wrote:
> > > parameter setting error
> > > 139854491113288:error:06089094:digital envelope
> > > routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:404:
> > 
> > In that case, your OpenSSL library is broken, or was built without
> > EC support.  Perhaps you're running the wrong openssl(1) binary.
> 
> Perhaps++.  The command ran on a 1.0.2 platform.
> 
> > EC key creation is supported in 1.0.2:
> 
> openssl version
> OpenSSL 1.0.1e-fips 11 Feb 2013
> 
> The C API's seem to support EC.  Perhaps the openssl binary does not?
> 
> RHEL 6.7 is still at 1.0.1.
> 
> Can I create the key and certificates on the 1.0.2 platform and use them
> with the C API on 1.0.1?

RedHat has in various past releases deliberately disabled EC support.
More recently they've enabled just the NIST P-256,384,521 curves.

So your software may be neutered by the vendor, however, you seem
to be using 1.0.1, while I was testing 1.0.2.

With 1.0.1 I get:

    $ openssl version -a; openssl genpkey -out cakeyecc.pem -outform PEM -pass pass:rrrr -aes256 -algorithm ec -pkeyopt ec_paramgen_curve:prime256v1 -pkeyopt ec_param_enc:named_curve -text; cat cakeyecc.pem
    OpenSSL 1.0.1v-dev  xx XXX xxxx
    built on: Fri Jan 13 15:35:13 2017
    platform: darwin64-x86_64-cc
    options:  bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(idx) 
    compiler: cc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
    OPENSSLDIR: "/Volumes/gitvol/viktor/ssl/OpenSSL_1_0_1/ssl"
    parameter setting error
    140735936984072:error:06089094:digital envelope routines:EVP_PKEY_CTX_ctrl:invalid operation:pmeth_lib.c:394:
    cat: cakeyecc.pem: No such file or directory

With 1.0.1, EC support in genpkey(1) is incomplete.  To encrypt
use a pipeline:

    $ openssl ecparam -name prime256v1 -genkey -noout | openssl pkey -aes256 -text
    Enter PEM pass phrase:
    Verifying - Enter PEM pass phrase:
    -----BEGIN ENCRYPTED PRIVATE KEY-----
    MIHeMEkGCSqGSIb3DQEFDTA8MBsGCSqGSIb3DQEFDDAOBAiDn5ZQFVqU2wICCAAw
    HQYJYIZIAWUDBAEqBBBMxK5x8CNp29AxpTpdjjZzBIGQFcjJotTUgue5zv1ZUiJE
    Fmp3LFInp0+mJmiSMM/WZUM2aALAG3xikB5xn0ENmtluiLVM+Osa5PZVj5WAisgN
    DBmHRYqFoxOQPc9L8DN8dr0PDM/d7KZe3Vr4FAlkG86R/aFOOn8yBX2DepDDmvuc
    aYn6abZZWe9uISi+Gk0r3Hna6cKz0K5M6ecGim6oBRg2
    -----END ENCRYPTED PRIVATE KEY-----
    Private-Key: (256 bit)
    priv:
	00:fc:ee:5b:91:0d:7b:11:c1:a3:6b:b6:45:e3:88:
	12:80:08:27:77:1b:3c:ad:59:4f:cd:10:42:f7:6e:
	53:4a:e9
    pub: 
	04:82:74:1c:da:70:65:e0:2d:3f:3b:8b:e4:10:e1:
	b0:60:b0:f8:59:9a:99:7d:a7:70:52:13:be:02:8d:
	c4:a0:56:9b:7f:79:ae:b8:ca:61:52:8c:74:06:59:
	72:10:77:6e:53:62:df:47:ef:af:64:47:97:73:cb:
	a6:f0:eb:a2:24
    ASN1 OID: prime256v1

-- 
	Viktor.

From m.r.sopacua at gmail.com  Sat Jan 14 21:53:20 2017
From: m.r.sopacua at gmail.com (Melvyn Sopacua)
Date: Sat, 14 Jan 2017 22:53:20 +0100
Subject: [openssl-users] RSA_method_set_sign
Message-ID: <4525401.EbsysoPbcS@devstation>

Hello all,

Some background: I'd like to have a workstation that uses OpenSSL 1.1 
instead of a lower version. For that I'm porting various pieces of 
software and quickly discovered that I was repeating myself. In addition 
this teaches me more about the OpenSSL library, which I consider a great 
benefit.
This resulted in me working on a forwards-compatibility library, using 
the OpenSSL Wiki as a guide and the KDE QCA library as a testbed. Work 
in progress can be seen at [1] and [2].

However, I believe I've now hit a brick wall:
Various functions in the realm RSA_method_set_* allow us to set 
callbacks for RSA operations. However, I see no way to implement these, 
since various (all?) X509 structures are now opaque. In addition, the 
default RSA_sign implementation calls the rsa_sign callback in the 
provided RSA structure, so we'll create an infinite loop if we wrap it 
like this:

RSA_method_set_sign(meth, my_rsa_sign);
int my_rsa_sign(...) {
	RSA_sign(...);
	store_state_on_our_object();
}

This is caused by the code in [3].
That file also shows the problem: OpenSSL itself has access to X509_SIG 
(and friends) internals as demonstrated in encode_pkcs1(). But, I don't 
see any way to setup the same context(s) from outside OpenSSL. There's 
no X509_*_set_<anything> to setup the algorithm and parameters.

Am I missing something or is it simply no longer possible to implement 
these callbacks properly?


[1] https://github.com/melvyn-sopacua/qca/tree/openssl11-compat
[2] https://github.com/melvyn-sopacua/openssl-fwcompat
[3] 
<https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_sign.c#L77>
-- 
Melvyn Sopacua

From ajaygargnsit at gmail.com  Sun Jan 15 03:44:42 2017
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sun, 15 Jan 2017 09:14:42 +0530
Subject: [openssl-users] Issues while "configuring before compiling" OpenSSL
	on Raspberry-Pi
Message-ID: <CAHP4M8W-wv88wUNoh0MB4EHOkxScZAAjFr+11hdEDQrPK0Vuvw@mail.gmail.com>

Hi All.

I am getting stuck on the first step of configuring OpenSSL.
Following are some of the diagnostics ::


OpenSSL-Version : *1.0.2d*


#########################################################################
pi at raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a*
Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l
GNU/Linux
#########################################################################


#########################################################################
pi at raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure linux-armv4*
Configuring for linux-armv4
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip
dir)
    no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
    no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
    no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
    no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
    no-shared       [default]
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
    no-store        [experimental] OPENSSL_NO_STORE (skip dir)
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
    no-zlib         [default]
    no-zlib-dynamic [default]
IsMK1MF=0
CC            =gcc
CFLAG         =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
-DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
EX_LIBS       =-ldl
CPUID_OBJ     =armcap.o armv4cpuid.o
BN_ASM        =bn_asm.o armv4-mont.o armv4-gf2m.o
EC_ASM        =
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4_enc.o rc4_skey.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =
SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
RMD160_OBJ_ASM=
CMLL_ENC      =camellia.o cmll_misc.o cmll_cbc.o
MODES_OBJ     =ghash-armv4.o ghashv8-armx.o
ENGINES_OBJ   =
PROCESSOR     =
RANLIB        =/usr/bin/ranlib
ARFLAGS       =
PERL          =/usr/bin/perl
THIRTY_TWO_BIT mode
DES_UNROLL used
DES_INT used
BN_LLONG mode
RC4 uses uchar
RC4_CHUNK is unsigned long
BF_PTR used
e_os2.h => include/openssl/e_os2.h
making links in crypto...
make[1]: Entering directory '/home/pi/instamsg-c/third_party/openssl/crypto'
crypto.h => ../include/openssl/crypto.h
opensslv.h => ../include/openssl/opensslv.h
opensslconf.h => ../include/openssl/opensslconf.h
ebcdic.h => ../include/openssl/ebcdic.h
symhacks.h => ../include/openssl/symhacks.h
ossl_typ.h => ../include/openssl/ossl_typ.h
constant_time_test.c => ../test/constant_time_test.c
making links in crypto/objects...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/objects'
objects.h => ../../include/openssl/objects.h
obj_mac.h => ../../include/openssl/obj_mac.h
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/objects'
making links in crypto/md4...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md4'
md4.h => ../../include/openssl/md4.h
md4test.c => ../../test/md4test.c
md4.c => ../../apps/md4.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md4'
making links in crypto/md5...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md5'
md5.h => ../../include/openssl/md5.h
md5test.c => ../../test/md5test.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/md5'
making links in crypto/sha...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/sha'
sha.h => ../../include/openssl/sha.h
shatest.c => ../../test/shatest.c
sha1test.c => ../../test/sha1test.c
sha256t.c => ../../test/sha256t.c
sha512t.c => ../../test/sha512t.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/sha'
making links in crypto/mdc2...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/mdc2'
mdc2.h => ../../include/openssl/mdc2.h
mdc2test.c => ../../test/mdc2test.c
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/mdc2'
making links in crypto/hmac...
make[2]: Entering directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/hmac'
make[2]: *** No rule to make target 'links'.  Stop.
make[2]: Leaving directory '/home/pi/instamsg-c/third_par
ty/openssl/crypto/hmac'
Makefile:95: recipe for target 'links' failed
make[1]: *** [links] Error 1
make[1]: Leaving directory '/home/pi/instamsg-c/third_party/openssl/crypto'
Makefile:433: recipe for target 'links' failed
make: *** [links] Error 1
#########################################################################


What am I missing?

Will be grateful for pointers.



Thanks and Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170115/e506d8da/attachment.html>

From norm.green at gemtalksystems.com  Sun Jan 15 03:47:20 2017
From: norm.green at gemtalksystems.com (Norm Green)
Date: Sat, 14 Jan 2017 19:47:20 -0800
Subject: [openssl-users] Encrypting using EC public key
Message-ID: <d2d36c05-2c1b-d9a6-6013-7a4a6b45cdab@gemtalksystems.com>

Is there a way to encrypt a file using the openssl command with an 
elliptic curve public key?  Here's what I get when I try using OpenSSL 
1.1.0c :

normg>./openssl pkeyutl -encrypt -pubin -inkey secp256k1-public-key.pem 
-in a.txt -out a.txt.enc
pkeyutl: Error initializing context
140339244734272:error:0608B096:digital envelope 
routines:EVP_PKEY_encrypt_init:operation not supported for this 
keytype:crypto/evp/pmeth_fn.c:139:

normg>cat secp256k1-public-key.pem
-----BEGIN PUBLIC KEY-----
MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE3bT9LIDRFNZ1D5QbA90zDh6UxDyYdrQv
XmxFEr1AwKnmeD8dAg4F62ddmzX76fNaw1QqLbmEQTLdrEYM3KxUdA==
-----END PUBLIC KEY-----


Norm Green

From matt at openssl.org  Mon Jan 16 09:35:10 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Jan 2017 09:35:10 +0000
Subject: [openssl-users] Encrypting using EC public key
In-Reply-To: <d2d36c05-2c1b-d9a6-6013-7a4a6b45cdab@gemtalksystems.com>
References: <d2d36c05-2c1b-d9a6-6013-7a4a6b45cdab@gemtalksystems.com>
Message-ID: <db4c3408-0b06-716d-5842-4eab15c5b916@openssl.org>



On 15/01/17 03:47, Norm Green wrote:
> Is there a way to encrypt a file using the openssl command with an
> elliptic curve public key?  Here's what I get when I try using OpenSSL
> 1.1.0c :

OpenSSL only supports ECDH (for key exchange) and ECDSA (for digital
signatures) for elliptic curve keys, i.e. there are no ec encryption
algorithms available.

Matt

> 
> normg>./openssl pkeyutl -encrypt -pubin -inkey secp256k1-public-key.pem
> -in a.txt -out a.txt.enc
> pkeyutl: Error initializing context
> 140339244734272:error:0608B096:digital envelope
> routines:EVP_PKEY_encrypt_init:operation not supported for this
> keytype:crypto/evp/pmeth_fn.c:139:
> 
> normg>cat secp256k1-public-key.pem
> -----BEGIN PUBLIC KEY-----
> MFYwEAYHKoZIzj0CAQYFK4EEAAoDQgAE3bT9LIDRFNZ1D5QbA90zDh6UxDyYdrQv
> XmxFEr1AwKnmeD8dAg4F62ddmzX76fNaw1QqLbmEQTLdrEYM3KxUdA==
> -----END PUBLIC KEY-----
> 
> 
> Norm Green

From mshirley at nsslabs.com  Mon Jan 16 14:14:23 2017
From: mshirley at nsslabs.com (Michael Shirley)
Date: Mon, 16 Jan 2017 14:14:23 +0000
Subject: [openssl-users] Disable ETM in OpenSSL 1.1.0+
Message-ID: <2B206FE1-A221-4B03-AE7E-17E4C19E9F48@nsslabs.com>

It appears that starting with OpenSSL 1.1.0, it is not possible to disable the Encrypt-Then-MAC (ETM) TLS extension for CBC ciphers. Is there an undocumented method to do this, which would also allow me to use the built-in s_server/s_client test mechanism?

Thanks,
-Mike

Michael Shirley
Senior Test Engineer
Office: (512) 498-7038 | Mobile:(512) 965-9004
mshirley at nsslabs.com

<http://mshirley at nsslabs.com/>
[s_logo_esig2.png]<https://www.nsslabs.com/>

  [itter_logo_esig_sm.png] <https://twitter.com/nsslabs>   [nkedin_logo_esig_sm.png] <https://www.linkedin.com/company/nss-labs>


[P Strategic Guidance Learn More]<http://sigstr.nsslabs.com/uc/586d0945825be97367c551f6>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/1cfc16a5/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 3594 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/1cfc16a5/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 715 bytes
Desc: image002.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/1cfc16a5/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 684 bytes
Desc: image003.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/1cfc16a5/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.png
Type: image/png
Size: 34299 bytes
Desc: image004.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/1cfc16a5/attachment-0007.png>

From matt at openssl.org  Mon Jan 16 15:00:54 2017
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Jan 2017 15:00:54 +0000
Subject: [openssl-users] Disable ETM in OpenSSL 1.1.0+
In-Reply-To: <2B206FE1-A221-4B03-AE7E-17E4C19E9F48@nsslabs.com>
References: <2B206FE1-A221-4B03-AE7E-17E4C19E9F48@nsslabs.com>
Message-ID: <2bcb1fe3-1741-56be-a7c9-5f15378e5cea@openssl.org>



On 16/01/17 14:14, Michael Shirley wrote:
> It appears that starting with OpenSSL 1.1.0, it is not possible to
> disable the Encrypt-Then-MAC (ETM) TLS extension for CBC ciphers. Is
> there an undocumented method to do this, which would also allow me to
> use the built-in s_server/s_client test mechanism?

This is a new feature in 1.1.0 that is on by default. Unfortunately
there is no way to disable it. That capability has since been added to
the master branch (so will be in 1.1.1) via this commit:

commit cde6145ba19a2fce039cf054a89e49f67c623c59
Author:     David Woodhouse <David.Woodhouse at intel.com>
AuthorDate: Fri Oct 14 00:26:38 2016 +0100
Commit:     Matt Caswell <matt at openssl.org>
CommitDate: Mon Oct 17 23:17:39 2016 +0100

    Add SSL_OP_NO_ENCRYPT_THEN_MAC

    Reviewed-by: Tim Hudson <tjh at openssl.org>
    Reviewed-by: Matt Caswell <matt at openssl.org>


Matt

From tedd.weyman at gmail.com  Mon Jan 16 16:05:50 2017
From: tedd.weyman at gmail.com (Tedd Weyman)
Date: Mon, 16 Jan 2017 11:05:50 -0500
Subject: [openssl-users] End user getting request to update OpenSSL
Message-ID: <CAB2rOkt_E+ydTuMpc2hL7i9Z7=_LAJfQuem+g7w-JRig_oZ1TA@mail.gmail.com>

I ran a Secunia update (set for auto update), and got a request to manually
go to OpenSSL to update. But OpenSSL does not provide updates for end
users. Anyone have an idea why such an update would not be automatic from
the downstream vendor, and how might I get the update myself?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/5ecf2c82/attachment.html>

From jb-openssl at wisemo.com  Mon Jan 16 16:27:09 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 16 Jan 2017 17:27:09 +0100
Subject: [openssl-users] End user getting request to update OpenSSL
In-Reply-To: <CAB2rOkt_E+ydTuMpc2hL7i9Z7=_LAJfQuem+g7w-JRig_oZ1TA@mail.gmail.com>
References: <CAB2rOkt_E+ydTuMpc2hL7i9Z7=_LAJfQuem+g7w-JRig_oZ1TA@mail.gmail.com>
Message-ID: <c7951684-9ef5-b147-9ef3-b11a4079248c@wisemo.com>

On 16/01/2017 17:05, Tedd Weyman wrote:
> I ran a Secunia update (set for auto update), and got a request to 
> manually go to OpenSSL to update. But OpenSSL does not provide updates 
> for end users. Anyone have an idea why such an update would not be 
> automatic from the downstream vendor, and how might I get the update 
> myself?
Who is your downstream vendor?

Note that Secunia is sometimes quite sloppy in their advisory
research.  For example I have been told I lack a Silverlight
update, when I have skipped an unrelated update to a different
part of Windows, which just happened to be released on the same
day as that Silverlight update.  This was via a third party
scanner who had purchased their advisory and detection data
from Secunia.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From openssl-users at dukhovni.org  Mon Jan 16 16:30:24 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 16 Jan 2017 11:30:24 -0500
Subject: [openssl-users] Encrypting using EC public key
In-Reply-To: <db4c3408-0b06-716d-5842-4eab15c5b916@openssl.org>
References: <d2d36c05-2c1b-d9a6-6013-7a4a6b45cdab@gemtalksystems.com>
 <db4c3408-0b06-716d-5842-4eab15c5b916@openssl.org>
Message-ID: <975481CE-2BD8-4B94-86E7-C3CA12E858D7@dukhovni.org>


> On Jan 16, 2017, at 4:35 AM, Matt Caswell <matt at openssl.org> wrote:
> 
> OpenSSL only supports ECDH (for key exchange) and ECDSA (for digital
> signatures) for elliptic curve keys, i.e. there are no ec encryption
> algorithms available.

That said, IIRC CMS supports EC public keys, by performing off-line
ECDH:

commit 88e20b8584a78c803eca7aa9fcf8c46ff0ece4ae
Author: Dr. Stephen Henson <steve at openssl.org>
Date:   Wed Jul 17 15:13:37 2013 +0100

    Add support for ECDH KARI.
    
    Add support for ECDH in enveloped data. The CMS ctrls for the EC ASN1
    method decode/encode the appropriate parameters from the CMS ASN1 data
    and send appropriate data to the EC public key method.

And further refinements in later commits.

-- 
	Viktor.


From mshirley at nsslabs.com  Mon Jan 16 17:17:25 2017
From: mshirley at nsslabs.com (Michael Shirley)
Date: Mon, 16 Jan 2017 17:17:25 +0000
Subject: [openssl-users] Disable ETM in OpenSSL 1.1.0+
In-Reply-To: <2bcb1fe3-1741-56be-a7c9-5f15378e5cea@openssl.org>
References: <2B206FE1-A221-4B03-AE7E-17E4C19E9F48@nsslabs.com>
 <2bcb1fe3-1741-56be-a7c9-5f15378e5cea@openssl.org>
Message-ID: <F7B4BEB1-2FD9-444E-8493-8C4B47E82E73@nsslabs.com>

I tested the master branch that adds this capability, but I?m apparently not using the right combination of flags to turn it off ? when I attempt s_client/s_server in the 1.1.1dev branch, I?m still seeing the ETM extension offered and negotiated for CBC suites. What would be the correct method to disable ETM using the master branch? 

Thanks,
-Mike

On 1/16/17, 9:00 AM, "openssl-users on behalf of Matt Caswell" <openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:

    
    
    On 16/01/17 14:14, Michael Shirley wrote:
    > It appears that starting with OpenSSL 1.1.0, it is not possible to
    > disable the Encrypt-Then-MAC (ETM) TLS extension for CBC ciphers. Is
    > there an undocumented method to do this, which would also allow me to
    > use the built-in s_server/s_client test mechanism?
    
    This is a new feature in 1.1.0 that is on by default. Unfortunately
    there is no way to disable it. That capability has since been added to
    the master branch (so will be in 1.1.1) via this commit:
    
    commit cde6145ba19a2fce039cf054a89e49f67c623c59
    Author:     David Woodhouse <David.Woodhouse at intel.com>
    AuthorDate: Fri Oct 14 00:26:38 2016 +0100
    Commit:     Matt Caswell <matt at openssl.org>
    CommitDate: Mon Oct 17 23:17:39 2016 +0100
    
        Add SSL_OP_NO_ENCRYPT_THEN_MAC
    
        Reviewed-by: Tim Hudson <tjh at openssl.org>
        Reviewed-by: Matt Caswell <matt at openssl.org>
    
    
    Matt
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4549 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170116/c180a9ff/attachment.bin>

From getmithunp at gmail.com  Tue Jan 17 06:44:59 2017
From: getmithunp at gmail.com (Mithun P)
Date: Tue, 17 Jan 2017 12:14:59 +0530
Subject: [openssl-users] RSA Key generation time
Message-ID: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>

Hi

I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
I am generating RSA 2048 and 3072 bit key pairs.
I am providing entropy to openssl by using RAND_seed from a HW RNG.

My average generation time for RSA 2048 key pair is 2 Minutes and  3072 is
8 minutes.
Is there a way to reduce the generation time?

Regards
Mithun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170117/61f0ca0a/attachment-0001.html>

From lmpmbernardo at gmail.com  Tue Jan 17 07:24:10 2017
From: lmpmbernardo at gmail.com (Luis Bernardo)
Date: Tue, 17 Jan 2017 08:24:10 +0100
Subject: [openssl-users] Fwd: CMS_NOATTR and CMS_SignerInfo_sign
In-Reply-To: <mailman.1508.1484605103.1806.openssl-users@openssl.org>
References: <mailman.1508.1484605103.1806.openssl-users@openssl.org>
Message-ID: <CAO3yRHu1G_B533t4rD-czTKXh=ncPnY6eWFOhdK6LcDNeWqHig@mail.gmail.com>

Hello,

I have been unable to prevent CMS_SignerInfo_sign() to add a signing time
attribute even though I used CMS_NOATTR. I think the issue is here:

if (CMS_signed_get_attr_by_NID(si, NID_pkcs9_signingTime, -1) < 0) {
if (!cms_add1_signingTime(si, NULL))
goto err;
}

This is around line 648 of crypto/cms/cms_sd.c.

It seems to me that no matter what, the signing time attribute will be
added if not present. If I comment out the above lines I get the result I
want, which is no signing time attribute, but maybe I am not using the
flags correctly.

Can someone comment?

Thanks,
Luis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170117/0425bbfc/attachment.html>

From jb-openssl at wisemo.com  Tue Jan 17 16:08:57 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 17 Jan 2017 17:08:57 +0100
Subject: [openssl-users] RSA Key generation time
In-Reply-To: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
References: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
Message-ID: <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>

On 17/01/2017 07:44, Mithun P wrote:
> Hi
>
> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
> I am generating RSA 2048 and 3072 bit key pairs.
> I am providing entropy to openssl by using RAND_seed from a HW RNG.
>
> My average generation time for RSA 2048 key pair is 2 Minutes and 
>  3072 is 8 minutes.
> Is there a way to reduce the generation time?
>
I believe this is a CPU intensive operation (if VxWorks can do
this, try observing the CPU load during).

Potential improvements:

1. Check if the CPU specific bignum optimizations for your CPU
   variant have been enabled via the libcrypto CPU detection code
   (for example, there are optimizations for different ARM cortex
   variants).
2. Faster CPU (expensive obviously).
3. Do the generation in the background before the keypair is
   needed, at a time when the extra CPU load is less of a problem.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From sj at gleebees.com  Wed Jan 18 15:43:53 2017
From: sj at gleebees.com (=?utf-8?Q?Sophie_Jacquin?=)
Date: Wed, 18 Jan 2017 16:43:53 +0100
Subject: [openssl-users] oppenssl error when connecting to a mosquitto
 broker with tls security
Message-ID: <zarafa.587f8d39.0d6f.4485ef266be8480f@hive.gleebees.com>

Hello,

We try to use mosquitto mqtt messages with tls security protocol.

To do so, we follow the following tutorial:

https://primalcortex.wordpress.com/2016/03/31/mqtt-mosquitto-broker-with-ssltls-transport-security/


 

to generate the authority certificate file and the server certificate we use this script https://github.com/owntracks/tools/blob/master/TLS/generate-CA.sh

This tutorial seems complete and well done as we successfully connect several machines by following this method. Nevertheless when trying to configure the broker on our server we encounter several problems.

In the server the mosquitto.conf content is :


 

# A full description of the configuration file is at

# /usr/share/doc/mosquitto/examples/mosquitto.conf.example

pid_file /var/run/mosquitto.pid
 

persistence true

persistence_location /var/lib/mosquitto/
 

log_dest file /var/log/mosquitto/mosquitto.log
 

listener 8884

cafile /etc/mosquitto/certs3/ca.crt

certfile /etc/mosquitto/certs3/server.crt

keyfile /etc/mosquitto/certs3/server.key


 

Mosquitto version is 1.4.10 and Openssl version is 1.0.2j

When trying to subcribe or publish on port 8884 locally (ie from a client also on the server), no problem, the connection success.

But when we try to connect from an other machine we get different error if we use command line or

mosqutto C library

- With command line

mosquitto_pub -h xxx.xxx.com -t test -m "hello word" --cafile /etc/mosquitto/certs/ca.crt -p 8884

On server log file


 

1484748728: OpenSSL Error: error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert certificate unknown

And ssldump gives the following exit:


 

0.0384 (0.0384) C>S Handshake

 ClientHello

 Version 3.3 

 cipher suites

 Unknown value 0xc030

 Unknown value 0xc02c

 Unknown value 0xc028

 Unknown value 0xc024

 Unknown value 0xc014

 Unknown value 0xc00a

 Unknown value 0xa3

 Unknown value 0x9f

 Unknown value 0x6b

 Unknown value 0x6a

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA

 TLS_DHE_DSS_WITH_AES_256_CBC_SHA

 Unknown value 0x88

 Unknown value 0x87

 Unknown value 0xc032

 Unknown value 0xc02e

 Unknown value 0xc02a

 Unknown value 0xc026

 Unknown value 0xc00f

 Unknown value 0xc005

 Unknown value 0x9d

 Unknown value 0x3d

 TLS_RSA_WITH_AES_256_CBC_SHA

 Unknown value 0x84

 Unknown value 0xc02f

 Unknown value 0xc02b

 Unknown value 0xc027

 Unknown value 0xc023

 Unknown value 0xc013

 Unknown value 0xc009

 Unknown value 0xa2

 Unknown value 0x9e

 TLS_DHE_DSS_WITH_NULL_SHA

 Unknown value 0x40

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA

 Unknown value 0x9a

 Unknown value 0x99

 Unknown value 0x45

 Unknown value 0x44

 Unknown value 0xc031

 Unknown value 0xc02d

 Unknown value 0xc029

 Unknown value 0xc025

 Unknown value 0xc00e

 Unknown value 0xc004

 Unknown value 0x9c

 Unknown value 0x3c

 TLS_RSA_WITH_AES_128_CBC_SHA

 Unknown value 0x96

 Unknown value 0x41

 Unknown value 0xc011

 Unknown value 0xc007

 Unknown value 0xc00c

 Unknown value 0xc002

 TLS_RSA_WITH_RC4_128_SHA

 TLS_RSA_WITH_RC4_128_MD5

 Unknown value 0xc012

 Unknown value 0xc008

 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

 Unknown value 0xc00d

 Unknown value 0xc003

 TLS_RSA_WITH_3DES_EDE_CBC_SHA

 Unknown value 0xff

 compression methods

 NULL

1 2 0.0415 (0.0030) S>C Handshake

 ServerHello

 Version 3.3 

 session_id[0]=


 

 cipherSuite Unknown value 0xc030

 compressionMethod NULL

1 3 0.0415 (0.0000) S>C Handshake

 Certificate

1 4 0.0415 (0.0000) S>C Handshake

 ServerKeyExchange

1 5 0.0415 (0.0000) S>C Handshake

 ServerHelloDone

1 6 0.0783 (0.0368) C>S Alert

 level fatal

 value certificate_unknown

1 0.0785 (0.0002) S>C TCP FIN

We try and get the same result with machine on which openssl 1.0.2j is installed with mosquitto 1.4.10 than on a machine on which oppenssl 1.0.1t is installed with mosquitto version 1.3.4.

when using the insecure option, it is working well

mosquitto_pub -h xx.xxx.com -t test -m "hello word" --cafile /etc/mosquitto/certs/ca.crt -p 8884 ?insecure

but it is not our goal.

-When using C mosquitto library :

openssl-1.1.0c

mosquitto 1.4.10

c-code implementation:

?
? ? err = mosquitto_tls_set(poMosq,

? ? ? "/etc/mosquitto/certs/ca.crt",

? ? ? "/etc/mosquitto/certs/",?

? ? ? NULL,

? ? ? NULL,

? ? ? NULL

? ? );


 


 


 

1484747462: OpenSSL Error: error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error


 


 


 

 C>S Handshake

 ClientHello

 Version 3.3 

 cipher suites

 Unknown value 0xc030

 Unknown value 0xc02c

 Unknown value 0xc028

 Unknown value 0xc024

 Unknown value 0xc014

 Unknown value 0xc00a

 Unknown value 0xa5

 Unknown value 0xa3

 Unknown value 0xa1

 Unknown value 0x9f

 Unknown value 0x6b

 Unknown value 0x6a

 Unknown value 0x69

 Unknown value 0x68

 TLS_DHE_RSA_WITH_AES_256_CBC_SHA

 TLS_DHE_DSS_WITH_AES_256_CBC_SHA

 TLS_DH_RSA_WITH_AES_256_CBC_SHA

 TLS_DH_DSS_WITH_AES_256_CBC_SHA

 Unknown value 0x88

 Unknown value 0x87

 Unknown value 0x86

 Unknown value 0x85

 Unknown value 0xc032

 Unknown value 0xc02e

 Unknown value 0xc02a

 Unknown value 0xc026

 Unknown value 0xc00f

 Unknown value 0xc005

 Unknown value 0x9d

 Unknown value 0x3d

 TLS_RSA_WITH_AES_256_CBC_SHA

 Unknown value 0x84

 Unknown value 0xc02f

 Unknown value 0xc02b

 Unknown value 0xc027

 Unknown value 0xc023

 Unknown value 0xc013

 Unknown value 0xc009

 Unknown value 0xa4

 Unknown value 0xa2

 Unknown value 0xa0

 Unknown value 0x9e

 TLS_DHE_DSS_WITH_NULL_SHA

 Unknown value 0x40

 Unknown value 0x3f

 Unknown value 0x3e

 TLS_DHE_RSA_WITH_AES_128_CBC_SHA

 TLS_DHE_DSS_WITH_AES_128_CBC_SHA

 TLS_DH_RSA_WITH_AES_128_CBC_SHA

 TLS_DH_DSS_WITH_AES_128_CBC_SHA

 Unknown value 0x9a

 Unknown value 0x99

 Unknown value 0x98

 Unknown value 0x97

 Unknown value 0x45

 Unknown value 0x44

 Unknown value 0x43

 Unknown value 0x42

 Unknown value 0xc031

 Unknown value 0xc02d

 Unknown value 0xc029

 Unknown value 0xc025

 Unknown value 0xc00e

 Unknown value 0xc004

 Unknown value 0x9c

 Unknown value 0x3c

 TLS_RSA_WITH_AES_128_CBC_SHA

 Unknown value 0x96

 Unknown value 0x41

 TLS_RSA_WITH_IDEA_CBC_SHA

 Unknown value 0xc011

 Unknown value 0xc007

 Unknown value 0xc00c

 Unknown value 0xc002

 TLS_RSA_WITH_RC4_128_SHA

 TLS_RSA_WITH_RC4_128_MD5

 Unknown value 0xc012

 Unknown value 0xc008

 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA

 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

 TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

 TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA

 Unknown value 0xc00d

 Unknown value 0xc003

 TLS_RSA_WITH_3DES_EDE_CBC_SHA

 Unknown value 0xff

 compression methods

 NULL

1 2 0.0426 (0.0032) S>C Handshake

 ServerHello

 Version 3.3 

 session_id[0]=



 cipherSuite Unknown value 0xc030t

 compressionMethod NULL

1 3 0.0426 (0.0000) S>C Handshake

 Certificate

1 4 0.0426 (0.0000) S>C Handshake

 ServerKeyExchange

1 5 0.0426 (0.0000) S>C Handshake

 ServerHelloDone

1 6 0.0770 (0.0344) C>S Alert

 level fatal





We check if the common name on the certificate server is good and it corresponds to the hostname used to connect the server, so the problem does not seems to come from here.



We will be very grateful if you could give us some ideas about how to debug this problem.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170118/2fc733ba/attachment-0001.html>

From a.chris.clark at gmail.com  Wed Jan 18 23:30:12 2017
From: a.chris.clark at gmail.com (Chris Clark)
Date: Wed, 18 Jan 2017 15:30:12 -0800
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
Message-ID: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>

I am trying to compile OpenSSL 1.1.0c for Visual Studio with the
depreciated RC4 cipher enabled.

I tried the following configure line:
perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-deprecated enable-rc4


Once I compile, and I run "openssl cipher -v" it does not show any RC4 ciphers.
Is there another parameter needed?

I would also like to know, is it possible to also enable the
depreciated SSL3 ciphers?

-Chris

From openssl-users at dukhovni.org  Wed Jan 18 23:37:28 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Jan 2017 23:37:28 +0000
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
Message-ID: <20170118233728.GJ22199@mournblade.imrryr.org>

On Wed, Jan 18, 2017 at 03:30:12PM -0800, Chris Clark wrote:

> I am trying to compile OpenSSL 1.1.0c for Visual Studio with the
> depreciated RC4 cipher enabled.

The "Configure" script includes embedded documentation for the
available options.

    # enable-weak-ssl-ciphers
    #               Enable weak ciphers that are disabled by default. This currently
    #               only includes RC4 based ciphers.

> I tried the following configure line:
> perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-deprecated enable-rc4
> 
> 
> Once I compile, and I run "openssl cipher -v" it does not show any RC4 ciphers.
> Is there another parameter needed?

Which "openssl" command did you run and against which libraries?
Report the output of "openssl version -a".

> I would also like to know, is it possible to also enable the
> depreciated SSL3 ciphers?

Do you mean the ciphers or the protocol?  Many SSLv3 ciphers are
still needed for interoperable TLS 1.0/1.1/1.2

-- 
	Viktor.

From a.chris.clark at gmail.com  Thu Jan 19 01:29:17 2017
From: a.chris.clark at gmail.com (Chris Clark)
Date: Wed, 18 Jan 2017 17:29:17 -0800
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <20170118233728.GJ22199@mournblade.imrryr.org>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
Message-ID: <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>

On Wed, Jan 18, 2017 at 3:37 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:

>> I am trying to compile OpenSSL 1.1.0c for Visual Studio with the
> >depreciated RC4 cipher enabled.

>> I tried the following configure line:
>> perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-deprecated enable-rc4
>>
> > Once I compile, and I run "openssl ciphers -v" it does not show any RC4 ciphers.
> > Is there another parameter needed?
>
> Which "openssl" command did you run and against which libraries?
> Report the output of "openssl version -a".

OpenSSL 1.1.0c  10 Nov 2016
built on: reproducible build, date unspecified
platform:
compiler: cl " "VC-WIN64A
OPENSSLDIR: "c:\openssl64"
ENGINESDIR: "C:\openssl64\lib\engines-1_1"


Here is the batch file I used:
SET PREFIX=C:\openssl64
SET OPENSSLDIR=C:\openssl64
perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-deprecated enable-rc4
nmake

>> I would also like to know, is it possible to also enable the depreciated SSL3
>> ciphers?
>
> Do you mean the ciphers or the protocol?  Many SSLv3 ciphers are
> still needed for interoperable TLS 1.0/1.1/1.2

Sorry, I meant to say the SSLv3 protocol.

-Chris

From openssl-users at dukhovni.org  Thu Jan 19 03:01:46 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 18 Jan 2017 22:01:46 -0500
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
 <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
Message-ID: <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>


> On Jan 18, 2017, at 8:29 PM, Chris Clark <a.chris.clark at gmail.com> wrote:
> 
> OpenSSL 1.1.0c  10 Nov 2016
> built on: reproducible build, date unspecified
> platform:
> compiler: cl " "VC-WIN64A
> OPENSSLDIR: "c:\openssl64"
> ENGINESDIR: "C:\openssl64\lib\engines-1_1"

Sadly this does not shed much light on the build options.

>>> I would also like to know, is it possible to also enable the depreciated SSL3
>>> ciphers?
>> 
>> Do you mean the ciphers or the protocol?  Many SSLv3 ciphers are
>> still needed for interoperable TLS 1.0/1.1/1.2
> 
> Sorry, I meant to say the SSLv3 protocol.

For that "enable-ssl3" and "enable-ssl3-method".

-- 
	Viktor.


From rsalz at akamai.com  Thu Jan 19 13:41:55 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Jan 2017 13:41:55 +0000
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
Message-ID: <d69003b0feb5499992eec1babe64aa0d@usma1ex-dag1mb1.msg.corp.akamai.com>

> Once I compile, and I run "openssl cipher -v" it does not show any RC4
> ciphers.
> Is there another parameter needed?

In addition to what Viktor said, you need to say "ALL" because RC4 is still not part of DEFAULT.

From richard.collins at bristol.ac.uk  Thu Jan 19 15:04:45 2017
From: richard.collins at bristol.ac.uk (Richard Collins)
Date: Thu, 19 Jan 2017 15:04:45 +0000
Subject: [openssl-users] Adding new key exchange to OpenSSL
Message-ID: <5cf2a9c1-8be5-9eaf-cfc4-bbd4e8c02d36@bristol.ac.uk>

Hello

I'm looking at adding functionality to OpenSSL and need some help with
where to start.
I'd like to add a component to OpenSSL, ether externally to the library
or by modifying the library, which provides symmetric key to the
encryption algorithms. I'm hoping to be able to insert my key generator
into the system using the cypher description to modify the key exchange,
rather than EDH for example.

Any pointers in the right direction would be greatly appreciated.

-- 

Richard Collins
Senior Research Associate in Networks
University of Bristol
MVB G0.01
Bristol
Email: Richard.Collins at bristol.ac.uk



From rsalz at akamai.com  Thu Jan 19 15:06:49 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Jan 2017 15:06:49 +0000
Subject: [openssl-users] Adding new key exchange to OpenSSL
In-Reply-To: <5cf2a9c1-8be5-9eaf-cfc4-bbd4e8c02d36@bristol.ac.uk>
References: <5cf2a9c1-8be5-9eaf-cfc4-bbd4e8c02d36@bristol.ac.uk>
Message-ID: <c7484992637041f7993f24bed9913399@usma1ex-dag1mb1.msg.corp.akamai.com>

Look at the PSK ciphers; the callbacks should be able to call your generator...

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz

From richard.collins at bristol.ac.uk  Thu Jan 19 16:07:17 2017
From: richard.collins at bristol.ac.uk (Richard Collins)
Date: Thu, 19 Jan 2017 16:07:17 +0000
Subject: [openssl-users] Adding new key exchange to OpenSSL
In-Reply-To: <c7484992637041f7993f24bed9913399@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <5cf2a9c1-8be5-9eaf-cfc4-bbd4e8c02d36@bristol.ac.uk>
 <c7484992637041f7993f24bed9913399@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <3c8bab9b-28fd-68bf-caa4-c6bed11e04b2@bristol.ac.uk>

Thankyou, the SSL_*_set_psk_*_callback functions look like they're
exactly what I need. I just need to work out which callbacks to use.


On 19/01/17 15:06, Salz, Rich wrote:
> Look at the PSK ciphers; the callbacks should be able to call your generator...
>
> --  
> Senior Architect, Akamai Technologies
> Member, OpenSSL Dev Team
> IM: richsalz at jabber.at Twitter: RichSalz

-- 

Richard Collins
Senior Research Associate in Networks
University of Bristol
MVB G0.01
Bristol
Email: Richard.Collins at bristol.ac.uk


From a.chris.clark at gmail.com  Thu Jan 19 17:59:14 2017
From: a.chris.clark at gmail.com (Chris Clark)
Date: Thu, 19 Jan 2017 09:59:14 -0800
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
 <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
 <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>
Message-ID: <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>

On Wed, Jan 18, 2017 at 7:01 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:

> Sadly this does not shed much light on the build options.

Here is more info, and now I added the "enable-ssl3" and
"enable-ssl3-method" options:

c:\openssl-1.1.0c64>perl Configure VC-WIN64A enable-weak-ssl-ciphers
enable-deprecated enable-rc4 enable-ssl3 enable-ssl3-method
Configuring OpenSSL version 1.1.0c (0x1010003fL)
    no-asan         [default]  OPENSSL_NO_ASAN
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for VC-WIN64A

It looks like you don't have either nmake.exe or dmake.exe on your PATH,
so you will not be able to execute the commands from a Makefile.  You can
install dmake.exe with the Perl Package Manager by running:
    ppm install dmake

CC            =cl
CFLAG         =-W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE
-D_UNICODE /MD /O2
SHARED_CFLAG  =
DEFINES       =OPENSSL_USE_APPLINK DSO_WIN32 NDEBUG OPENSSL_THREADS
OPENSSL_NO_STATIC_ENGINE OPENSSL_PIC OPENSSL_IA32_SSE2
OPENSSL_BN_ASM_MONT OPENSSL_BN_ASM_MONT5 OPENSSL_BN_ASM_GF2m SHA1_ASM
SHA256_ASM SHA512_ASM RC4_ASM MD5_ASM AES_ASM VPAES_ASM BSAES_ASM
GHASH_ASM ECP_NISTZ256_ASM POLY1305_ASM
LFLAG         =/nologo /debug
PLIB_LFLAG    =
EX_LIBS       =ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib
APPS_OBJ      =win32_init.o ../ms/applink.o
CPUID_OBJ     =x86_64cpuid.o
UPLINK_OBJ    =../ms/uplink.o uplink-x86_64.o
BN_ASM        =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o
EC_ASM        =ecp_nistz256.o ecp_nistz256-x86_64.o
DES_ENC       =des_enc.o fcrypt_b.o
AES_ENC       =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
aesni-mb-x86_64.o
BF_ENC        =bf_enc.o
CAST_ENC      =c_enc.o
RC4_ENC       =rc4-x86_64.o rc4-md5-x86_64.o
RC5_ENC       =rc5_enc.o
MD5_OBJ_ASM   =md5-x86_64.o
SHA1_OBJ_ASM  =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o
RMD160_OBJ_ASM=
CMLL_ENC      =cmll-x86_64.o cmll_misc.o
MODES_OBJ     =ghash-x86_64.o aesni-gcm-x86_64.o
PADLOCK_OBJ   =e_padlock-x86_64.o
CHACHA_ENC    =chacha-x86_64.o
POLY1305_OBJ  =poly1305-x86_64.o
BLAKE2_OBJ    =
PROCESSOR     =
RANLIB        =true
ARFLAGS       =/nologo
PERL          =c:\perl\bin\perl.exe
SIXTY_FOUR_BIT mode
Configured for VC-WIN64A.


Notice it says that dmake.exe is not in my path, but this appears to
be a bug as I am running this from a Visual Studio 2008 x64 Command
Prompt, and nmake.exe is indeed in the path, located in:
c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64

Here is the batch file which I use:
SET PREFIX=C:\openssl64
SET OPENSSLDIR=C:\openssl64
perl Configure VC-WIN64A enable-weak-ssl-ciphers enable-deprecated
enable-rc4 enable-ssl3 enable-ssl3-method
nmake


Here is my development environment:
Windows 10 Professional
Visual Studio 2008 version 9.0.30729.1 SP1
ActivePerl version 5.22.2
NASM version 2.12.02

nmake compiles without errors, though there are many "conversion from
size_t" warnings.
The results of running "openssl.exe ciphers -v" which I do not find
any RC4 ciphers:

ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(256) Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK
Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA384
ECDHE-PSK-AES256-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(256)  Mac=SHA1
SRP-RSA-AES-256-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(256)  Mac=SHA1
SRP-AES-256-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(256)  Mac=SHA1
RSA-PSK-AES256-CBC-SHA384 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA384
DHE-PSK-AES256-CBC-SHA384 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA384
RSA-PSK-AES256-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-PSK-AES256-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(256)  Mac=SHA1
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
PSK-AES256-CBC-SHA384   TLSv1 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA384
PSK-AES256-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(256)  Mac=SHA1
ECDHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA256
ECDHE-PSK-AES128-CBC-SHA SSLv3 Kx=ECDHEPSK Au=PSK  Enc=AES(128)  Mac=SHA1
SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=AES(128)  Mac=SHA1
SRP-AES-128-CBC-SHA     SSLv3 Kx=SRP      Au=SRP  Enc=AES(128)  Mac=SHA1
RSA-PSK-AES128-CBC-SHA256 TLSv1 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-PSK-AES128-CBC-SHA256 TLSv1 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA256
RSA-PSK-AES128-CBC-SHA  SSLv3 Kx=RSAPSK   Au=RSA  Enc=AES(128)  Mac=SHA1
DHE-PSK-AES128-CBC-SHA  SSLv3 Kx=DHEPSK   Au=PSK  Enc=AES(128)  Mac=SHA1
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
PSK-AES128-CBC-SHA256   TLSv1 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA256
PSK-AES128-CBC-SHA      SSLv3 Kx=PSK      Au=PSK  Enc=AES(128)  Mac=SHA1

-Chris

From matt at openssl.org  Thu Jan 19 18:36:44 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 19 Jan 2017 18:36:44 +0000
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
 <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
 <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>
 <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>
Message-ID: <7de59d53-089e-b20c-c697-516a95b9dcdc@openssl.org>



On 19/01/17 17:59, Chris Clark wrote:
> On Wed, Jan 18, 2017 at 7:01 PM, Viktor Dukhovni
> <openssl-users at dukhovni.org> wrote:
> 
>> Sadly this does not shed much light on the build options.
> 
> Here is more info, and now I added the "enable-ssl3" and
> "enable-ssl3-method" options:

If all you want is RC4 (which you can have without SSLv3 if you want
it), then all you need to add is enable-weak-ssl-ciphers


> It looks like you don't have either nmake.exe or dmake.exe on your PATH,
> so you will not be able to execute the commands from a Makefile.  You can
> install dmake.exe with the Perl Package Manager by running:
>     ppm install dmake
...
> 
> Notice it says that dmake.exe is not in my path, but this appears to
> be a bug as I am running this from a Visual Studio 2008 x64 Command
> Prompt, and nmake.exe is indeed in the path, located in:
> c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64

That message doesn't come from OpenSSL. It's a bug in perl.


thout errors, though there are many "conversion from
> size_t" warnings.
> The results of running "openssl.exe ciphers -v" which I do not find
> any RC4 ciphers:

Try this:

openssl ciphers -v "ALL:@SECLEVEL=0"

Matt

From bkaduk at akamai.com  Thu Jan 19 18:37:12 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Thu, 19 Jan 2017 12:37:12 -0600
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
 <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
 <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>
 <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>
Message-ID: <0933a5a6-99e3-e384-74de-d2846a8fd362@akamai.com>

On 01/19/2017 11:59 AM, Chris Clark wrote:
> Notice it says that dmake.exe is not in my path, but this appears to
> be a bug as I am running this from a Visual Studio 2008 x64 Command
> Prompt, and nmake.exe is indeed in the path, located in:
> c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64

This is a known bug; something about "use Config;" triggers it but no
one figured out a way to prevent it from happening.
(https://mta.openssl.org/pipermail/openssl-users/2017-January/005071.html)

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170119/cd358f78/attachment.html>

From a.chris.clark at gmail.com  Thu Jan 19 19:26:12 2017
From: a.chris.clark at gmail.com (Chris Clark)
Date: Thu, 19 Jan 2017 11:26:12 -0800
Subject: [openssl-users] How to enable RC4 in OpenSSL 1.1.0c
In-Reply-To: <7de59d53-089e-b20c-c697-516a95b9dcdc@openssl.org>
References: <CACaGmvDV_8JcS6Yyx24UBP-O3QrjCttKN1e0v5k7ed_9gtPzjg@mail.gmail.com>
 <20170118233728.GJ22199@mournblade.imrryr.org>
 <CACaGmvB3Nd9UOFe0h2a+aFThYPSbUW4ZSjx4CqH8hP8HV6=8gA@mail.gmail.com>
 <CF2F0EDD-531C-47F2-9B1D-9A99C919503C@dukhovni.org>
 <CACaGmvABU28aCO3UZKThKSRDq=Xu=_h9YTqaoYPFizE5CT3mMg@mail.gmail.com>
 <7de59d53-089e-b20c-c697-516a95b9dcdc@openssl.org>
Message-ID: <CACaGmvCWd1geMt=eEfGOSosW8i1xr3EoqZKKE-YRFP998GuiXg@mail.gmail.com>

On Thu, Jan 19, 2017 at 10:36 AM, Matt Caswell <matt at openssl.org> wrote:

> Try this:
>
> openssl ciphers -v "ALL:@SECLEVEL=0"

Okay that worked! Thanks to everyone that responded. I saw Rich Salz
mentioned using ALL, but I didn't realize it was a parameter.

-Chris

From openssl.org at 18informatique.com  Sun Jan 22 22:12:06 2017
From: openssl.org at 18informatique.com (mlrx)
Date: Sun, 22 Jan 2017 23:12:06 +0100
Subject: [openssl-users] stronger Kex
In-Reply-To: <47c51e6f-e0c7-a51b-14c6-b1c4c2d3a8f3@wisemo.com>
References: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com>
 <7c90e857-4960-2aab-eab4-42579eb88224@18informatique.com>
 <47c51e6f-e0c7-a51b-14c6-b1c4c2d3a8f3@wisemo.com>
Message-ID: <825db652-00b2-ac0c-dc62-561e3c13ad7a@18informatique.com>

Hello,
Thank you for this very useful explanation and your time.
I apologize for the delay in response.
Best regards,
benoist.

Le 27/12/2016 ? 10:16, Jakob Bohm wrote :
> On 27/12/2016 09:15, mlrx wrote:
>> Le 21/12/2016 ? 16:07, mlrx a ?crit :
>>> Hello,
>>>
>>> I have two servers for testing purpose :
>>> - debian 6, apache 2.2,   openssl 1.0.1t      (mutu)
>>> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>>>
>>> Now, these 2 serveurs offers only those ciphers :
>>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>>
>>> I have two goals. First, I would like to use at least secp384r1
>>> and second (no problem), use an ECC certificate.
>>>
>>> Is it possible to do it with CHACHA20-POLY1305 ?
>>> Is it possible to use this cipher on those servers ?
>>>
>>> openssl ciphers -V CHACHA20 return an error on each server.
>>> I understand it's because there is no chacha20 cipher (?).
>>>
>>> Why can I connect a server by SSH with chacha20-poly1305 at openssh.com
>>> and not using it with Apache ?
>>>
>>> All advices are welcome :-).
>>>
>>> Best regards,
>> Hello,
>> Is somebody could explain me the difference between a message who
>> received an answer and this one ?
>> What's wrong ? RTFM ?
> Even though at least one SSH program (OpenSSH) uses the crypto functions
> from the OpenSSL libcrypto, the SSH protocol is completely unrealted to
> the SSL/TLS security protocol.
> 
> So the ability to use specific settings with SSH is almost completely
> unrelated to the ability to use similarly named settings for SSL.
> 
> One major difference is that SSH identifies cryptographic suites by
> strings that can easily be extended by organizations such as openssh.com.
> 
> In contrast, SSL/TLS identifies cryptographic suites by 16 bit numbers
> specified in RFCs and listed in a table published by IANA/ICANN. Thus
> for SSL/TLS libraries such as OpenSSL can really only provide choices
> that were given an official number in an RFC and added to that table
> as part of the RFC publishing process.
> 
> On top of that, the OpenSSL team has a policy of only implementing new
> SSL/TLS cryptographic suites when the number part of the OpenSSL version
> number changes.  Thus anything not included in the original OpenSSL
> 1.0.2 release will only be available in 1.1.0 or an even later release
> (because they will not be making a 1.0.3 release).  Similarly anything
> not in the original 1.1.0 release will only be in 1.2.0 or later
> (assuming there is no 1.1.1 release).
> 
> Enjoy
> 
> Jakob


-- 
benoist

-- 
benoist

From openssl.org at 18informatique.com  Sun Jan 22 22:12:20 2017
From: openssl.org at 18informatique.com (mlrx)
Date: Sun, 22 Jan 2017 23:12:20 +0100
Subject: [openssl-users] stronger Kex
In-Reply-To: <CAH8yC8n09NOcKQ1MxvGt=8Qa-HutgHA_StM50dJ1d5omAJM=tw@mail.gmail.com>
References: <7b0a0592-9820-f334-01c6-8109469f0fd6@18informatique.com>
 <CAH8yC8n09NOcKQ1MxvGt=8Qa-HutgHA_StM50dJ1d5omAJM=tw@mail.gmail.com>
Message-ID: <ef9d8323-2924-67fd-6040-aca252f257ec@18informatique.com>

Hello,
I also thank you. It was useful to.
Best regards.
benoist

Le 27/12/2016 ? 17:38, Jeffrey Walton wrote :
>> I have two servers for testing purpose :
>> - debian 6, apache 2.2,   openssl 1.0.1t      (mutu)
>> - centos 7, apache 2.4.6, openssl 1.0.1e-fips (dedicated)
>>
>> Now, these 2 serveurs offers only those ciphers :
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
>>
>> I have two goals. First, I would like to use at least secp384r1
>> and second (no problem), use an ECC certificate.
>>
>> Is it possible to do it with CHACHA20-POLY1305 ?
>> Is it possible to use this cipher on those servers ?
> 
> You need OpenSSL 1.1.0 or above for ChaCha20/Poly1305:
> 
> $ openssl version
> OpenSSL 1.1.0b  26 Sep 2016
> 
> $ openssl ciphers | tr ':' '\n' | grep -i chacha
> ECDHE-ECDSA-CHACHA20-POLY1305
> ECDHE-RSA-CHACHA20-POLY1305
> DHE-RSA-CHACHA20-POLY1305
> RSA-PSK-CHACHA20-POLY1305
> DHE-PSK-CHACHA20-POLY1305
> ECDHE-PSK-CHACHA20-POLY1305
> PSK-CHACHA20-POLY1305
> 
> Jeff
> 


-- 
benoist

From getmithunp at gmail.com  Mon Jan 23 07:09:00 2017
From: getmithunp at gmail.com (Mithun P)
Date: Mon, 23 Jan 2017 12:39:00 +0530
Subject: [openssl-users] RSA Key generation time
In-Reply-To: <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>
References: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
 <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>
Message-ID: <CAMzucFSQZuLKL9defTowmTvAWVYAsvpfhaGxovKHobRiStr3MA@mail.gmail.com>

Hi Jakob,

Can you please give me some reference/example of bignum optimization which
I can check on powerpc architectures.
Is this any specific instruction set addition? or something more generic?

Thanks & Regards
Mithun

On Tue, Jan 17, 2017 at 9:38 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 17/01/2017 07:44, Mithun P wrote:
>
>> Hi
>>
>> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
>> I am generating RSA 2048 and 3072 bit key pairs.
>> I am providing entropy to openssl by using RAND_seed from a HW RNG.
>>
>> My average generation time for RSA 2048 key pair is 2 Minutes and  3072
>> is 8 minutes.
>> Is there a way to reduce the generation time?
>>
>> I believe this is a CPU intensive operation (if VxWorks can do
> this, try observing the CPU load during).
>
> Potential improvements:
>
> 1. Check if the CPU specific bignum optimizations for your CPU
>   variant have been enabled via the libcrypto CPU detection code
>   (for example, there are optimizations for different ARM cortex
>   variants).
> 2. Faster CPU (expensive obviously).
> 3. Do the generation in the background before the keypair is
>   needed, at a time when the extra CPU load is less of a problem.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170123/466e3d59/attachment.html>

From jb-openssl at wisemo.com  Tue Jan 24 16:10:42 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 24 Jan 2017 17:10:42 +0100
Subject: [openssl-users] RSA Key generation time
In-Reply-To: <CAMzucFSQZuLKL9defTowmTvAWVYAsvpfhaGxovKHobRiStr3MA@mail.gmail.com>
References: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
 <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>
 <CAMzucFSQZuLKL9defTowmTvAWVYAsvpfhaGxovKHobRiStr3MA@mail.gmail.com>
Message-ID: <4df9c064-f9f4-b868-9918-191eeffd9562@wisemo.com>

I'm afraid you will have to look at the OpenSSL source code, I haven't
paid much attention to that CPU recently.

On 23/01/2017 08:09, Mithun P wrote:
> Hi Jakob,
>
> Can you please give me some reference/example of bignum optimization 
> which I can check on powerpc architectures.
> Is this any specific instruction set addition? or something more generic?
>
> Thanks & Regards
> Mithun
>
> On Tue, Jan 17, 2017 at 9:38 PM, Jakob Bohm <jb-openssl at wisemo.com 
> <mailto:jb-openssl at wisemo.com>> wrote:
>
>     On 17/01/2017 07:44, Mithun P wrote:
>
>         Hi
>
>         I have a embedded board P1010 RDB  running openssl on VXWORKS
>         5.4 .
>         I am generating RSA 2048 and 3072 bit key pairs.
>         I am providing entropy to openssl by using RAND_seed from a HW
>         RNG.
>
>         My average generation time for RSA 2048 key pair is 2 Minutes
>         and  3072 is 8 minutes.
>         Is there a way to reduce the generation time?
>
>     I believe this is a CPU intensive operation (if VxWorks can do
>     this, try observing the CPU load during).
>
>     Potential improvements:
>
>     1. Check if the CPU specific bignum optimizations for your CPU
>       variant have been enabled via the libcrypto CPU detection code
>       (for example, there are optimizations for different ARM cortex
>       variants).
>     2. Faster CPU (expensive obviously).
>     3. Do the generation in the background before the keypair is
>       needed, at a time when the extra CPU load is less of a problem.
>
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From matt at openssl.org  Wed Jan 25 08:59:22 2017
From: matt at openssl.org (Matt Caswell)
Date: Wed, 25 Jan 2017 08:59:22 +0000
Subject: [openssl-users] Fwd: [openssl-announce] Forthcoming OpenSSL releases
In-Reply-To: <alpine.LFD.2.20.1701232107570.22765@hatman>
References: <alpine.LFD.2.20.1701232107570.22765@hatman>
Message-ID: <ca714d8f-bb1c-850b-2846-e81b7acb96d8@openssl.org>

In case anyone on these lists missed this on the openssl-announce list:


-------- Forwarded Message --------
Subject: [openssl-announce] Forthcoming OpenSSL releases
Date: Mon, 23 Jan 2017 21:08:50 +0000 (GMT)
From: OpenSSL <openssl at openssl.org>
Reply-To: openssl-users at openssl.org
To: openssl-announce at openssl.org

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2k, 1.1.0d.

These releases will be made available on 26th January 2017 between
approximately
1300-1700 UTC.  They will fix several security defects with maximum severity
"moderate".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.1
ended on 31st December 2016.

Yours

The OpenSSL Project Team
-- 
openssl-announce mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 480 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170125/8b5cc94e/attachment.sig>

From asish_sam at hotmail.com  Wed Jan 25 11:00:34 2017
From: asish_sam at hotmail.com (Asis Kumar Samanta)
Date: Wed, 25 Jan 2017 11:00:34 +0000
Subject: [openssl-users] Need openssl.spec for OpenSSL-1.1.0c for redHat
	Linux 6.5
Message-ID: <HK2PR06MB1555049B6EB91F5F405FAC9A8F740@HK2PR06MB1555.apcprd06.prod.outlook.com>



Could you please provide the openssl.spec for OpenSSL-1.1.0c for redHat Linux 6.5 to build the binary rpm??


Thank you advance.


Regards,


Asish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170125/d046d1a9/attachment.html>

From eero.volotinen at iki.fi  Wed Jan 25 11:58:11 2017
From: eero.volotinen at iki.fi (Eero Volotinen)
Date: Wed, 25 Jan 2017 13:58:11 +0200
Subject: [openssl-users] Need openssl.spec for OpenSSL-1.1.0c for redHat
 Linux 6.5
In-Reply-To: <HK2PR06MB1555049B6EB91F5F405FAC9A8F740@HK2PR06MB1555.apcprd06.prod.outlook.com>
References: <HK2PR06MB1555049B6EB91F5F405FAC9A8F740@HK2PR06MB1555.apcprd06.prod.outlook.com>
Message-ID: <CABzZrXet6Mak8ZPhaAfZcqBD3EHik-_OebbuzQctHi6Y1qSY5Q@mail.gmail.com>

RHEL version is heavily patched. so there is no such a version.

2017-01-25 13:00 GMT+02:00 Asis Kumar Samanta <asish_sam at hotmail.com>:

>
>
> Could you please provide the openssl.spec for OpenSSL-1.1.0c for redHat
> Linux 6.5 to build the binary rpm??
>
>
> Thank you advance.
>
>
> Regards,
>
>
> Asish
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170125/d5e08321/attachment.html>

From kyle at batemans.org  Wed Jan 25 17:03:36 2017
From: kyle at batemans.org (Kyle Bateman)
Date: Wed, 25 Jan 2017 10:03:36 -0700
Subject: [openssl-users] Open source network money project
In-Reply-To: <bab99a8537e946b89c577ac207c41e37@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <b790460e-7ed0-ff23-b672-0c4a784e9b04@batemans.org>
 <aca4d8f3-6d00-8884-0269-1ae0ec1cb5b6@opensslfoundation.org>
 <bab99a8537e946b89c577ac207c41e37@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <c19f90be-253e-889d-c933-89b57e3731a5@batemans.org>

I have started a project to develop a new kind of open source money (not 
Bitcoin!). It will be heavily dependent on encryption technology. While 
I do have experience in coding, I am more capable as a system 
designer/architect. I am hoping to find a team of great developers who 
would enjoy working on this project with me.

It is outlined here: gotchoices.org/mychips/software.html
And a repository ready to start filling up with new code: 
https://github.com/gotchoices/MyCHIPs

Anyone interested? There is no reward in it, other than unimaginable 
fame and fortune!

You can reply on the contact page of the gotchoices.org site.


From vsraja at gmail.com  Thu Jan 26 04:38:21 2017
From: vsraja at gmail.com (Senthil Raja Velu)
Date: Thu, 26 Jan 2017 10:08:21 +0530
Subject: [openssl-users] OpenSSL handshake failure in
	ssl3_get_client_hello() routine
Message-ID: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>

Hi,
I have a setup where the handshake between openssl server and client fails
at times but not always. And when it does,  the client keeps retrying and
all of trials fail. Only way to recover is to restart the server.

Currently on the server side the openssl version that I have installed is
1.0.1m.

Both server and client are written in C and are in non-blocking mode. I
have added InfoCallBack and printCallBack routines on the server side.

On the server side application, I have set the following options;

    pCtx = SSL_CTX_new(SSLv23_server_method());

    SSL_CTX_set_options(pCtx, SSL_OP_NO_SSLv2);
    SSL_CTX_set_options(pCtx, SSL_OP_NO_SSLv3);
    SSL_CTX_set_options(pCtx, SSL_OP_NO_TLSv1);


Now when the failure occurs, I get the following error message on the
server side:

InfoCB
HANDSHAKE_START(time:5093879)  undefined: before/accept initialization

InfoCB
SSL_accept:before/accept initialization

InfoCB
SSL3 alert write:fatal:internal error

PrintCB
error:1408A044:SSL routines:SSL3_GET_CLIENT_HELLO:internal
error:/server/openssl/ssl/s3_srvr.c:1265:

InfoCB
SSL_accept:error in SSLv3 read client hello C

InfoCB
SSL_accept:error in SSLv3 read client hello C


The SSL code path </server/openssl/ssl/s3_srvr.c:1265> refers to the
following section of code in ssl3_get_client_hello() routine in s3_srvr.c.

--------------------------------------------------------------------------
    /*
     * Check if we want to use external pre-shared secret for this handshake
     * for not reused session only. We need to generate server_random before
     * calling tls_session_secret_cb in order to allow SessionTicket
     * processing to use it in key derivation.
     */
    {
        unsigned char *pos;
        pos = s->s3->server_random;
        if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
#ifdef USER_EXTENSIONS
            SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
#endif // USER_EXTENSIONS
            goto f_err;
        }
    }
--------------------------------------------------------------------------

Note, I have edited the SSL library to include this USER_EXTENSIONS
section, so that I could confirm where exactly this issue is happening in
the library.

Clearly ssl_fill_hello_ramdom() routine is returning -1 or something less
than zero.

I do not hit this issue always.

Any pointers on addressing this issue will be a big help.


Thanks,
Senthil.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/a97b2c9f/attachment.html>

From matt at openssl.org  Thu Jan 26 10:08:00 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Jan 2017 10:08:00 +0000
Subject: [openssl-users] OpenSSL handshake failure in
 ssl3_get_client_hello() routine
In-Reply-To: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
References: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
Message-ID: <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>



On 26/01/17 04:38, Senthil Raja Velu wrote:
> Hi,
> I have a setup where the handshake between openssl server and client
> fails at times but not always. And when it does,  the client keeps
> retrying and all of trials fail. Only way to recover is to restart the
> server.
> 
> Currently on the server side the openssl version that I have installed
> is 1.0.1m.

That's quite an old version and is likely to be vulnerable to various
security issues. You should upgrade. Further the 1.0.1 series is no
longer supported (unless your 1.0.1m is actually supplied by your OS
vendor - in which case they may be backporting security fixes to it). If
you are not using an OS supplied version then I recommend you upgrade to
version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
(which may be more difficult). Those versions will be released later today.

> The SSL code path </server/openssl/ssl/s3_srvr.c:1265> refers to the
> following section of code in ssl3_get_client_hello() routine in s3_srvr.c.
> 
> --------------------------------------------------------------------------
>     /*
>      * Check if we want to use external pre-shared secret for this handshake
>      * for not reused session only. We need to generate server_random before
>      * calling tls_session_secret_cb in order to allow SessionTicket
>      * processing to use it in key derivation.
>      */
>     {
>         unsigned char *pos;
>         pos = s->s3->server_random;
>         if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
> #ifdef USER_EXTENSIONS
>             SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
> #endif // USER_EXTENSIONS
>             goto f_err;
>         }
>     }
> --------------------------------------------------------------------------
> 
> Note, I have edited the SSL library to include this USER_EXTENSIONS
> section, so that I could confirm where exactly this issue is happening
> in the library.
> 
> Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
> less than zero.

Well zero or less to be exact. The code for ssl_fill_hello_random()
looks like this:

int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
len)
{
    int send_time = 0;

    if (len < 4)
        return 0;
    if (server)
        send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
    else
        send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
    if (send_time) {
        unsigned long Time = (unsigned long)time(NULL);
        unsigned char *p = result;
        l2n(Time, p);
        return RAND_pseudo_bytes(p, len - 4);
    } else
        return RAND_pseudo_bytes(result, len);
}


As you can see it can return 0 if len < 4 - but in this case it is clear
that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).

Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
reasons why that function returns <= 0:

1) It can't find the random method to use (either built-in or default).
This is really a "should never happen" type condition.

2) If using the default random method then it has insufficient entropy.

3) If using an engine supplied random method, then it has failed for
some engine specific reason.

Are you using an engine that might supply its own random method? If so
you might want to look at whether that is failing.

If not, then look here:
https://www.openssl.org/docs/faq.html#USER1

Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
would probably get an additional error message confirming that it is a
low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
changed to RAND_bytes(). These two are very similar, but on failure due
to low entropy RAND_bytes() puts an error in the error queue.

Matt

From openssl at openssl.org  Thu Jan 26 14:01:36 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 26 Jan 2017 14:01:36 +0000
Subject: [openssl-users] OpenSSL version 1.0.2k published
Message-ID: <20170126140136.GA22894@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.0.2k released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.2k of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2k is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.0.2k.tar.gz
      Size: 5309236
      SHA1 checksum: 5f26a624479c51847ebd2f22bb9f84b3b44dcb44
      SHA256 checksum: 6b3977c61f2aedf0f96367dcfb5c6e578cf37e7b8d913b4ecb6643c3cb88d8c0

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2k.tar.gz
    openssl sha256 openssl-1.0.2k.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYifggAAoJENnE0m0OYESRHWUIAJXlSdrySe40QGFuOfSUQya0
iWTa0PcIPCPjSaM1Rige1BMSwTVhWwNmdimAyG94I1/y6uAoJzFsfNs4xSPlsGGO
9pdAiqeu9GAnJ3z4H/mkasUAmzXkemeWt5dN9KdANbT7HAg+ROKmthrmWiffftoU
x+sGZ/lThIfKIYf+Ch5EmM4VFuCU9gG6YTwlUSKQAcnmcPt1AVrGlSxyVTx1Ahku
Pl3iYbQors6vfBlh4BZZnxh7NJW4WRpJ77+1OH8xaOobJQMDZ5VQqnPMIIbbMLoM
MAJz7T0nfzTaQ8Yzwv078qNPuwzeumI92NGybETbOI8zThHdEffsOegBaHqV+Jk=
=KDh3
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jan 26 14:02:01 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 26 Jan 2017 14:02:01 +0000
Subject: [openssl-users] OpenSSL version 1.1.0d published
Message-ID: <20170126140201.GA22932@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.0d released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.1.0d of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        https://www.openssl.org/news/openssl-1.1.0-notes.html

   OpenSSL 1.1.0d is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0d.tar.gz
      Size: 5201626
      SHA1 checksum: f423e9253ad8a8617fc9fb3562788a9fa066d46f
      SHA256 checksum: 7d5ebb9e89756545c156ff9c13cf2aa6214193b010a468a3bc789c3c28fe60df

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0d.tar.gz
    openssl sha256 openssl-1.1.0d.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYifVEAAoJENnE0m0OYESRcPYH/AqSYRJDURNli0/PhHa45ynT
eXGk5v44l0q/TBqHOiUjPEAE6ctMe+Dg2Bw+2UI5msGZDyD+alksUrf94OzFMIll
UC3FPAyAAIxu/DNyL/tRyGwBqOyHrzvKzwl+yGnOtzQ/a9/la79KCSTUMheDDBgk
2LiPoGi35wfNpJ+jBr/ucPto15+dWQfTMxX8aeYWkdVjUGGcO4XmAuqpIo5Jl7gw
szSzpgvLB55sRZ8o6edU9knoIGRad+TH9JjfKAIzAIUH5BWaALmswQUMWhKTQkpX
jHosHsLUPBLqqPJtmlLr1T7bHXGqz3fvQF0/lHYKA9eQDm0Owd0izeJlsiqaCac=
=WZYB
-----END PGP SIGNATURE-----

From openssl at openssl.org  Thu Jan 26 14:04:46 2017
From: openssl at openssl.org (OpenSSL)
Date: Thu, 26 Jan 2017 14:04:46 +0000
Subject: [openssl-users] OpenSSL Security Advisory
Message-ID: <20170126140446.GA24451@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


OpenSSL Security Advisory [26 Jan 2017]
========================================

Truncated packet could crash via OOB read (CVE-2017-3731)
=========================================================

Severity: Moderate

If an SSL/TLS server or client is running on a 32-bit host, and a specific
cipher is being used, then a truncated packet can cause that server or client
to perform an out-of-bounds read, usually resulting in a crash.

For OpenSSL 1.1.0, the crash can be triggered when using CHACHA20/POLY1305;
users should upgrade to 1.1.0d

For Openssl 1.0.2, the crash can be triggered when using RC4-MD5; users who have
not disabled that algorithm should update to 1.0.2k

This issue was reported to OpenSSL on 13th November 2016 by Robert ?wi?cki of
Google. The fix was developed by Andy Polyakov of the OpenSSL development team.

Bad (EC)DHE parameters cause a client crash (CVE-2017-3730)
===========================================================

Severity: Moderate

If a malicious server supplies bad parameters for a DHE or ECDHE key exchange
then this can result in the client attempting to dereference a NULL pointer
leading to a client crash. This could be exploited in a Denial of Service
attack.

OpenSSL 1.1.0 users should upgrade to 1.1.0d

This issue does not affect OpenSSL version 1.0.2.

Note that this issue was fixed prior to it being recognised as a security
concern. This means the git commit with the fix does not contain the CVE
identifier. The relevant fix commit can be identified by commit hash efbe126e3.

This issue was reported to OpenSSL on 14th January 2017 by Guido Vranken. The
fix was developed by Matt Caswell of the OpenSSL development team.

BN_mod_exp may produce incorrect results on x86_64 (CVE-2017-3732)
==================================================================

Severity: Moderate

There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No
EC algorithms are affected. Analysis suggests that attacks against RSA and DSA
as a result of this defect would be very difficult to perform and are not
believed likely. Attacks against DH are considered just feasible (although very
difficult) because most of the work necessary to deduce information
about a private key may be performed offline. The amount of resources
required for such an attack would be very significant and likely only
accessible to a limited number of attackers. An attacker would
additionally need online access to an unpatched system using the target
private key in a scenario with persistent DH parameters and a private
key that is shared between multiple clients. For example this can occur by
default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very
similar to CVE-2015-3193 but must be treated as a separate problem.

OpenSSL 1.1.0 users should upgrade to 1.1.0d
OpenSSL 1.0.2 users should upgrade to 1.0.2k

This issue was reported to OpenSSL on 15th January 2017 by the OSS-Fuzz project.
The fix was developed by Andy Polyakov of the OpenSSL development team.

Montgomery multiplication may produce incorrect results (CVE-2016-7055)
=======================================================================

Severity: Low

This issue was previously fixed in 1.1.0c and covered in security advisory
https://www.openssl.org/news/secadv/20161110.txt

OpenSSL 1.0.2k users should upgrade to 1.0.2k


Note
====

Support for version 1.0.1 ended on 31st December 2016. Support for versions
0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer
receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20170126.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJYifonAAoJENnE0m0OYESRnhYH/1ldFYDEZ894DleZfjRrZulX
OQkEH7w6v+D6YFp8i2v6rJaDq8caOPEhzupQCxPcqYitBUnww9UzUvYJ77aBV0CG
DQ3UvE9XeEn5D7MGAGq/ut5Z5WpvlYL7n7PaciX751vpTsWTBKfGecQ8YV0aT6y+
7V7vHz6NVFnuTQDMUYs9C9aTsCDTNy3Bl84d7gYyoDWXUXds5k008g9LFRI4YQ8l
+4z+GXRVcvAFr6fKH94Yq1RMAp6cJi0RDkyuwcGhSOUwVfSLTN8+i2v4xqzKgsx1
q2qPo3+7uederE5ZaNZScl0xAzEilotxLQyy9XSVx/DDXHz0in1500qxgxNFELU=
=12E/
-----END PGP SIGNATURE-----

From vsraja at gmail.com  Thu Jan 26 15:24:09 2017
From: vsraja at gmail.com (Senthil Raja Velu)
Date: Thu, 26 Jan 2017 20:54:09 +0530
Subject: [openssl-users] OpenSSL handshake failure in
 ssl3_get_client_hello() routine
In-Reply-To: <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>
References: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
 <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>
Message-ID: <CAJ-5c6vq1SuzowB=zT=siTd0nvjz0EQp56xHu0W2bFq-Hbug3w@mail.gmail.com>

Hi Matt,
Thanks for such a detailed reply. I will work on the pointers provided. And
will plan to move openssl implementation to 1.0.2 series as suggested. I
will check the random method used if that is the cause of this issue.

Many thanks,
Senthil.


On Thu, Jan 26, 2017 at 3:38 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 26/01/17 04:38, Senthil Raja Velu wrote:
> > Hi,
> > I have a setup where the handshake between openssl server and client
> > fails at times but not always. And when it does,  the client keeps
> > retrying and all of trials fail. Only way to recover is to restart the
> > server.
> >
> > Currently on the server side the openssl version that I have installed
> > is 1.0.1m.
>
> That's quite an old version and is likely to be vulnerable to various
> security issues. You should upgrade. Further the 1.0.1 series is no
> longer supported (unless your 1.0.1m is actually supplied by your OS
> vendor - in which case they may be backporting security fixes to it). If
> you are not using an OS supplied version then I recommend you upgrade to
> version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
> (which may be more difficult). Those versions will be released later today.
>
> > The SSL code path </server/openssl/ssl/s3_srvr.c:1265> refers to the
> > following section of code in ssl3_get_client_hello() routine in
> s3_srvr.c.
> >
> > ------------------------------------------------------------
> --------------
> >     /*
> >      * Check if we want to use external pre-shared secret for this
> handshake
> >      * for not reused session only. We need to generate server_random
> before
> >      * calling tls_session_secret_cb in order to allow SessionTicket
> >      * processing to use it in key derivation.
> >      */
> >     {
> >         unsigned char *pos;
> >         pos = s->s3->server_random;
> >         if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
> > #ifdef USER_EXTENSIONS
> >             SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
> > #endif // USER_EXTENSIONS
> >             goto f_err;
> >         }
> >     }
> > ------------------------------------------------------------
> --------------
> >
> > Note, I have edited the SSL library to include this USER_EXTENSIONS
> > section, so that I could confirm where exactly this issue is happening
> > in the library.
> >
> > Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
> > less than zero.
>
> Well zero or less to be exact. The code for ssl_fill_hello_random()
> looks like this:
>
> int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
> len)
> {
>     int send_time = 0;
>
>     if (len < 4)
>         return 0;
>     if (server)
>         send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
>     else
>         send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
>     if (send_time) {
>         unsigned long Time = (unsigned long)time(NULL);
>         unsigned char *p = result;
>         l2n(Time, p);
>         return RAND_pseudo_bytes(p, len - 4);
>     } else
>         return RAND_pseudo_bytes(result, len);
> }
>
>
> As you can see it can return 0 if len < 4 - but in this case it is clear
> that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).
>
> Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
> reasons why that function returns <= 0:
>
> 1) It can't find the random method to use (either built-in or default).
> This is really a "should never happen" type condition.
>
> 2) If using the default random method then it has insufficient entropy.
>
> 3) If using an engine supplied random method, then it has failed for
> some engine specific reason.
>
> Are you using an engine that might supply its own random method? If so
> you might want to look at whether that is failing.
>
> If not, then look here:
> https://www.openssl.org/docs/faq.html#USER1
>
> Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
> would probably get an additional error message confirming that it is a
> low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
> changed to RAND_bytes(). These two are very similar, but on failure due
> to low entropy RAND_bytes() puts an error in the error queue.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/0ae18170/attachment-0001.html>

From vsraja at gmail.com  Thu Jan 26 15:53:04 2017
From: vsraja at gmail.com (Senthil Raja Velu)
Date: Thu, 26 Jan 2017 21:23:04 +0530
Subject: [openssl-users] OpenSSL handshake failure in
 ssl3_get_client_hello() routine
In-Reply-To: <CAJ-5c6vq1SuzowB=zT=siTd0nvjz0EQp56xHu0W2bFq-Hbug3w@mail.gmail.com>
References: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
 <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>
 <CAJ-5c6vq1SuzowB=zT=siTd0nvjz0EQp56xHu0W2bFq-Hbug3w@mail.gmail.com>
Message-ID: <CAJ-5c6vpJOfFUezintL4uQV8GF-QQE96X1jAeghdzcm_YK3-QA@mail.gmail.com>

Hi Matt,
One other quick question, Is there a openssl utility code to just check
PRNG is initialized or NOT_SEEDED.
That way I could verify the current running state of the application. The
other thing I am after is, it works some times but not other times.

Thanks,
Senthil.


On Thu, Jan 26, 2017 at 8:54 PM, Senthil Raja Velu <vsraja at gmail.com> wrote:

> Hi Matt,
> Thanks for such a detailed reply. I will work on the pointers provided.
> And will plan to move openssl implementation to 1.0.2 series as suggested.
> I will check the random method used if that is the cause of this issue.
>
> Many thanks,
> Senthil.
>
>
> On Thu, Jan 26, 2017 at 3:38 PM, Matt Caswell <matt at openssl.org> wrote:
>
>>
>>
>> On 26/01/17 04:38, Senthil Raja Velu wrote:
>> > Hi,
>> > I have a setup where the handshake between openssl server and client
>> > fails at times but not always. And when it does,  the client keeps
>> > retrying and all of trials fail. Only way to recover is to restart the
>> > server.
>> >
>> > Currently on the server side the openssl version that I have installed
>> > is 1.0.1m.
>>
>> That's quite an old version and is likely to be vulnerable to various
>> security issues. You should upgrade. Further the 1.0.1 series is no
>> longer supported (unless your 1.0.1m is actually supplied by your OS
>> vendor - in which case they may be backporting security fixes to it). If
>> you are not using an OS supplied version then I recommend you upgrade to
>> version 1.0.2k (which should be a straight forward upgrade) or 1.1.0d
>> (which may be more difficult). Those versions will be released later
>> today.
>>
>> > The SSL code path </server/openssl/ssl/s3_srvr.c:1265> refers to the
>> > following section of code in ssl3_get_client_hello() routine in
>> s3_srvr.c.
>> >
>> > ------------------------------------------------------------
>> --------------
>> >     /*
>> >      * Check if we want to use external pre-shared secret for this
>> handshake
>> >      * for not reused session only. We need to generate server_random
>> before
>> >      * calling tls_session_secret_cb in order to allow SessionTicket
>> >      * processing to use it in key derivation.
>> >      */
>> >     {
>> >         unsigned char *pos;
>> >         pos = s->s3->server_random;
>> >         if (ssl_fill_hello_random(s, 1, pos, SSL3_RANDOM_SIZE) <= 0) {
>> > #ifdef USER_EXTENSIONS
>> >             SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, ERR_R_INTERNAL_ERROR);
>> > #endif // USER_EXTENSIONS
>> >             goto f_err;
>> >         }
>> >     }
>> > ------------------------------------------------------------
>> --------------
>> >
>> > Note, I have edited the SSL library to include this USER_EXTENSIONS
>> > section, so that I could confirm where exactly this issue is happening
>> > in the library.
>> >
>> > Clearly ssl_fill_hello_ramdom() routine is returning -1 or something
>> > less than zero.
>>
>> Well zero or less to be exact. The code for ssl_fill_hello_random()
>> looks like this:
>>
>> int ssl_fill_hello_random(SSL *s, int server, unsigned char *result, int
>> len)
>> {
>>     int send_time = 0;
>>
>>     if (len < 4)
>>         return 0;
>>     if (server)
>>         send_time = (s->mode & SSL_MODE_SEND_SERVERHELLO_TIME) != 0;
>>     else
>>         send_time = (s->mode & SSL_MODE_SEND_CLIENTHELLO_TIME) != 0;
>>     if (send_time) {
>>         unsigned long Time = (unsigned long)time(NULL);
>>         unsigned char *p = result;
>>         l2n(Time, p);
>>         return RAND_pseudo_bytes(p, len - 4);
>>     } else
>>         return RAND_pseudo_bytes(result, len);
>> }
>>
>>
>> As you can see it can return 0 if len < 4 - but in this case it is clear
>> that that isn't happening (because len is set to SSL3_RANDOM_SIZE == 32).
>>
>> Otherwise it returns the result of RAND_pseudo_bytes(). There are a few
>> reasons why that function returns <= 0:
>>
>> 1) It can't find the random method to use (either built-in or default).
>> This is really a "should never happen" type condition.
>>
>> 2) If using the default random method then it has insufficient entropy.
>>
>> 3) If using an engine supplied random method, then it has failed for
>> some engine specific reason.
>>
>> Are you using an engine that might supply its own random method? If so
>> you might want to look at whether that is failing.
>>
>> If not, then look here:
>> https://www.openssl.org/docs/faq.html#USER1
>>
>> Incidentally if you were to do the upgrade to 1.0.2 or 1.1.0 then you
>> would probably get an additional error message confirming that it is a
>> low entropy issue. In 1.0.2 the RAND_pseudo_bytes() call has been
>> changed to RAND_bytes(). These two are very similar, but on failure due
>> to low entropy RAND_bytes() puts an error in the error queue.
>>
>> Matt
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/dbe0594c/attachment.html>

From matt at openssl.org  Thu Jan 26 15:57:03 2017
From: matt at openssl.org (Matt Caswell)
Date: Thu, 26 Jan 2017 15:57:03 +0000
Subject: [openssl-users] OpenSSL handshake failure in
 ssl3_get_client_hello() routine
In-Reply-To: <CAJ-5c6vpJOfFUezintL4uQV8GF-QQE96X1jAeghdzcm_YK3-QA@mail.gmail.com>
References: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
 <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>
 <CAJ-5c6vq1SuzowB=zT=siTd0nvjz0EQp56xHu0W2bFq-Hbug3w@mail.gmail.com>
 <CAJ-5c6vpJOfFUezintL4uQV8GF-QQE96X1jAeghdzcm_YK3-QA@mail.gmail.com>
Message-ID: <2c8c6ebd-3e97-e62c-0385-035f6c5c0531@openssl.org>



On 26/01/17 15:53, Senthil Raja Velu wrote:
> Hi Matt,
> One other quick question, Is there a openssl utility code to just check
> PRNG is initialized or NOT_SEEDED.

See RAND_status().

Matt

From vsraja at gmail.com  Thu Jan 26 16:59:35 2017
From: vsraja at gmail.com (Senthil Raja Velu)
Date: Thu, 26 Jan 2017 22:29:35 +0530
Subject: [openssl-users] OpenSSL handshake failure in
 ssl3_get_client_hello() routine
In-Reply-To: <2c8c6ebd-3e97-e62c-0385-035f6c5c0531@openssl.org>
References: <CAJ-5c6uEP5NyN641Pf6FfR52rWqtonxMyu8WmwmqQNsyyU1uBA@mail.gmail.com>
 <07a82d91-4ba0-896a-f319-96db99509114@openssl.org>
 <CAJ-5c6vq1SuzowB=zT=siTd0nvjz0EQp56xHu0W2bFq-Hbug3w@mail.gmail.com>
 <CAJ-5c6vpJOfFUezintL4uQV8GF-QQE96X1jAeghdzcm_YK3-QA@mail.gmail.com>
 <2c8c6ebd-3e97-e62c-0385-035f6c5c0531@openssl.org>
Message-ID: <CAJ-5c6u3TQ9Fa1gFkw-ytYA_0u7jVHnjV1ovgMQwUkVmW=YMGA@mail.gmail.com>

Thanks again!

-Senthil.


On Thu, Jan 26, 2017 at 9:27 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 26/01/17 15:53, Senthil Raja Velu wrote:
> > Hi Matt,
> > One other quick question, Is there a openssl utility code to just check
> > PRNG is initialized or NOT_SEEDED.
>
> See RAND_status().
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/b16ee0f4/attachment.html>

From ethan.rahn at gmail.com  Thu Jan 26 18:40:15 2017
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Thu, 26 Jan 2017 10:40:15 -0800
Subject: [openssl-users] Should openssl publish the commit #'s that fixed
	each CVE?
Message-ID: <CAEW9rAh2sBKp7mNCajb9USSxHnUhqwY1QT0X=r+yd+d4mJzk3Q@mail.gmail.com>

Hello,

When looking a the latest security announcement, something that I notice is
that it's hard to find the actual commits that fixed an issue. If you
search git.openssl.org you can find some of them if they are mentioned in
the change message, but it still requires some active effort.

Would it be a good idea for openssl to publish the commit(s) that fixed
each CVE? It would make it easier to see what changed, which is great for
a.) backporting.
b.) satisfying curiosity of armchair cryptographers.
c.) better assessing an issue.

Cheers,

Ethan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/44afd3e9/attachment.html>

From scott_n at xypro.com  Thu Jan 26 18:53:17 2017
From: scott_n at xypro.com (Scott Neugroschl)
Date: Thu, 26 Jan 2017 18:53:17 +0000
Subject: [openssl-users] Should openssl publish the commit #'s that
 fixed	each CVE?
In-Reply-To: <CAEW9rAh2sBKp7mNCajb9USSxHnUhqwY1QT0X=r+yd+d4mJzk3Q@mail.gmail.com>
References: <CAEW9rAh2sBKp7mNCajb9USSxHnUhqwY1QT0X=r+yd+d4mJzk3Q@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F37549877902A0E9@XYSVEX02.XYPRO-23.LOCAL>

The CVE itself contains the commit info.  Find it at cve.mitre.org

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Ethan Rahn
Sent: Thursday, January 26, 2017 10:40 AM
To: openssl-users at openssl.org
Subject: [openssl-users] Should openssl publish the commit #'s that fixed each CVE?

Hello,

When looking a the latest security announcement, something that I notice is that it's hard to find the actual commits that fixed an issue. If you search git.openssl.org<http://git.openssl.org> you can find some of them if they are mentioned in the change message, but it still requires some active effort.

Would it be a good idea for openssl to publish the commit(s) that fixed each CVE? It would make it easier to see what changed, which is great for
a.) backporting.
b.) satisfying curiosity of armchair cryptographers.
c.) better assessing an issue.

Cheers,

Ethan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/753af9b7/attachment-0001.html>

From ethan.rahn at gmail.com  Thu Jan 26 19:20:03 2017
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Thu, 26 Jan 2017 11:20:03 -0800
Subject: [openssl-users] Should openssl publish the commit #'s that
 fixed each CVE?
In-Reply-To: <D358E5B1511A314F8160ADC6F37549877902A0E9@XYSVEX02.XYPRO-23.LOCAL>
References: <CAEW9rAh2sBKp7mNCajb9USSxHnUhqwY1QT0X=r+yd+d4mJzk3Q@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F37549877902A0E9@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <CAEW9rAgz9NcPbzK6z5-0tGSxLxn3icSjhH4EzDsgVkGu_1YXWg@mail.gmail.com>

Scott, I just checked the CVE ID's on mitre, and as of now ( 11:18 AM PST
1/26/17 ) they are all listed as 'reserved' and don't have any information
about the issue. NVD shows the same information. In either case, it seems
like an extra hoop to jump through to have to go to a third party site to
find a commit #, when the third party chooses to release the information.

On Thu, Jan 26, 2017 at 10:53 AM, Scott Neugroschl <scott_n at xypro.com>
wrote:

> The CVE itself contains the commit info.  Find it at cve.mitre.org
>
>
>
> *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On
> Behalf Of *Ethan Rahn
> *Sent:* Thursday, January 26, 2017 10:40 AM
> *To:* openssl-users at openssl.org
> *Subject:* [openssl-users] Should openssl publish the commit #'s that
> fixed each CVE?
>
>
>
> Hello,
>
>
>
> When looking a the latest security announcement, something that I notice
> is that it's hard to find the actual commits that fixed an issue. If you
> search git.openssl.org you can find some of them if they are mentioned in
> the change message, but it still requires some active effort.
>
>
>
> Would it be a good idea for openssl to publish the commit(s) that fixed
> each CVE? It would make it easier to see what changed, which is great for
>
> a.) backporting.
>
> b.) satisfying curiosity of armchair cryptographers.
>
> c.) better assessing an issue.
>
>
>
> Cheers,
>
>
>
> Ethan
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170126/1245161b/attachment.html>

From ajaygargnsit at gmail.com  Sat Jan 28 05:20:29 2017
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sat, 28 Jan 2017 10:50:29 +0530
Subject: [openssl-users] Issues while "configuring before compiling"
	OpenSSL on Raspberry-Pi
In-Reply-To: <CAHP4M8W-wv88wUNoh0MB4EHOkxScZAAjFr+11hdEDQrPK0Vuvw@mail.gmail.com>
References: <CAHP4M8W-wv88wUNoh0MB4EHOkxScZAAjFr+11hdEDQrPK0Vuvw@mail.gmail.com>
Message-ID: <CAHP4M8XA8kpF4+d_YSO4i-SYecuDq=sFaq7YMxqfcHvttP5dgA@mail.gmail.com>

Hi Experts !!!

Any help, please ?!!!

On Sun, Jan 15, 2017 at 9:14 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> Hi All.
>
> I am getting stuck on the first step of configuring OpenSSL.
> Following are some of the diagnostics ::
>
>
> OpenSSL-Version : *1.0.2d*
>
>
> #########################################################################
> pi at raspberrypi:~/instamsg-c/third_party/openssl $ *uname -a*
> Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l
> GNU/Linux
> #########################################################################
>
>
> #########################################################################
> pi at raspberrypi:~/instamsg-c/third_party/openssl $ *./Configure
> linux-armv4*
> Configuring for linux-armv4
>     no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128
> (skip dir)
>     no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
>     no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
>     no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
>     no-libunbound   [experimental] OPENSSL_NO_LIBUNBOUND (skip dir)
>     no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
>     no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
>     no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
>     no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
>     no-shared       [default]
>     no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
>     no-store        [experimental] OPENSSL_NO_STORE (skip dir)
>     no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
>     no-zlib         [default]
>     no-zlib-dynamic [default]
> IsMK1MF=0
> CC            =gcc
> CFLAG         =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
> -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
> EX_LIBS       =-ldl
> CPUID_OBJ     =armcap.o armv4cpuid.o
> BN_ASM        =bn_asm.o armv4-mont.o armv4-gf2m.o
> EC_ASM        =
> DES_ENC       =des_enc.o fcrypt_b.o
> AES_ENC       =aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o
> BF_ENC        =bf_enc.o
> CAST_ENC      =c_enc.o
> RC4_ENC       =rc4_enc.o rc4_skey.o
> RC5_ENC       =rc5_enc.o
> MD5_OBJ_ASM   =
> SHA1_OBJ_ASM  =sha1-armv4-large.o sha256-armv4.o sha512-armv4.o
> RMD160_OBJ_ASM=
> CMLL_ENC      =camellia.o cmll_misc.o cmll_cbc.o
> MODES_OBJ     =ghash-armv4.o ghashv8-armx.o
> ENGINES_OBJ   =
> PROCESSOR     =
> RANLIB        =/usr/bin/ranlib
> ARFLAGS       =
> PERL          =/usr/bin/perl
> THIRTY_TWO_BIT mode
> DES_UNROLL used
> DES_INT used
> BN_LLONG mode
> RC4 uses uchar
> RC4_CHUNK is unsigned long
> BF_PTR used
> e_os2.h => include/openssl/e_os2.h
> making links in crypto...
> make[1]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto'
> crypto.h => ../include/openssl/crypto.h
> opensslv.h => ../include/openssl/opensslv.h
> opensslconf.h => ../include/openssl/opensslconf.h
> ebcdic.h => ../include/openssl/ebcdic.h
> symhacks.h => ../include/openssl/symhacks.h
> ossl_typ.h => ../include/openssl/ossl_typ.h
> constant_time_test.c => ../test/constant_time_test.c
> making links in crypto/objects...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/objects'
> objects.h => ../../include/openssl/objects.h
> obj_mac.h => ../../include/openssl/obj_mac.h
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/objects'
> making links in crypto/md4...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md4'
> md4.h => ../../include/openssl/md4.h
> md4test.c => ../../test/md4test.c
> md4.c => ../../apps/md4.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md4'
> making links in crypto/md5...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md5'
> md5.h => ../../include/openssl/md5.h
> md5test.c => ../../test/md5test.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/md5'
> making links in crypto/sha...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/sha'
> sha.h => ../../include/openssl/sha.h
> shatest.c => ../../test/shatest.c
> sha1test.c => ../../test/sha1test.c
> sha256t.c => ../../test/sha256t.c
> sha512t.c => ../../test/sha512t.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/sha'
> making links in crypto/mdc2...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/mdc2'
> mdc2.h => ../../include/openssl/mdc2.h
> mdc2test.c => ../../test/mdc2test.c
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/mdc2'
> making links in crypto/hmac...
> make[2]: Entering directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/hmac'
> make[2]: *** No rule to make target 'links'.  Stop.
> make[2]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto/hmac'
> Makefile:95: recipe for target 'links' failed
> make[1]: *** [links] Error 1
> make[1]: Leaving directory '/home/pi/instamsg-c/third_par
> ty/openssl/crypto'
> Makefile:433: recipe for target 'links' failed
> make: *** [links] Error 1
> #########################################################################
>
>
> What am I missing?
>
> Will be grateful for pointers.
>
>
>
> Thanks and Regards,
> Ajay
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170128/9c0a4d1d/attachment.html>

From Michal.Trojnara at stunnel.org  Sat Jan 28 09:53:00 2017
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Sat, 28 Jan 2017 10:53:00 +0100
Subject: [openssl-users] stunnel 5.40 released
Message-ID: <2c8dde28-9f88-6b16-f0c1-5f9481d002b2@stunnel.org>

Dear Users,

I have released version 5.40 of stunnel.

Version 5.40, 2017.01.28, urgency: HIGH
* Security bugfixes
  - OpenSSL DLLs updated to version 1.0.2k.
    https://www.openssl.org/news/secadv/20170126.txt
* New features
  - DH ciphersuites are now disabled by default.
  - The daily server DH parameter regeneration is only performed if
    DH ciphersuites are enabled in the configuration file.
  - "checkHost" and "checkEmail" were modified to require either
    "verifyChain" or "verifyPeer" (thx to Ma?orzata Olsz?wka).
* Bugfixes
  - Fixed setting default ciphers.

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
23acdb390326ffd507d90f8984ecc90e0d9993f6bd6eac1d0a642456565c45ff
stunnel-5.40.tar.gz
c55548ffe073ddcea61ff938dbbbc66a7dce3be6f70c10ba578b33d18aa1f234
stunnel-5.40-win32-installer.exe
c7c4bb78689d3111e362e3b1e859aa9293809b4720b814810b8cdd6963fc17b1
stunnel-5.40-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170128/a5c4d433/attachment-0001.sig>

From fm at frank4dd.com  Sat Jan 28 11:28:27 2017
From: fm at frank4dd.com (Frank Migge)
Date: Sat, 28 Jan 2017 20:28:27 +0900
Subject: [openssl-users] RSA Key generation time
In-Reply-To: <4df9c064-f9f4-b868-9918-191eeffd9562@wisemo.com>
References: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
 <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>
 <CAMzucFSQZuLKL9defTowmTvAWVYAsvpfhaGxovKHobRiStr3MA@mail.gmail.com>
 <4df9c064-f9f4-b868-9918-191eeffd9562@wisemo.com>
Message-ID: <588C805B.9060902@frank4dd.com>

Hi Mithun,

 >> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
 >> I am generating RSA 2048 and 3072 bit key pairs.
 >> I am providing entropy to openssl by using RAND_seed from a HW RNG.

 >> My average generation time for RSA 2048 key pair is 2 Minutes and 
  3072 is 8 minutes.

I noticed embedded board key generation times vary by OS and OpenSSL 
version after converting a Altera Atlas FPGA SoC HPS from original 2013 
Yocto Linux to latest Ubuntu. Under the old Yocto, key generation 
occasionally took up to 2 minutes. Same board under Ubuntu 16.04, 2048 
RSA keys take consistently 2-5 seconds, while 3072 keys need around 8-16 
seconds. Even running the system single core, the numbers don't change 
(on a low utilized system, using OS built-in /dev/urandom).

While I am on a different CPU and OS (32bit ARM v7  900Mhz dual core, 
1GB 400Mhz RAM), your e500 PowerPC can't be to far behind. Your numbers 
seem to be off by a magnitude. You mentioned using a external HW RNG, 
could that be it?

Cheers,
Frank
> Jakob Bohm <mailto:jb-openssl at wisemo.com>
> Wednesday, January 25, 2017 1:10 AM
> I'm afraid you will have to look at the OpenSSL source code, I haven't
> paid much attention to that CPU recently.
>
>
>
>
> Enjoy
>
> Jakob
> Mithun P <mailto:getmithunp at gmail.com>
> Monday, January 23, 2017 4:09 PM
> Hi Jakob,
>
> Can you please give me some reference/example of bignum optimization 
> which I can check on powerpc architectures.
> Is this any specific instruction set addition? or something more generic?
>
> Thanks & Regards
> Mithun
>
>
> Jakob Bohm <mailto:jb-openssl at wisemo.com>
> Wednesday, January 18, 2017 1:08 AM
>
> I believe this is a CPU intensive operation (if VxWorks can do
> this, try observing the CPU load during).
>
> Potential improvements:
>
> 1. Check if the CPU specific bignum optimizations for your CPU
>   variant have been enabled via the libcrypto CPU detection code
>   (for example, there are optimizations for different ARM cortex
>   variants).
> 2. Faster CPU (expensive obviously).
> 3. Do the generation in the background before the keypair is
>   needed, at a time when the extra CPU load is less of a problem.
>
>
> Enjoy
>
> Jakob
> Mithun P <mailto:getmithunp at gmail.com>
> Tuesday, January 17, 2017 3:44 PM
> Hi
>
> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
> I am generating RSA 2048 and 3072 bit key pairs.
> I am providing entropy to openssl by using RAND_seed from a HW RNG.
>
> My average generation time for RSA 2048 key pair is 2 Minutes and 
>  3072 is 8 minutes.
> Is there a way to reduce the generation time?
>
> Regards
> Mithun
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170128/3ad85d95/attachment.html>

From matthias.ballreich at outlook.de  Sat Jan 28 15:01:24 2017
From: matthias.ballreich at outlook.de (Matthias Ballreich)
Date: Sat, 28 Jan 2017 15:01:24 +0000
Subject: [openssl-users] Leading Zeros in ASN1_INTEGER?
Message-ID: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>

Hi there,

is it normal that OpenSSL removes the leading Zeros in an ASN1_INTEGER?
I tried to read the Certificate Serial and the Certificate Serial in the AuthorityKeyID-Extension with C++, which works very well, but i noticed that OpenSSL removes the leading Zeros on it.
The real ASN1-Value is: 00BEED73EE for example, but i got only BEED73EE.
If i view the Certificate inside Microsoft Cert Tool (Certmgr.exe) the leading Zeros are listed there. Same on Firefox, if i Import and view the Certificate there.
So is this the correct way of handling inside OpenSSL or is it a bug or?

Is there a way to prevent that?

I?m using  OpenSSL 1.0.2j.

Hope someone could explain it a little bit.
Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170128/855c12dd/attachment.html>

From openssl-users at dukhovni.org  Sat Jan 28 16:00:53 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 28 Jan 2017 11:00:53 -0500
Subject: [openssl-users] Leading Zeros in ASN1_INTEGER?
In-Reply-To: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
Message-ID: <A9C36C02-E28D-43E5-A958-1AF4445EAD91@dukhovni.org>


> On Jan 28, 2017, at 10:01 AM, Matthias Ballreich <matthias.ballreich at outlook.de> wrote:
> 
> is it normal that OpenSSL removes the leading Zeros in an ASN1_INTEGER?
> I tried to read the Certificate Serial and the Certificate Serial in the
> AuthorityKeyID-Extension with C++, which works very well, but i noticed
> that OpenSSL removes the leading Zeros on it.
> 
> The real ASN1-Value is: 00BEED73EE for example, but i got only BEED73EE.
> If i view the Certificate inside Microsoft Cert Tool (Certmgr.exe) the
> leading Zeros are listed there. Same on Firefox, if i Import and view
> the Certificate there. So is this the correct way of handling inside
> OpenSSL or is it a bug or?

Integers don't have leading zeros.  Octet strings representing integers
(in non-DER form) might have leading zeros, but you should not confuse
the data type with its representation.  OpenSSL outputs the correct DER
form of the serial *number* in certificates.

Leading zeros are needed in the DER representation of positive integers
whose most significant nibble is in the range from 8 to F.  Otherwise
the leading bit would cause the integer to be interpreted as negative.

-- 
	Viktor.


From getmithunp at gmail.com  Sat Jan 28 16:38:19 2017
From: getmithunp at gmail.com (Mithun P)
Date: Sat, 28 Jan 2017 22:08:19 +0530
Subject: [openssl-users] RSA Key generation time
In-Reply-To: <588C805B.9060902@frank4dd.com>
References: <CAMzucFQdk3rGWqupz5xGNEjpF_k2iz9Sej64=jH1_9_EEAKMmw@mail.gmail.com>
 <b5b77df5-a610-1bb0-7322-ad7a6b1926c7@wisemo.com>
 <CAMzucFSQZuLKL9defTowmTvAWVYAsvpfhaGxovKHobRiStr3MA@mail.gmail.com>
 <4df9c064-f9f4-b868-9918-191eeffd9562@wisemo.com>
 <588C805B.9060902@frank4dd.com>
Message-ID: <CAMzucFRG3Ux2NjbBZgatyyRaZChQ0C0-jFVyP5NcC5yo+ev9fA@mail.gmail.com>

Hi,

I tried the same key generation on the default linux port from freescale on
the same board and i am getting an average of 20 seconds with the same
board.

Do you think that there is such a huge performance margin with OS.

The only other difference that i can see is that on the VX works port of
openssl, i am using a compiler with is old and optimized for e-500 core
while P1010 uses a e-500V2 core.

Also on the VXworks port of OpenSSL, i have enabled FIPS whereas in the
linux port of openssl FIPS is disabled.

Regards
Mithun

On Sat, Jan 28, 2017 at 4:58 PM, Frank Migge <fm at frank4dd.com> wrote:

> Hi Mithun,
>
> >> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
> >> I am generating RSA 2048 and 3072 bit key pairs.
> >> I am providing entropy to openssl by using RAND_seed from a HW RNG.
>
> >> My average generation time for RSA 2048 key pair is 2 Minutes and  3072
> is 8 minutes.
>
> I noticed embedded board key generation times vary by OS and OpenSSL
> version after converting a Altera Atlas FPGA SoC HPS from original 2013
> Yocto Linux to latest Ubuntu. Under the old Yocto, key generation
> occasionally took up to 2 minutes. Same board under Ubuntu 16.04, 2048 RSA
> keys take consistently 2-5 seconds, while 3072 keys need around 8-16
> seconds. Even running the system single core, the numbers don't change (on
> a low utilized system, using OS built-in /dev/urandom).
>
> While I am on a different CPU and OS (32bit ARM v7  900Mhz dual core, 1GB
> 400Mhz RAM), your e500 PowerPC can't be to far behind. Your numbers seem to
> be off by a magnitude. You mentioned using a external HW RNG, could that be
> it?
>
> Cheers,
> Frank
>
> Jakob Bohm <jb-openssl at wisemo.com>
> Wednesday, January 25, 2017 1:10 AM
> I'm afraid you will have to look at the OpenSSL source code, I haven't
> paid much attention to that CPU recently.
>
>
>
>
> Enjoy
>
> Jakob
> Mithun P <getmithunp at gmail.com>
> Monday, January 23, 2017 4:09 PM
> Hi Jakob,
>
> Can you please give me some reference/example of bignum optimization which
> I can check on powerpc architectures.
> Is this any specific instruction set addition? or something more generic?
>
> Thanks & Regards
> Mithun
>
>
> Jakob Bohm <jb-openssl at wisemo.com>
> Wednesday, January 18, 2017 1:08 AM
>
> I believe this is a CPU intensive operation (if VxWorks can do
> this, try observing the CPU load during).
>
> Potential improvements:
>
> 1. Check if the CPU specific bignum optimizations for your CPU
>   variant have been enabled via the libcrypto CPU detection code
>   (for example, there are optimizations for different ARM cortex
>   variants).
> 2. Faster CPU (expensive obviously).
> 3. Do the generation in the background before the keypair is
>   needed, at a time when the extra CPU load is less of a problem.
>
>
> Enjoy
>
> Jakob
> Mithun P <getmithunp at gmail.com>
> Tuesday, January 17, 2017 3:44 PM
> Hi
>
> I have a embedded board P1010 RDB  running openssl on VXWORKS 5.4 .
> I am generating RSA 2048 and 3072 bit key pairs.
> I am providing entropy to openssl by using RAND_seed from a HW RNG.
>
> My average generation time for RSA 2048 key pair is 2 Minutes and  3072 is
> 8 minutes.
> Is there a way to reduce the generation time?
>
> Regards
> Mithun
>
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170128/7c604ab0/attachment-0001.html>

From norm.green at gemtalksystems.com  Sat Jan 28 18:50:41 2017
From: norm.green at gemtalksystems.com (Norm Green)
Date: Sat, 28 Jan 2017 10:50:41 -0800
Subject: [openssl-users] OCB ciphers
Message-ID: <0d9c65f0-13d2-3ac1-2859-88bc646d3cbe@gemtalksystems.com>

This is with openssl 1.10d.  When I run:

./openssl ciphers -v

The OCB ciphers are not in the list.  Is this an omission or 
intentional?  Other AEAD ciphers are there (GCM).

Thanks,

Norm Green


normg at bunk>./openssl ciphers -v |grep AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA 
Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA Enc=AESGCM(256) 
Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA Enc=AESGCM(256) 
Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=ECDSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH     Au=RSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH       Au=RSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA 
Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA Enc=AESGCM(128) 
Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA Enc=AESGCM(128) 
Mac=AEAD
RSA-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=RSAPSK   Au=RSA Enc=AESGCM(256) 
Mac=AEAD
DHE-PSK-AES256-GCM-SHA384 TLSv1.2 Kx=DHEPSK   Au=PSK Enc=AESGCM(256) 
Mac=AEAD
RSA-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=RSAPSK   Au=RSA 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
DHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=DHEPSK   Au=PSK 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-PSK-CHACHA20-POLY1305 TLSv1.2 Kx=ECDHEPSK Au=PSK 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA Enc=AESGCM(256) Mac=AEAD
PSK-AES256-GCM-SHA384   TLSv1.2 Kx=PSK      Au=PSK Enc=AESGCM(256) Mac=AEAD
PSK-CHACHA20-POLY1305   TLSv1.2 Kx=PSK      Au=PSK 
Enc=CHACHA20/POLY1305(256) Mac=AEAD
RSA-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=RSAPSK   Au=RSA Enc=AESGCM(128) 
Mac=AEAD
DHE-PSK-AES128-GCM-SHA256 TLSv1.2 Kx=DHEPSK   Au=PSK Enc=AESGCM(128) 
Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA Enc=AESGCM(128) Mac=AEAD
PSK-AES128-GCM-SHA256   TLSv1.2 Kx=PSK      Au=PSK Enc=AESGCM(128) Mac=AEAD


From openssl-users at dukhovni.org  Sat Jan 28 19:21:47 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 28 Jan 2017 19:21:47 +0000
Subject: [openssl-users] OCB ciphers
In-Reply-To: <0d9c65f0-13d2-3ac1-2859-88bc646d3cbe@gemtalksystems.com>
References: <0d9c65f0-13d2-3ac1-2859-88bc646d3cbe@gemtalksystems.com>
Message-ID: <20170128192147.GA28349@mournblade.imrryr.org>

On Sat, Jan 28, 2017 at 10:50:41AM -0800, Norm Green wrote:
> This is with openssl 1.10d.  When I run:
> 
> ./openssl ciphers -v

This command shows TLS ciphersuites.

> The OCB ciphers are not in the list.  Is this an omission or intentional?
> Other AEAD ciphers are there (GCM).

There are no OCB TLS ciphersuites.

    https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

-- 
	Viktor.

From russellbell at gmail.com  Sun Jan 29 16:34:48 2017
From: russellbell at gmail.com (russellbell at gmail.com)
Date: Sun, 29 Jan 2017 09:34:48 -0700
Subject: [openssl-users] 'No client certificate CA names sent'
Message-ID: <201701291634.v0TGYmRG013822@randytool.net>


	I apologize if you've answered this question before.  I've
read some of the answers I've found in the archives but I don't
understand them.
	What does this message mean?  That I failed to send a client
certificate CA name?  That I failed to receive one?

	I run

	openssl s_client -certform gmail.pem -key gmail.key -CAfile cacert.pem   -debug -verify 10 -connect smtp.gmail.com:465

I don't see the an argument to send a client certificate CA name in
s_client's man page.

From openssl-users at dukhovni.org  Sun Jan 29 17:36:27 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 29 Jan 2017 12:36:27 -0500
Subject: [openssl-users] 'No client certificate CA names sent'
In-Reply-To: <201701291634.v0TGYmRG013822@randytool.net>
References: <201701291634.v0TGYmRG013822@randytool.net>
Message-ID: <99B08A4E-3909-4CF2-81CC-496E34EE4380@dukhovni.org>


> On Jan 29, 2017, at 11:34 AM, russellbell at gmail.com wrote:
> 
> What does this message mean?  That I failed to send a client
> certificate CA name?  That I failed to receive one?  I run
> 
>  $ openssl s_client -certform gmail.pem -key gmail.key \
>      -CAfile cacert.pem -debug -verify 10 -connect smtp.gmail.com:465
> 
> I don't see the an argument to send a client certificate CA name in
> s_client's man page.

The list of "client certificate CA names" is optionally sent by servers when
requesting client certificates.   It is normal for no such list to be sent,
and it is often wise to send an empty list when requesting client certificates.
All this is controlled on the server side.

-- 
	Viktor.

From sanumesh at in.ibm.com  Mon Jan 30 07:13:53 2017
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Mon, 30 Jan 2017 12:43:53 +0530
Subject: [openssl-users] Does CVE-2016-7055 only impact x86_64 platform ?
Message-ID: <OF4804315A.B15171B6-ON002580B8.00276DF3-652580B8.0027B92F@notes.na.collabserv.com>


Hi

Can you please clarify if CVE-2016-7055 only impact x86_64 platform ? What
about other platforms listed in crypto/bn/asm/ folder which has Montgomery
multiplication procedure, is it impacted ?
Thanks


Regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/ec3e07a8/attachment.html>

From Matthias.Ballreich at outlook.de  Mon Jan 30 10:03:49 2017
From: Matthias.Ballreich at outlook.de (Matthias Ballreich)
Date: Mon, 30 Jan 2017 10:03:49 +0000
Subject: [openssl-users] Leading Zeros in ASN1_INTEGER?
In-Reply-To: <A9C36C02-E28D-43E5-A958-1AF4445EAD91@dukhovni.org>
References: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>,
 <A9C36C02-E28D-43E5-A958-1AF4445EAD91@dukhovni.org>
Message-ID: <AM5P195MB0099CC95FF49976EB2D2BE5FFB4B0@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>

thanks for explanation.


But why did Windows Cert Manager and Firefox Cert Manager show 00BEED73EE as serial number instead of BEED73EE (which openssl shows)?


________________________________
Von: openssl-users <openssl-users-bounces at openssl.org> im Auftrag von Viktor Dukhovni <openssl-users at dukhovni.org>
Gesendet: Samstag, 28. Januar 2017 17:00:53
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] Leading Zeros in ASN1_INTEGER?


> On Jan 28, 2017, at 10:01 AM, Matthias Ballreich <matthias.ballreich at outlook.de> wrote:
>
> is it normal that OpenSSL removes the leading Zeros in an ASN1_INTEGER?
> I tried to read the Certificate Serial and the Certificate Serial in the
> AuthorityKeyID-Extension with C++, which works very well, but i noticed
> that OpenSSL removes the leading Zeros on it.
>
> The real ASN1-Value is: 00BEED73EE for example, but i got only BEED73EE.
> If i view the Certificate inside Microsoft Cert Tool (Certmgr.exe) the
> leading Zeros are listed there. Same on Firefox, if i Import and view
> the Certificate there. So is this the correct way of handling inside
> OpenSSL or is it a bug or?

Integers don't have leading zeros.  Octet strings representing integers
(in non-DER form) might have leading zeros, but you should not confuse
the data type with its representation.  OpenSSL outputs the correct DER
form of the serial *number* in certificates.

Leading zeros are needed in the DER representation of positive integers
whose most significant nibble is in the range from 8 to F.  Otherwise
the leading bit would cause the integer to be interpreted as negative.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/e998b3f0/attachment-0001.html>

From noloader at gmail.com  Mon Jan 30 10:24:03 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 30 Jan 2017 05:24:03 -0500
Subject: [openssl-users] Leading Zeros in ASN1_INTEGER?
In-Reply-To: <AM5P195MB0099CC95FF49976EB2D2BE5FFB4B0@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
 <A9C36C02-E28D-43E5-A958-1AF4445EAD91@dukhovni.org>
 <AM5P195MB0099CC95FF49976EB2D2BE5FFB4B0@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
Message-ID: <CAH8yC8kNfrN41n3ih1kgEeFO-h+T=-U0QZ2FW6J9HgtaGzJ0gg@mail.gmail.com>

On Mon, Jan 30, 2017 at 5:03 AM, Matthias Ballreich
<Matthias.Ballreich at outlook.de> wrote:
> thanks for explanation.
>
> But why did Windows Cert Manager and Firefox Cert Manager show 00BEED73EE as
> serial number instead of BEED73EE (which openssl shows)?

Its just a presentation detail. It appears Microsoft and Mozilla take
the content octets of the ASN.1 integer and they hex encoded it.
OpenSSL appears to convert the it into a binary number/big endian
array and hex encodes it before presenting it to you.

Another tool could have turned it into a binary number and Base64
encoded it before presenting it to you.

The important detail is the underlying data. You can use tools like
OpenSSL's asn1parse or Gutmann's dumpasn1 to see the raw data, if
needed.

Jeff

From Erwann.Abalea at docusign.com  Mon Jan 30 10:25:49 2017
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Mon, 30 Jan 2017 10:25:49 +0000
Subject: [openssl-users] Leading Zeros in ASN1_INTEGER?
In-Reply-To: <AM5P195MB0099CC95FF49976EB2D2BE5FFB4B0@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
References: <AM5P195MB0099FE79A8876BCCFBED077FFB490@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
 <A9C36C02-E28D-43E5-A958-1AF4445EAD91@dukhovni.org>
 <AM5P195MB0099CC95FF49976EB2D2BE5FFB4B0@AM5P195MB0099.EURP195.PROD.OUTLOOK.COM>
Message-ID: <121D5E5E-1346-4D5C-B30D-7C65F30E20D4@docusign.com>

Why not?

This serial number could also be displayed as 3203232750, or 000BEED73EE, or 03203232750.

Cordialement,
Erwann Abalea

Le 30 janv. 2017 ? 11:03, Matthias Ballreich <matthias.ballreich at outlook.de<mailto:matthias.ballreich at outlook.de>> a ?crit :

thanks for explanation.

But why did Windows Cert Manager and Firefox Cert Manager show 00BEED73EE as serial number instead of BEED73EE (which openssl shows)?

________________________________
Von: openssl-users <openssl-users-bounces at openssl.org<mailto:openssl-users-bounces at openssl.org>> im Auftrag von Viktor Dukhovni <openssl-users at dukhovni.org<mailto:openssl-users at dukhovni.org>>
Gesendet: Samstag, 28. Januar 2017 17:00:53
An: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Betreff: Re: [openssl-users] Leading Zeros in ASN1_INTEGER?


> On Jan 28, 2017, at 10:01 AM, Matthias Ballreich <matthias.ballreich at outlook.de<mailto:matthias.ballreich at outlook.de>> wrote:
>
> is it normal that OpenSSL removes the leading Zeros in an ASN1_INTEGER?
> I tried to read the Certificate Serial and the Certificate Serial in the
> AuthorityKeyID-Extension with C++, which works very well, but i noticed
> that OpenSSL removes the leading Zeros on it.
>
> The real ASN1-Value is: 00BEED73EE for example, but i got only BEED73EE.
> If i view the Certificate inside Microsoft Cert Tool (Certmgr.exe) the
> leading Zeros are listed there. Same on Firefox, if i Import and view
> the Certificate there. So is this the correct way of handling inside
> OpenSSL or is it a bug or?

Integers don't have leading zeros.  Octet strings representing integers
(in non-DER form) might have leading zeros, but you should not confuse
the data type with its representation.  OpenSSL outputs the correct DER
form of the serial *number* in certificates.

Leading zeros are needed in the DER representation of positive integers
whose most significant nibble is in the range from 8 to F.  Otherwise
the leading bit would cause the integer to be interpreted as negative.

--
        Viktor.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/c677b5b9/attachment.html>

From russellbell at gmail.com  Mon Jan 30 16:44:09 2017
From: russellbell at gmail.com (russellbell at gmail.com)
Date: Mon, 30 Jan 2017 09:44:09 -0700
Subject: [openssl-users] 'No client certificate CA names sent'
Message-ID: <201701301644.v0UGi94t003292@randytool.net>

	Quoth Mr Viktor Dukhovni, 'it is often wise to send an empty
list when requesting client certificates.'
	How does one send an empty list?


From bkaduk at akamai.com  Mon Jan 30 17:01:35 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 30 Jan 2017 11:01:35 -0600
Subject: [openssl-users] 'No client certificate CA names sent'
In-Reply-To: <201701301644.v0UGi94t003292@randytool.net>
References: <201701301644.v0UGi94t003292@randytool.net>
Message-ID: <76ac439f-9866-5981-0996-4606ec146ff3@akamai.com>

On 01/30/2017 10:44 AM, russellbell at gmail.com wrote:
> 	Quoth Mr Viktor Dukhovni, 'it is often wise to send an empty
> list when requesting client certificates.'
> 	How does one send an empty list?
>

That's generally the default server behavior when no CAs are configured
for that purpose.  But, (1) I thought you were looking at the client
side, and (2) how to configure the server depends on what software is
used on the server, so there's not much more to say right now.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/b5fff4b9/attachment-0001.html>

From bkaduk at akamai.com  Mon Jan 30 17:01:35 2017
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 30 Jan 2017 11:01:35 -0600
Subject: [openssl-users] 'No client certificate CA names sent'
In-Reply-To: <201701301644.v0UGi94t003292@randytool.net>
References: <201701301644.v0UGi94t003292@randytool.net>
Message-ID: <76ac439f-9866-5981-0996-4606ec146ff3@akamai.com>

On 01/30/2017 10:44 AM, russellbell at gmail.com wrote:
> 	Quoth Mr Viktor Dukhovni, 'it is often wise to send an empty
> list when requesting client certificates.'
> 	How does one send an empty list?
>

That's generally the default server behavior when no CAs are configured
for that purpose.  But, (1) I thought you were looking at the client
side, and (2) how to configure the server depends on what software is
used on the server, so there's not much more to say right now.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/b5fff4b9/attachment-0002.html>

From openssl-users at dukhovni.org  Mon Jan 30 17:18:59 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 30 Jan 2017 12:18:59 -0500
Subject: [openssl-users] 'No client certificate CA names sent'
In-Reply-To: <201701301644.v0UGi94t003292@randytool.net>
References: <201701301644.v0UGi94t003292@randytool.net>
Message-ID: <4DB98284-88AC-4AB3-A479-784656BD909F@dukhovni.org>


> On Jan 30, 2017, at 11:44 AM, russellbell at gmail.com wrote:
> 
>> it is often wise to send an empty list when requesting client certificates.
> 
> How does one send an empty list?

https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_client_CA_list.html

Just pass a NULL stack.

-- 
	Viktor.


From james.m.carter at nasa.gov  Mon Jan 30 20:44:16 2017
From: james.m.carter at nasa.gov (Carter, James M. (MSFC-ES34))
Date: Mon, 30 Jan 2017 20:44:16 +0000
Subject: [openssl-users] FW: problem with missing STDINT.H file
Message-ID: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>



The attached text file is a snippet from attempting to install openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when <stdint.h> could not be found. There is no such file anywhere on this machine. As root, searched from the root directory for the file. Do have <stdio.h> in more than one location, /usr/include   /opt/SUNWSpro/prod/include/CC/std   /opt/SUNWSpro/prod/include/CC/stlport4

I found this file on GITHUB. Can it be downloaded and put in /usr/include or /opt/SUNWspro/prod/CC/std.

Thank you for your assistance

James

James Carter  PhD
ES34 Bldg 4487 Rm B117
Optics & Imaging Branch
Space Systems Department
Marshall Space Flight Center, AL 35812
P: 256-544-3469
C: 256-425-2068
F: 256-544-5629

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/29ef6d21/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: script_tail
Type: application/octet-stream
Size: 2621 bytes
Desc: script_tail
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170130/29ef6d21/attachment.obj>

From jb-openssl at wisemo.com  Mon Jan 30 21:14:17 2017
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 30 Jan 2017 22:14:17 +0100
Subject: [openssl-users] FW: problem with missing STDINT.H file
In-Reply-To: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
Message-ID: <dd908d8b-f04f-b916-56e4-d3a37c1409ba@wisemo.com>

On 30/01/2017 21:44, Carter, James M. (MSFC-ES34) wrote:
>
> The attached text file is a snippet from attempting to install 
> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when 
> <stdint.h> could not be found. There is no such file anywhere on this 
> machine. As root, searched from the root directory for the file. Do 
> have <stdio.h> in more than one location, /usr/include 
>   /opt/SUNWSpro/prod/include/CC/std 
>   /opt/SUNWSpro/prod/include/CC/stlport4
>
> I found this file on GITHUB. Can it be downloaded and put in 
> /usr/include or /opt/SUNWspro/prod/CC/std.
>
>
The correct contents of stdint.h depends on the compiler and
its options.  You can't just use a stdint.h written for a
different compiler/os/etc. combination.

At least with OpenSSL 1.0.2, OpenSSL can be compiled on systems
without stdint.h, maybe some of the logic in the new build
system mistakenly thinks Solaris/SunOS provides stdint.h even
when it doesn't.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From noloader at gmail.com  Tue Jan 31 04:17:08 2017
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 30 Jan 2017 23:17:08 -0500
Subject: [openssl-users] FW: problem with missing STDINT.H file
In-Reply-To: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
Message-ID: <CAH8yC8nAeHisY2HrqM72VkcDKCUg8Z5hrsa+UBtPwvAovyTmjw@mail.gmail.com>

> The attached text file is a snippet from attempting to install
> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when
> <stdint.h> could not be found. There is no such file anywhere on this
> machine. As root, searched from the root directory for the file. Do have
> <stdio.h> in more than one location, /usr/include
> /opt/SUNWSpro/prod/include/CC/std   /opt/SUNWSpro/prod/include/CC/stlport4

CC is the Sun C++ compiler. C99 offered <stdint.h> and its available
for C programs. <stdint.h> provides uint32_t, uintptr_t and friends.
Many C++ compilers offer them, but the <stdint.h> types it was not
required for C++ until recently (C++11?).

Until this email, I thought Microsoft was the only implementation
which did not offer it in most of its compilers. Microsoft users must
include <stddef.h> instead (I think it changed in VS2013 with better
C++11 support).

I know <stdint.h> is available on later Solaris, but I don't know what
you need for early Solaris. Or maybe more correctly, its available in
later versions of Sun Studio/Oracle Studio/Developer Studio (like
versions 12).

The real question is for you, do you have the data types like
uint32_t, uintptr_t, and friends.

Jeff

From matt at openssl.org  Tue Jan 31 09:37:40 2017
From: matt at openssl.org (Matt Caswell)
Date: Tue, 31 Jan 2017 09:37:40 +0000
Subject: [openssl-users] FW: problem with missing STDINT.H file
In-Reply-To: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
References: <5077833AAECE8A45871004A2ABC9F2C2178C5B7A@NDMSMBX301.ndc.nasa.gov>
Message-ID: <a13fe97a-e106-bfc6-7f01-241f65118baf@openssl.org>



On 30/01/17 20:44, Carter, James M. (MSFC-ES34) wrote:
>  
> 
>  
> 
> The attached text file is a snippet from attempting to install
> openssl-1.1.0c on a Solaris 8 machine. As can be seen, failed when
> <stdint.h> could not be found.

Do you have inttypes.h instead?

As Jeff pointed out in another email this is for uint32_t and similar
types. These get included from e_os2.h as follows:

# if defined(OPENSSL_SYS_UEFI)
typedef INT8 int8_t;
typedef UINT8 uint8_t;
typedef INT16 int16_t;
typedef UINT16 uint16_t;
typedef INT32 int32_t;
typedef UINT32 uint32_t;
typedef INT64 int64_t;
typedef UINT64 uint64_t;
#  define PRIu64 "%Lu"
# elif (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) || \
     defined(__osf__) || defined(__sgi) || defined(__hpux) || \
     defined(OPENSSL_SYS_VMS) || defined (__OpenBSD__)
#  include <inttypes.h>
# elif defined(_MSC_VER) && _MSC_VER<=1500
/*
 * minimally required typdefs for systems not supporting inttypes.h or
 * stdint.h: currently just older VC++
 */
typedef signed char int8_t;
typedef unsigned char uint8_t;
typedef short int16_t;
typedef unsigned short uint16_t;
typedef int int32_t;
typedef unsigned int uint32_t;
typedef __int64 int64_t;
typedef unsigned __int64 uint64_t;
# else
#  include <stdint.h>
# endif

As you can see we test for various things and then we either include
inttypes.h or stdint.h (or do some platform specific things for UEFI and
MS). If you have inttypes.h then a tweak to the above tests might be
sufficient to get it going.

Matt

From russellbell at gmail.com  Tue Jan 31 15:07:16 2017
From: russellbell at gmail.com (russellbell at gmail.com)
Date: Tue, 31 Jan 2017 08:07:16 -0700
Subject: [openssl-users] 'No client certificate CA names sent'
Message-ID: <201701311507.v0VF7G5G003776@randytool.net>

	Quoth Mr Benjamin Kaduk:

	'That's generally the default server behavior when no CAs are
configured for that purpose.  But, (1) I thought you were looking at
the client side, and (2) how to configure the server depends on what
software is used on the server, so there's not much more to say right
now.'
	It was on the client side.  I'm running sendmail as a client
to relay mail that originates on my computer through gmail.  When I
request a certificate from gmail I get that message in the return
(along with a certificate).  It may not matter.  It doesn't keep me
from sending mail through gmail.  I just wanted to understand it.
	When I send mail through gmail, sendmail reports
'verify=FAIL'.  I hoped to make that not happen.

	Quoth Mr Viktor Dukhovni:

	'https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_client_CA_list.html

	That's the same as the man page I already have.

	'Just pass a NULL stack.'

	Is there an app with which I can do this or do I have to write
a program?  Not that I can't do that.

russell bell

From openssl-users at dukhovni.org  Tue Jan 31 15:34:01 2017
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 31 Jan 2017 15:34:01 +0000
Subject: [openssl-users] 'No client certificate CA names sent'
In-Reply-To: <201701311507.v0VF7G5G003776@randytool.net>
References: <201701311507.v0VF7G5G003776@randytool.net>
Message-ID: <20170131153401.GD28349@mournblade.imrryr.org>

On Tue, Jan 31, 2017 at 08:07:16AM -0700, russellbell at gmail.com wrote:

> 	It was on the client side.  I'm running sendmail as a client
> to relay mail that originates on my computer through gmail.

Gmail's SMTP server, correctly, does not suggest any preferred
client CAs.

> When I
> request a certificate from gmail I get that message in the return
> (along with a certificate).  It may not matter.

Not only does it not matter, it is expected and best practice.

> 	When I send mail through gmail, sendmail reports
> 'verify=FAIL'.  I hoped to make that not happen.

Completely unrelated to the preferred client CA list.  Sendmail's
TLS support is fairly anaemic, you should probably just ignore
this.  While it is possible to "verify" the certificate, that's
pointless unless you also configure secure matching of the MX
hostname against the certificate.  Absent DNSSEC (which gmail does
not currently support) you'd need to define custom policy for gmail
that insists on their current MX hostnames or some fuzzy match
thereof.  This is much too much work.

    https://tools.ietf.org/html/rfc7672#section-1.3

For now, opportunistic unauthenticated TLS will do and is what
what most SMTP email uses:

    https://tools.ietf.org/html/rfc7435#section-1.3
    https://www.google.com/transparencyreport/saferemail/

> 	Quoth Mr Viktor Dukhovni:
> 
> 	'https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_client_CA_list.html
> 
> 	That's the same as the man page I already have.
> 
> 	'Just pass a NULL stack.'
> 
> 	Is there an app with which I can do this or do I have to write
> a program?  Not that I can't do that.

None of this is applicable on the client side.

-- 
	Viktor.

From chintuhema at gmail.com  Tue Jan 31 18:13:23 2017
From: chintuhema at gmail.com (Hema Murthy)
Date: Tue, 31 Jan 2017 23:43:23 +0530
Subject: [openssl-users] Compilation of openssl 1.0.2k breaks
In-Reply-To: <CACWQscaCjykV3max=4K8eYsnwLuGZOd1Hs-C100D5=rhuQxRrw@mail.gmail.com>
References: <CACWQsca4k0o03EfYC00BR_FJcUbQ9PYYs9hBSuQtUe1ofA7nKw@mail.gmail.com>
 <CACWQscZXbrbzehBeD-22DmVT7dR2OwXyxntxvtVouPo_-TMdZQ@mail.gmail.com>
 <CACWQscZKpt1AtuiFz_XH2QQHsBzNfUXhuHxgQt8tLVV0Hw6TxQ@mail.gmail.com>
 <CACWQscaCjykV3max=4K8eYsnwLuGZOd1Hs-C100D5=rhuQxRrw@mail.gmail.com>
Message-ID: <CACWQscYUX0Fx3pA4crm8s8W-xQHpkSqSKe1srLZXpW8SUJyVEQ@mail.gmail.com>

Hi,

Am trying to upgrade openssl 1.0.1p to 1.0.2k and the compilation breaks
with the below error

and am using Ubuntu 10.04.1



In file included from req.c:84:

comp.h:28: error: redefinition of typedef 'COMP_METHOD'

../../Build/target/usr/include/openssl/ossl_typ.h:181: error: previous
declaration of 'COMP_METHOD' was here



Am very new to this work and will be of great help if you can give me
pointers in resolving the above issue.

Awaiting for reply.



Thanks in advance,

Hema
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170131/06105e54/attachment.html>

From rsalz at akamai.com  Tue Jan 31 19:05:47 2017
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 31 Jan 2017 19:05:47 +0000
Subject: [openssl-users] Does CVE-2016-7055 only impact x86_64 platform ?
In-Reply-To: <OF4804315A.B15171B6-ON002580B8.00276DF3-652580B8.0027B92F@notes.na.collabserv.com>
References: <OF4804315A.B15171B6-ON002580B8.00276DF3-652580B8.0027B92F@notes.na.collabserv.com>
Message-ID: <c77ee41afc904a61be3a31dba7f52ef8@usma1ex-dag1mb1.msg.corp.akamai.com>

The text says Broadwell-specific

So it only affects *some* x86_64 platforms.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz

From: Sandeep Umesh [mailto:sanumesh at in.ibm.com]
Sent: Monday, January 30, 2017 2:14 AM
To: openssl-users at openssl.org
Subject: [openssl-users] Does CVE-2016-7055 only impact x86_64 platform ?


Hi

Can you please clarify if CVE-2016-7055 only impact x86_64 platform ? What about other platforms listed in crypto/bn/asm/ folder which has Montgomery multiplication procedure, is it impacted ?
Thanks


Regards
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20170131/e1e64780/attachment.html>