Andy Polyakov | 24 Oct 18:02 2014
Picon

Inconsistency in ARM support

There is inconsistency in ARM support and I'd like to gather some
opinions on how to resolve it. Circulate this to ARM people near you.

At some point an inconsistency of following nature was introduced and
then just grew. OpenSSL attempts to adapt to processor it's running on
by detecting capabilities and using run-time switch between different
code paths. The code probing capabilities is compiled and executed on
all supported ARM architectures, ARMv4 through ARMv8. Original rationale
was that one should be able to produce "universal" binary that can be
executed on wide range of processors and deliver optimal performance on
all of them. But at the same time assembly modules have #if
__ARM_ARCH__>=X which effectively renders them not as universal as
implied in capability probing code. This is the inconsistency. There are
two ways to resolve it.

1. __ARM_ARCH__ is effectively controlled by compiler -march command
line option, which naturally also controls compiler-generated outcome.
In order to live up to original intention to produce "universal" binary,
it would be appropriate to tell *compiler* to generate code for minimal
architecture one wants to target, but tell *assembler* to accept
instructions for maximum architecture one wants to target, e.g.
-march=armv4 -Wa,-march=armv7-a.

2. Abandon the idea of producing true "universal" binary and limit
capability detection to contemporary processor families, ARMv7/8 for the
moment of this writing. And run pre-ARMv7 without capability detection
(there is nothing to detect really).

I suppose distro vendors would prefer 2nd option, because everything has
to match anyway. ISV on the other hand might prefer 1st one, unless of
(Continue reading)

Matthieu Crapet via RT | 24 Oct 16:31 2014
Picon

[openssl.org #3580] [PATCH] Print correct help message (according to configure)

From: Matthieu Crapet <mcrapet <at> gmail.com>

Applies when using no-ssl2 or no-ssl3 switches to Configure.
'-ssl2' and '-ssl3' switches are correctly handled in s_client, s_server and s_time, but help message is
still mentionning it.

Signed-off-by: Matthieu Crapet <mcrapet <at> gmail.com>
---
 apps/s_client.c | 4 ++++
 apps/s_server.c | 4 ++++
 apps/s_time.c   | 4 ++++
 3 files changed, 12 insertions(+)

diff --git a/apps/s_client.c b/apps/s_client.c
index a6f972a..ffee429 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
 <at>  <at>  -335,8 +335,12  <at>  <at>  static void sc_usage(void)
 	BIO_printf(bio_err," -srp_moregroups   - Tolerate other than the known g N values.\n");
 	BIO_printf(bio_err," -srp_strength int - minimal mength in bits for N (default %d).\n",SRP_MINIMAL_N);
 #endif
+#ifndef OPENSSL_NO_SSL2
 	BIO_printf(bio_err," -ssl2         - just use SSLv2\n");
+#endif
+#ifndef OPENSSL_NO_SSL3
 	BIO_printf(bio_err," -ssl3         - just use SSLv3\n");
+#endif
 	BIO_printf(bio_err," -tls1_2       - just use TLSv1.2\n");
 	BIO_printf(bio_err," -tls1_1       - just use TLSv1.1\n");
 	BIO_printf(bio_err," -tls1         - just use TLSv1\n");
(Continue reading)

JiaYanwei via RT | 24 Oct 16:31 2014
Picon

[openssl.org #3579] [PATCH] support building with MinGW under msys2

The kernel name of msys2(MSYS*, e.g. MSYS_NT-6.1) is different from
msys(MINGW*, e.g. MINGW32_NT-6.1). While both of them can be configured
as "${MACHINE}-whatever-mingw".

The attachment is the patch.

Best Regards.
Yanwei

Attachment (msys2.patch): application/octet-stream, 147 bytes
Kyle Hamilton | 23 Oct 21:12 2014
Picon

Proposal: environment variable to disable SSLv2/v3/TLSv1.0/etc individually

This idea comes via https://bugzilla.mozilla.org/show_bug.cgi?id=1083767
(which I realize isn't on openssl's rt, but given the enormity of the
security problem I hope you'll forgive me).  The proposal at that bug is
to create an environment variable for NSS to enforce disablement of
particular versions of the protocols.

What I'd like to see is a single environment variable that can do the
same across NSS and OpenSSL and any other TLS library that chooses to
look for the same variable.

I realize that on embedded platforms, there is no such thing as a
process environment.  Obviously, this wouldn't have any effect in those
platforms.  But, it would reduce environment wastage across the two
largest open-source TLS libraries and their clients, and would provide a
single checklist item that could control OpenSSL clients (think Chrome)
as well as NSS (think Firefox).

Thoughts?

-Kyle H

Attachment (smime.p7s): application/pkcs7-signature, 5065 bytes
Andy Polyakov via RT | 23 Oct 15:34 2014
Picon

Re: [openssl.org #3556] Problem building openssl 1.0.1i in debug mode

> I used the commands
> 
> ./Configure shared debug
  ^^^^^^^^^^^^^^^^^^^^^^^^ I don't think this would be working build on
a 64-bit platform such as one in question. Or rather even if it does
work (make test passes, etc.) it wouldn't be supported and questions
should be dismissed. "Official" way to make a debugging build is to pass
-d to ./config.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Andy Polyakov via RT | 23 Oct 15:09 2014
Picon

Re: [openssl.org #3564]

> Have attempted another build using Win 32 option
>                 perl  Configure  VC-WIN32  no-asm  no-hw
> 
> ms\do_ms completes without error or warnings.
> 
> Running   nmake -f ms\ntdll.mak  compiles all C code but generates the following error on linking
>         rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc
> Microsoft (R) Windows (R) Resource Compiler Version 6.2.9200.16384
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
>         link /nologo /subsystem:console /opt:ref /debug /dll /out:out32dll\libeay32.dll
/def:ms/LIBEAY32.def  <at> C:\Users\nmangino\AppData\Local\Temp\nm9D07.tmp
>    Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp
> bss_fd.obj : error LNK2001: unresolved external symbol _OPENSSL_UplinkTable
> bss_file.obj : error LNK2019: unresolved external symbol _OPENSSL_UplinkTable referenced in function
>  _BIO_new_file
> b_dump.obj : error LNK2001: unresolved external symbol _OPENSSL_UplinkTable
> out32dll\libeay32.dll : fatal error LNK1120: 1 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\BIN\link.EXE"' :
>  return code '0x460'
> Stop.

I can't reproduce it. You tried to build for another platform earlier.
If it was in same directory you probably have to delete tmp32dll.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

(Continue reading)

Andy Polyakov via RT | 23 Oct 14:43 2014
Picon

Re: [openssl.org #3564] Build error OpenSSL 1.0.1i

> I am attempting to build Open SSL 1.0.1.i on  Intel 64,  Windows 7,  using Visual Studio Professional 2012.
> I configured the build with
>                 perl  Configure  debug-VC-WIN64I  no-asm  no-hw

WIN64I denotes Itanium, while what you need on Windows 7 is WIN64A.

> ms\do_win64i complains about not finding ias but continues.
> 
> Running   nmake -f ms\ntdll.mak  generates the following errors
>         ml  /c ms\uptable.asm
> Microsoft (R) Macro Assembler Version 11.00.50727.1
> Copyright (C) Microsoft Corporation.  All rights reserved.
> 
> Assembling: ms\uptable.asm
> ms\uptable.asm(1) : error A2008:syntax error : .
> ms\uptable.asm(2) : error A2044:invalid character in file
> ms\uptable.asm(3) : error A2044:invalid character in file
> ms\uptable.asm(5) : error A2044:invalid character in file
> ms\uptable.asm(6) : error A2034:must be in segment block
> ms\uptable.asm(7) : error A2008:syntax error : .
> ms\uptable.asm(8) : error A2045:missing angle bracket or brace in literal
> ms\uptable.asm(9) : error A2008:syntax error : loc0
> ms\uptable.asm(10) : error A2008:syntax error : .
> ms\uptable.asm(11) : error A2008:syntax error
> ms\uptable.asm(12) : error A2044:invalid character in file
> ms\uptable.asm(13) : error A2008:syntax error : .
> ms\uptable.asm(14) : error A2045:missing angle bracket or brace in literal
> ms\uptable.asm(15) : error A2045:missing angle bracket or brace in literal
> ms\uptable.asm(16) : error A2045:missing angle bracket or brace in literal
> ms\uptable.asm(17) : error A2044:invalid character in file
(Continue reading)

David Leon Gil via RT | 22 Oct 22:15 2014
Picon

Re: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x

On Wed, Oct 22, 2014 at 1:19 PM, Andy Polyakov via RT <rt <at> openssl.org> wrote:
> I actually have improved implementation (well, it's not actually a *lot*
> better, can't be made a *lot* better because of aesenclast latency, but
> it should get better on processors with lower latency) for all key
> lengths.

Awesome! :)

> Bottom line is that specific submission is dismissed, and as there is
> interest I can proceed committing my code.

Thanks,

David

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Andy Polyakov via RT | 22 Oct 19:19 2014
Picon

Re: [openssl.org #3576] Speed up AES-256 key expansion by 1.9x

> Use aesenclast to do key expansion for AES-256 rather than aeskeygenassist.
> 
> Shay Gueron gives the technique in his AES-NI whitepaper; I
> discovered, after implementing my own version (and looking for places
> to patch), that he and Vlad Krasnov had already implemented this
> technique in NSS.
> 
> Relative speedup (key expansion microbenchmark): 1.9x
> 
> Relative speedup, AES-256-GCM seal of 16B messages (BoringSSL
> tool/bssl speed): 1.17x
> 
> This can obviously be extended to other key-lengths; but since I don't
> think people should be using AES-128, and no one uses AES-192, I see
> little point in doing so.

I actually have improved implementation (well, it's not actually a *lot*
better, can't be made a *lot* better because of aesenclast latency, but
it should get better on processors with lower latency) for all key
lengths. The trouble with this approach is that it's *not* faster on
processors other than contemporary i[57]-*, especially on Silvermont
it's a lot slower. One can still argue that improvement on i[57]-*
outweighs losses on others. Reasonable compromise for today can be to
detect AVX capability so that Westmere and Silvermont are exempted.
Bottom line is that specific submission is dismissed, and as there is
interest I can proceed committing my code.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
(Continue reading)

Hubert Kario via RT | 22 Oct 16:46 2014
Picon

Re: [openssl.org #3578] Bug report, verify using CApath not working any more

On Wednesday 22 October 2014 09:50:02 Magnus Thulstrup via RT wrote:
> Hi.
> I have problem to use the CA path to verify the certificate from the
> server in my SSL client.
> I used the command  "openssl s_client -connect www.server.se:443 -CApath
> /opt/etc/certs/ca_root" to verify my certificates.
> The command works on an old openssl distribution:
> OpenSSL 0.9.8j 07 Jan 2009
> 
> But fails on:
> OpenSSL 1.0.1e 11 Feb 2013
> OpenSSL 1.0.1g 11 Apr 2014
> OpenSSL 1.0.1h 5 Jun 2014
> OpenSSL 1.0.2-beta2 22 Jul 2014
> 
> OS: Linux 3.0.101-0.8-default #1 SMP Fri Nov 1 12:51:09 UTC 2013
> (2417eb9) x86_64 x86_64 x86_64 GNU/Linux
> 
> Error message is: Verify return code: 21 (unable to verify the first
> certificate)

openssl since 1.0.0 uses different hash algorithm for the the CApath folders, 
you need to rehash the directory
--

-- 
Regards,
Hubert Kario

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
(Continue reading)

Magnus Thulstrup via RT | 22 Oct 11:53 2014
Picon

Cancel [openssl.org #3578]

Hi.
The problem was that the old openssl binary was still in the path when
the new c_rehash was done for the new versions.
The fingerprint was different between the different openssl versions.

Please cancel the bug report.

Sorry for any inconvenience.
//Magnus.  

Greetings,

This message has been automatically generated in response to the
creation of a trouble ticket regarding:
"Bug report, verify using CApath not working any more", 
a summary of which appears below.

There is no need to reply to this message right now. Your ticket has
been
assigned an ID of [openssl.org #3578].

Please include the string:

[openssl.org #3578]

in the subject line of all future correspondence about this issue. To do
so, 
you may reply to this message.

Thank you,
(Continue reading)


Gmane