Re: [openssl-dev] [openssl.org #4230] apps/speed.c does not handle ghash in the no-SIGALRM case

> It looks like in the #ifndef SIGALRM case, c[D_GHASH][0] is set, but not > c[D_GHASH][i] for larger i. Fixed in master. > (Where is the no-SIGALRM code used?) Nowhere 99.997% cares about. Originally it was used extensively on Windows (i.e. among those majority cared about), but then even t

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

Hi, > Per Jeremy Farrell's suggestion, specifying the "-no-asm" option worked and I > was able to get through the build. > > Regarding the "stvx" instruction, here is a bit clearer set of info to map to > why that instruction seemed to be the issue: Original report listed even last lines in er

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

> You can also add some more macros to the perlasm which already translates a > LOT of opcodes into something older assemblers won't choke on. If it was a matter of few instructions, then absolutely. But if it's a question about *all* vector instructions, then it becomes counter-productive. As al

Re: [openssl-dev] [openssl.org #4210] Compiler warning for Sparc T4 DES opcodes

> OpenSSL 1.1.0 Pre 1 > Platform: Sparc Solaris 10 > Compiler: GCC 4.9.3 > > Warnings: > > e_des.c: In function 'des_init_key': > e_des.c:239:29: warning: assignment from incompatible pointer type > dat->stream.cbc = enc ? des_t4_cbc_encrypt : > des_t4_cbc_decrypt; >

Re: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

>>> OpenSSL 1.0.2e >>> >>> At line 156 of crypto/modes/ctr128.c >>> >>> const unsigned char *in, >>> unsigned char *out, >>> unsigned char ivec[16], >>> unsigned char ecount_buf[16] >>> >>>*(size_t *)(out + n) = >>>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >>> >>> If the buffe

Re: [openssl-dev] [openssl.org #3759] [PATCH] crypto: use bigint in x86-64 perl

> When building on x32 systems where the default type is 32bit, make sure > we can transparently represent 64bit integers. Otherwise we end up with > build errors like: > /usr/bin/perl asm/ghash-x86_64.pl elf > ghash-x86_64.s > Integer overflow in hexadecimal number at asm/../../perlasm/x86_64-xla

Re: [openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e

Hi, > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 > added a check to see if it should use the ADDX instructions based on the > clang version. Unfortunately, on older versions of clang on OS X this check > incorrectly returns true

Re: [openssl-dev] [openssl.org #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

Hi, >> OpenSSL 1.0.2e >> >> At line 156 of crypto/modes/ctr128.c >> >> const unsigned char *in, >> unsigned char *out, >> unsigned char ivec[16], >> unsigned char ecount_buf[16] >> >>*(size_t *)(out + n) = >>*(size_t *)(in + n) ^ *(size_t *)(ecount_buf + n); >> >> If the buffers are n

Re: [openssl-dev] [openssl.org #4229] Bug - OpenSSL 1.0.2e on AIX has sha256p8-ppc.s assembler build issue...

Hi, > I am attempting to build OpenSSL 1.0.2e on AIX and I'm seeing an issue with > the "stvx" assembler instruction in the sha256p8-ppc.s module. I have built > prior version OpenSSL packages on AIX without issue until now (prior was > 1.0.1c), and I haven't varied the steps I typically use.

Re: [openssl-dev] [openssl.org #4237] Failed self-tests on AARCH64 (ARM64)

Hi, > $ uname -a > Linux hikey 3.18.0-linaro-hikey #1 SMP PREEMPT Mon Nov 30 00:11:03 UTC > 2015 aarch64 GNU/Linux > > $ make test > ... > ../test/recipes/80-test_dane.t ok > ../test/recipes/80-test_ocsp.t ok > ../test/recipes/80-test_ssl.t . 1/43 > # F

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

> I verified the problem on both 1.0.2f and master: > > set LINK=/DEBUG > perl Configure VC-WIN64A > ms\do_win64a.bat > nmake -f ms\nt.make > > link /nologo /subsystem:console /opt:ref /debug > /out:out32\openssl.exe @C:\Users\oscar\AppData\Local\Temp\nm45EB.tmp > LINK : fatal error LNK

[openssl-dev] [openssl.org #4279] Re: [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit

> I have an available fix: > > https://github.com/openssl/openssl/pull/597 As per http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=fd7dc201d3b9d43972de6a0e659f7ef6421c99cc problem is addressed in a little bit alternative way. Closing ticket[s]. -- Ticket here: http://rt.openssl.org

Re: [openssl-dev] [openssl.org #4300] BUG: Solaris FIPS container does not redefine bn_mul_mont_fpu in fipssyms.h

Hi, > When building an OpenSSL shared library on Solaris with FIPS support you get > a multiply defined symbol error: > > ld: fatal: symbol 'bn_mul_mont_fpu' is multiply-defined: > (file /usr/local/ssl/fips-2.0/lib//fipscanister.o type=FUNC; file > libcrypto.a(sparcv9a-mont.o) type=FUNC); > l

Re: [openssl-dev] [openssl.org #4289] OpenSSL 1.0.2f serious bug in Win32 makefiles, easy to fix, solution provided

On 02/03/16 17:15, Joey Yandle via RT wrote: >> In the makefile created by Perl, the linker binary name is assigned to a >> variable named LINK. This variable $(LINK) is called to execute the linker >> call. >> This causes a serious collision with the MS Visual Studio build system which >> also

Re: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

> Use an older version of OpenSSL for your FIPS-enabled OpenSSL? For this specific problem it wouldn't help. I mean even older versions should/would exhibit same problem. And renaming symbols or removing .global directives (in whatever OpenSSL version being linked with FIPS module, not FIPS module

Re: [openssl-dev] [openssl.org #3699] openssl-1.0.2, fips sparc multiply defined _sparcv9_vis1_instrument_bus, _sparcv9_vis1_instrument_bus2

>> Sorry, we can't touch the FIPS code any more without sponsorship. > > Though if this is still a problem a workaround is to rename the symbols on the > OpenSSL side outside the FIPS code. Another possibility is to add .weak directives to sparccpuid.S so that linker can tolerate multiple symbols

Re: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS, HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"

>> The SecurityPolicy.pdf claims that HP-UX 11i IA64 is a Supported >> Configuration; how can this claim be made when the code does nto even >> compile correctly? > > The FIPS module compiles correctly but there is the duplicated symbol issue > when you use the FIPS capable OpenSSL. > > Although

Re: [openssl-dev] [openssl.org #4284] Bug in nistz256 assembly code.

Hi, Thanks! Verify attached diff. diff --git a/crypto/ec/asm/ecp_nistz256-x86_64.pl b/crypto/ec/asm/ecp_nistz256-x86_64.pl index c2621c2..824d7b5 100755 --- a/crypto/ec/asm/ecp_nistz256-x86_64.pl +++ b/crypto/ec/asm/ecp_nistz256-x86_64.pl @@ -2044,6 +2044,7 @@ $code.=<<___; push %r15 sub \$3

Re: [openssl-dev] [openssl.org #3810] [PATCH] Improved P256 ECC performance by means of a dedicated function for modular inversion modulo the P256 group order

Hi, > This patch is a contribution to OpenSSL. > > It concerns the P256 ECC implementation. > > The patch improves upon our previous submission, by providing a dedicated > function to perform modular inversion modulo the P256 group order. > > Results: > The performance improvements, for single

Re: [openssl-dev] [openssl.org #4170] Illegal instruction in sha1-586.asm when building for win32 using Visual Studio 2015

> When building openss-1.0.2e for win32 using Visual Studio 2015 I get error > in the assembler code: > > ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj > tmp32dll\sha1-586.asm > Assembling: tmp32dll\sha1-586.asm > tmp32dll\sha1-586.asm(1432) : error A2070:invalid instruction operand

Re: [openssl-dev] [openssl.org #4166] Bug: OpenSSL 1.0.1l fails to verify SOME root CAs: error:num=20:unable to get local issuer certificate

> [ Redirecting to openssl-users ] Problem is that if reported is not subscribed to either list, then he won't ever get the message. Whatever comes through is better passed though . > On Fri, Dec 04, 2015 at 03:25:35PM +, Oliver Schonrock via RT wrote: > >> To Reproduce: >> $ openssl s_clie

Re: [openssl-dev] [openssl.org #4156] Wrong expectation of value of _IOB_ENTRIES with Visual Studio 2015

Hi, > when using OpenSSL (1.0.1p) in our applications, we get the error 'No > OPENSSL_Applink' when calling PEM_read_X509_CRL. We build both OpenSSL > and the application using the same C runtime configuration (/MDd), using > Visual Studio 2015 on Windows 10. Original intention with OPENSSL_Appli

Re: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store

Hi, >> Question is if the condition for $no_vrsave assignment is proper. Or >> rather if it should be /aix|linux64/. As I couldn't see that big-endian >> Linux I have access to uses ELF ABI V2, I've settled for /aix|linux64le/. > I saw you already applied your patch. I apologize for not waiting f

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> ... Either way, we seem to >> agree that *replacing* sun with __sun is not right thing to do in SunOS >> 4 context. One can argue for sun || __sun, or one can argue in favour of >> reverting. My vote goes for latter, because original conditions [in >> e_os.h] do work adequately. > > After close

Re: [openssl-dev] [openssl.org #4142] Fail to detect Xcode 7 for Intel AVX code

Hi, > I just found the perl script for x86_64 assembly failed to detect Xcode 7 > environment (Apple LLVM 7.x), and skipped generating AVX code for MAC OS > ($avx variable is always false). The reason is Apple since Xcode 7.0 removed > string "based on LLVM x.y.z" from version information. Now

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

>>> I just found out that building with at least with the French >>> locale the AVX code is missing. The problem is this code in >>> crypto/sha/asm/sha1-x86_64.pl: >>> if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` >>> =~ /GNU assembler version ([2-9]\.[0-9]+)/)

Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

> >> I applied the patch you sent and configured/compiled using > >> "solaris-sparcv9-gcc" and the program completes normally. > >> As I am unable to use patched/unofficial code for our operational ... > > > >What is criteria for being "official"? Explicitly released as tar-ball > >or just co

Re: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store

Hi, >> Access to VRSAVE have a high cost in performance. >> Since ABI was update we don't need to save what >> vector register we are using. Removing VRSAVE access >> can improve a bit more our performance. > > ... I'd suggest to implement this in ppc-xlate. I.e. recognize > 'mtspr 256,rA' and co

Re: [openssl-dev] [openssl.org #4162] [PATCH] Removing vrsave load and store

Hi, > Access to VRSAVE have a high cost in performance. > Since ABI was update we don't need to save what > vector register we are using. Removing VRSAVE access > can improve a bit more our performance. Well, OpenSSL doesn't target exclusively post-ABI-update systems and the rationale for uncondi

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

> ... Either way, we seem to > agree that *replacing* sun with __sun is not right thing to do in SunOS > 4 context. One can argue for sun || __sun, or one can argue in favour of > reverting. My vote goes for latter, because original conditions [in > e_os.h] do work adequately. After closer look I

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> If you want distinguish Solaris, yes. But if you want to distinguish >> specifically SunOS 4, 'sun' is guaranteed to do the job. Because >> compiler that targets SunOS 4 *has to* have it. Either way, we seem to >> agree that *replacing* sun with __sun is not right thing to do in SunOS >> 4 conte

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>>> FWIW, the generally accepted and documented platform tests include: #ifdef __sun /* this is SunOS */ #endif >> >> By the way, was it *actually* tested on SunOS 4? And if so, when and >> with which compiler? Is it possible that it simply was harmonized at >> some point with "we

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

> FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif By the way, was it *actually* tested on SunOS 4? And if so, when and with which compiler? Is it possible that it simply was harmonized at some point with "we have double-unders

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> In other words I argue in favour of reverting suggested change in >> 1.0.1/2. Because I can't find evidence that __sun is defined on said >> platform. >> >> >> >> > FWIW, the generally accepted and documented platform tests include: >> #ifdef __sun >> /* this is SunOS */ >> #endif I understa

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>>> I'd like to propose the attached patch to 1.0.2d which avoids problems >>> with strict ISO conforming compiler/options, which do not define 'sun' only >>> '__sun' as usual... such as gcc/clang -std=c99 >>> >>> This affects the build itself, but also any user of openssl/opensslconf.h >> >> I've

Re: [openssl-dev] [openssl.org #4144] patch: Use '__sun' instead of 'sun' for strict ISO conforming, compiler/options

>> I'd like to propose the attached patch to 1.0.2d which avoids problems >> with strict ISO conforming compiler/options, which do not define 'sun' only >> '__sun' as usual... such as gcc/clang -std=c99 >> >> This affects the build itself, but also any user of openssl/opensslconf.h > > I've commit

Re: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse()

> The contract of volatile means that the compiler can't cache it. > But I think that's only when it actually generates code for it, > not when it can optimize it away. Well, if that was the case, then you wouldn't be able to talk to hardware from C. Formally volatile references are not subject to

Re: [openssl-dev] [openssl.org #4138] Detection of assembler version

Hi, > I just found out that building with at least with the French > locale the AVX code is missing. The problem is this code in > crypto/sha/asm/sha1-x86_64.pl: > if (`$ENV{CC} -Wa,-v -c -o /dev/null -x assembler /dev/null 2>&1` > =~ /GNU assembler version ([2-9]\.[0-9]+)/) { >

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

> See http://www.infradead.org/rpr.html Must be poor timing. First DNS took forever, then I get unable to connect, connection time-outs... >> To question about OPENSSL_stderr() that was removed with "not used" >> rationale. When it comes to a *library* you always run risk of finding >> something

Re: [openssl-dev] [openssl.org #3964] Fix OPENSSL_NO_STDIO build

To question about OPENSSL_stderr() that was removed with "not used" rationale. When it comes to a *library* you always run risk of finding something that it not used by the library itself, something that is meant to be used exclusively by somebody else's application. And OPENSSL_stderr() is such th

Re: [openssl-dev] [openssl.org #4056] 1.0.2d and Configure issue under X32 (ARFLAGS is architecture name?)

> It appears ARFLAGS is set to the architecture when using RPATH options > in Configure's $cflags and $ldflags. RPATHS are important (IMHO) > because OpenSSL can get into a situation where /usr/local/bin/openssl > uses /usr/local/lib/libssl.so, but libssl.so uses the system's > /usr/lib/libcrypto.s

Re: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface

>>> More coming in. Attached are ARMv8 modules. It might be worth noting that small-block performance of all presented Poly1305 modules can be improved by postponing pre-computations for vector code. I mean provided that a) non-vector initialization procedure is totally inexpensive, while b) vecto

Re: [openssl-dev] EXT :Re: [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

> I ran the truss command line you specified on the Sun T-3 and had to kill -9 > the process as Ctrl-C and Ctrl-Z did not work. Attached is the truss.log > output and below are the last few lines of that file where the process was > hung up. truss.log also effectively confirms the hypotheses.

Re: [openssl-dev] [openssl.org #3931] OpenSSL 1.0.2(c, d) hangs on Sun T3 in OPENSSL_cpuid_setup()

Hi, Misaki.Miyashita wrote: > Hi Rick, > > Can you run the truss(1) command when you run "openssl version" as follows? > > i.e. > % truss -lf -u libcrypto:: -u libpkcs11:: -o /tmp/truss.out openssl version > > The output will tell you more information about the function calls made > by the open

Re: [openssl-dev] [openssl.org #3932] Compilation Bug Report

jean-christophe manciot via RT wrote: > *Ubuntu Server 15.04* > *OpenSSL 1.0.2d sources from https://github.com/openssl/openssl > * > > root@msi-ge60 > :/home/actionmystique/Program-Files/Ubuntu/OpenSSL/git-open-ssl#* ./config* > Operating system: x86_64-whateve

Re: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface

>> More coming in. > > Consider 32-bit results. First column is assembly results for base 2^32 > integer-only code in comparison to compiler-generate code. Second column > is my result for NEON, and last column are results for Andrew Moon's > NEON implementation, both are base 2^26. > > #

Re: [openssl-dev] [openssl.org #3860] Some Sparc build configurations for gcc use deprecated -mv8

Hi, > Some build configurations for gcc on Sparc use the outdated gcc switch -mv8. > > The switch was deprecated at least back for gcc 2.95.2 in October 1999 > ([1][2]). GCC 4 does no longer support the -mv8 switch but instead now > you have to use the switch that was already preferred for vers

Re: [openssl-dev] [openssl.org #3859] [PATCH] Define GCC_VERSION macro to cover upto gcc-5

Hi, > Current check is limited to gcc 4 with minor versions > but when we use gcc 5.1, then minor version check fails > with current setup and we end up with build errors like > > | In file included from bn_div.c:62:0: > | bn_div.c: In function 'BN_div': > | bn_lcl.h:311:9: error: impossible cons

Re: [openssl-dev] [openssl.org #3858] [PATCH] fix copy paste error in ec_GF2m function prototypes

Hi, > Just removes some duplication in the header file. Patch attached. Applied, thanks for report. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()

>>> Yes, I added a new target "linux-mic" into Configure, which is slightly >>> modified from "linux-generic64". >>> >>> From the original patch: >>> >>> (...) >>> "linux-generic64","gcc:-DTERMIO -O3 >>> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT >>> DES_UNROLL >>>

Re: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards

Hi, > This patch adds Cavium Networks' OCTEON target to Configure file. The diff > is taken against OpenSSL-1.0.2a release. Well, objective is not to collect as many exotic config lines as possible, but rather more generic ones that we are ready to support and make them flexible enough to be re

Re: [openssl-dev] [openssl.org #3791] Problems configuring for OSX 10.8.5 (x86_64)

> This issue has kind of been with the project for so long its just kind > of accepted > > But its 2015 and all Apple hardware is x86_64. Its been that way for > quite a few years. Also, there's really no reason to (1) default to > darwin-i386 and (2) not recognize darwin-x86_64. > > I sugges

Re: [openssl-dev] [openssl.org #3792] OpenSSL debug build lacks -Og

> This is for OpenSSL 1.0.2. > > -Og was added to GCC to allow one to use optimizations that don't > disturb a debug session. As I understand it, it acts like like -O1 (to > perform some basic analysis) without losing symbol information (i.e., > "optimized out" under the debugger). See > https://g

Re: [openssl-dev] [openssl.org #3794] Missing symbols for padlock_aes_block during link in Master

> I'm trying to run OpenSSL Master through Clang's sanitizers. Below is > from 99-clang-sanitizer.conf (this is my fumbling). > > $ make > making all in crypto... > Undefined symbols for architecture x86_64: > "_padlock_aes_block", referenced from: > _padlock_ofb_cipher in libcrypto.a(e_pa

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

>>> ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq >>> $0,%xmm6,%xmm14,%xmm0' >> >> What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on >> your system? >> >> >> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null > GNU assembler version 2.17.50.0.6-14.el5 (x86_64-re

Re: [openssl-dev] [openssl.org #3795] OS X is using LD_LIBRARY_PATH, and not DYLD_LIBRARY_PATH in Master

Hi, > I'm working with Master on OS X. I tried to add a build configuration > of Clang and its sanitizers. I think I got the Darwin and OS X > specific stuff included in the CONF file (see below). > > During link, it appears LD_LIBRARY_PATH is used rather than > DYLD_LIBRARY_PATH. On OS X, DYLD_L

Re: [openssl-dev] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken

Hi, > I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris > 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work. > > Solaris 10 > Solaris Studio 12.4 > > Make test log attached. > > 1 When building 1.0.2 using > > ./Configure solaris-sparcv9-cc no-shared -m32

Re: [openssl-dev] [openssl.org #3811] [BUG REPORT] - Missing register name in aes-x86_64.s

Hi, > The suggested fix for #3759: [PATCH] crypto: use bigint in x86-64 perl > addresses some issues but not all issues with the generation of the asm from > the perl scripts. Using the provided patch, one still fails with: > > /usr/bin/perl asm/aes-x86_64.pl macosx > aes-x86_64.s > /opt/local

Re: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE

Hi, > I got a problem building openssl 1.0.2a on SUSE. > > Platform: >> uname -a > > Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 > x86_64 x86_64 x86_64 GNU/Linux > > > Compiler: > >> gcc -v > Using built-in specs. > Target: x86_64-suse-linux > Configured with: ../co

Re: [openssl-dev] [openssl.org #3819] make openssl-1.0.2a failed on Solaris 10 i86pc

Hi, > I am not able to build openssl-1.02.a on Solaris 10: > > # uname -a > SunOS corona 5.10 Generic_150401-23 i86pc i386 i86pc Solaris > > # ./Configure solaris-x86-gcc --openssldir=/usr/local/openssl-1.0.2a shared > … > Configured for solaris-x86-gcc. > > # make > > gcc -I. -I.. -I../includ

Re: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()

Hi, Thanks for tips and pointers. As for getting off-topic, I'm the one to blame anyway. So I'm going to strip most of message and comment on points that still might be of public interest. >> (*) BTW, did you try existing [multi-block SHA]? > > No, totally missed it! Found it now, good work! >

Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> I ran some more tests, the issue seems to be optimization not platform > types... If non-matching platform config happens to work, it's a party trick, not support matter. > when I removed -xO[n] from CFLAG, something (either cc or openssl compile set > up) turned back on optimization at -xO3

Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

put line (after your patch): > DBG: zz=89619874872 d0=7 > > > On Tue, May 19, 2015 at 4:04 PM, Andy Polyakov via RT > wrote: >> The commit intention is actually sane. This kind of brings us back to >> question why was it optimized away? BTW, which compiler version is it

Re: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface

> More coming in. Here are preliminary results for 32- and 64-bit ARM. "Preliminary" means that they are incomplete and subject to change. But in a sense they underpin some of the points in previous post, both in message itself and source code commentary. Consider 32-bit results. First column is

Re: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2; Solaris 11.0; Sparc T4; evp_test core dumps

>>> I am building openssl 1.0.2 on a number of platforms, and I am > having >>> problems on a virtual Solaris 11.0 machine running on a Sparc T4. >>> The code builds fine, but the evp_test core dumps. Here are the last >>> lines of output from the command (test/evp_test test/evptests.txt): >>> >>>

Re: [openssl-dev] [openssl.org #3474] selected processor does not support ARM mode `mrrc p15, 1, r0, r1, c14'

> With 1.0.2 beta 2 I'm seeing the following error: > gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector > --param=ssp-buffer-size=4 -Wformat -Werror=format-security > -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecst

Re: [openssl-dev] [openssl.org #3541] [PATCH] BN_nist_mod_521 fails on Windows ARM

> With the change suggested, the tests do succeed. This was committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8b07c005fe006044d0e4a795421447deca3c9f2c and http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=323154be3326a329f768958e9229585a84985747.

Re: [openssl-dev] [openssl.org #3554] [PATCH] aesni-x86_64.pl: zeroize registers, Win64 ABI fix

>>> All internal exports: Zeroize XMM registers that may contain secret >>> data before returning. (At 4x pxors per cycle, the overhead is >>> negligible.) This was committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=23f6eec71dbd472044db7dc854599f1de14a1f48 _

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

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

Re: [openssl-dev] [openssl.org #3827] Suspicious valgrind report

Hi, > I build OpenSSL 1.0.1m on Linux/RedHat with -DPURIFY option and tried > to analyze my app using Valgrind. Thanks to -DPURIFY most warnings > about uninitialized memory are gone, but not all. Remaining ones share > common signature - uninitialized memory comes from stack allocation in

Re: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl()

Hi, For reference. icc was not cared for for quite some time. Initially it was possible for me, by then university employee, to use it, but then they changes terms and it became impossible for me to maintain it. But I've just noticed they provide some starter version of something, I'll see... > L

Re: [openssl-dev] [openssl.org #3844] FW: regarding shared library for openssl -1.0.2a

> Hi all, > I want cross compile openssl for arm-xilinx-linux-gnueabi-gcc > platform .I have downloaded source code openssl-1.02a and I have looked > options for > for configure file. Arm-xilinx-linux-gnueabi is not found in list of > os/compiler option .so I selected linux-

Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> 1) They are "not" two different platforms, merely same command executed for 2 > different versions of openssl.. please see attachment 1 below. It is possible > that 1.0.2a was configured use config where openssl picked defaults and > 0.9.8g was build using "./Configure solaris-x86-cc" Attach

Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

> Found by the https://github.com/xiw/stack tool and then I checked the > generated asm (gcc and clang) to confirm. > > In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true > because the compiler optimizes out the tmp_ulong value to true because > (tmp_ulon

Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> Objective also is to pinpoint the problem to specific algorithm on > specific platform. Mentioning two distinct platforms running different > versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things > clearer. You have to present evidence that directly supports given > assumption,

Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> Thanks for the timely response... below is version we are using. I > also must point out that we are currently using 0.9.8g for several > years, I tried to upgrade to .9.8zf, and several 1.0.x versions and > had the same error. The "./Configure solaris-x86-cc" was used to > install openssl. But

Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

>>> Found by the https://github.com/xiw/stack tool and then I checked the >>> generated asm (gcc and clang) to confirm. >>> >>> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >>> because the compiler optimizes out the tmp_ulong value to true because >>> (tmp_ulong = zz >> d1

Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac

> I am getting following error connecting to a server running on Solaris 10 > only from other platform (Linux, HP, Windows). Connection is dropped by > Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record > mac > > (this is also t

Re: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out

> Found by the https://github.com/xiw/stack tool and then I checked the > generated asm (gcc and clang) to confirm. > > In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true > because the compiler optimizes out the tmp_ulong value to true because > (tmp_ulong = zz >> d1;) zz >> d1

Re: [openssl-dev] [openssl.org #3753] BUG: arm support ASM code incorrect for BE8

> The ARM assembly code implements some probing for the CPU at runtime > and uses hard coded byte sequences for the probe code. > > This way does not work for arm object file formats using new big endian > (BE8) mode. It is, however, very simple to fix: > > The armv4cpuid.S code (generated from a

Re: [openssl-dev] [openssl.org #3750] Compile 1.0.2 with RC4: rc4_md5_enc not found

Hi, > I run > > ./Configure threads zlib-dynamic linux-x86_64:"gcc -O3 -flto -Wl,-S" This thing, config-line:command-line, doesn't work as you expect. In the nutshell you're expected to provide *whole* config line with all those fields delimited by colons (see linux-x86_64 line in Configure). A

Re: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match

>> One thing to try would be to try both ways of the define for __thumb. This >> can explain the fingerprint failure. >> >> In fips_canister.c around line 188 >> >> # if defined(__thumb__) || defined(__thumb) >> return (void *)((size_t)instruction_pointer&~1); >> # else >> return (void *)

Re: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64 bit version

Hi, > Are you aware of the file system redirector on Windows for running 32 > bit applications on a 64 bit OS ? > The issue could be that you're testing two completely different > binaries, one 32 bit and one 64 bit, hence the different result. I would actually put as "the issue *is*", as opposit

Re: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match

>> I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly >> as provided without any modifications. >> Additionally, I built fips_algvs.exe to successfully validate the canister >> on the target system. >> >> After tweaking some #ifdef directives in the openSSL 1.0.1L, I was a

Re: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match

> One thing to try would be to try both ways of the define for __thumb. This > can explain the fingerprint failure. > > In fips_canister.c around line 188 > > # if defined(__thumb__) || defined(__thumb) > return (void *)((size_t)instruction_pointer&~1); > # else > return (void *)instruc

Re: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds

>> I am also having a issue this issue. It is a 32 bit build issue >> only. The 64 bit build completes using the same development >> environment. The offending instruction is "movd". Unfortunately >> I am not a x86 assembler expert. >> >> Mark >> >> perl crypto\sha\asm\sha1-586.pl win32

Re: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2; Solaris 11.0; Sparc T4; evp_test core dumps

Hi, > I am building openssl 1.0.2 on a number of platforms, and I am having > problems on a virtual Solaris 11.0 machine running on a Sparc T4. > The code builds fine, but the evp_test core dumps. Here are the last > lines of output from the command (test/evp_test test/evptests.txt): > > Testing

Re: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds

> I am also having a issue this issue. It is a 32 bit build issue > only. The 64 bit build completes using the same development > environment. The offending instruction is "movd". Unfortunately > I am not a x86 assembler expert. > > Mark > > perl crypto\sha\asm\sha1-586.pl win32 /MD /

Re: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in 1.0.2-stable for Windows builds

> Is the Windows build broken on 1.0.2-stable, am I doing something wrong, > or is this a tool chain issue? > > Assembling: tmp32\sha1-586.asm > tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands > tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands > NMAKE : fat

Re: [openssl-dev] [openssl.org #3607] nistz256 is broken.

>> Attached. A little bit worse performance on some CPUs. I also took >> opportunity to harmonize ecp_nistz256_from_mont by applying same pattern >> for reduction. The patch is cumulative, i.e. is not incremental to >> previously posted one[s], and addresses both problems, originally >> reported on

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

> Excellent. My summary is: > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect > my program in operation (you will probably say "will not affect") Well, as there is suggestion of what I would say, I would only say that it's false positive. > - when OpenSLL 1.0.2 eventu

Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

> The demo program actually allocates a whole extra block for the output, so > there should always be extra space available. Yes, which is why I said "as for alleged buffer overruns in *your* program". I mean you said "I discovered this [suspected buffer overrun] in my real code" and as you didn'

Re: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64

> OpenSSL is currently not supported under Cygwin64. Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a little bit more about what kind of problem does it cause. The Cygwin64 support was submitted by Cygwin maintainer, and no additional issues were reported. __

Re: [openssl.org #3623] faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b.

> Am using openssl for my monitoring tools and i have facing *faulting module > ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b *in application > log and its all type of windows OS > May i know that it is known issue or new issue,if it is known issue please > provide issue id. > > Kindly

Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext

> I started with an AES256 demo I found at https://github.com/saju/misc and > modified the initialisations to use AES128. The test strings that program > uses are quite short - less than 100 characters. If I add a significantly > longer string to those test values Valgrind reports a string of wh

Re: [openssl.org #3607] nistz256 is broken.

Oops! Wrong patch! Correct one attached. If you feel like testing the wrong one, go ahead, but there are some later non-essential adjustments. diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c index bf3fcc6..33b07ce 100644 --- a/crypto/ec/ecp_nistz256.c

Re: [openssl.org #3607] nistz256 is broken.

>>> Oops! Wrong patch! Correct one attached. If you feel like testing the >>> wrong one, go ahead, but there are some later non-essential adjustments. >>> >>> diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c >>> index bf3fcc6..33b07ce 100644 >>> --- a/crypto/ec/ecp_nistz256.c >>> ++

Re: [openssl.org #3607] nistz256 is broken.

>> Oops! Wrong patch! Correct one attached. If you feel like testing the >> wrong one, go ahead, but there are some later non-essential adjustments. >> >> diff --git a/crypto/ec/ecp_nistz256.c b/crypto/ec/ecp_nistz256.c >> index bf3fcc6..33b07ce 100644 >> --- a/crypto/ec/ecp_nistz256.c >> +++ b/cry

Re: [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface

Hi, > This patch is a contribution to OpenSSL. > It includes efficient implementations of Dan Bernstein's Poly1305 > (authenticator) and ChaCha20 (stream cipher). Incidentally I'm working on this too and already have ChaCha module. What I've learned is that ChaCha SIMD performance is a delicate

Re: [openssl.org #3607] nistz256 is broken.

> thanks! Was away last week and so didn't have a chance to try fixing this. > > I'll patch that it and run the tests against it. I've run out of time tracking this down for today, but I got to the point where setting the Jacobian coordinates: X: C4EB2994C09557B400FF

<    1   2   3   4   5   6   7   8   9   >