Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

> - GCC 6.1.0 is: KO, 64 & 32 bits: > # Failed test 'running evp_test evptests.txt' > # at ../test/recipes/30-test_evp.t line 18. > # Looks like you failed 1 test of 1. > ../test/recipes/30-test_evp.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests Phew!

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

> Note that a 32-bit Perl can be compiled with or without support for 64-bit > integers. > That fact hit me once doing OpenSSL builds, some 64-bit constants were not > calculated correctly, however that showed up at build time so not likely > to be the case here. However, it might be helpful

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

> I'm sorry to be late. > I was too busy and had to prepare 64 bit gdb (& 64 bit perl). > > It seems to be 32 bit perl (perl-5.24.0) problem. > (Generating 64 bit code with 32 bit perl.) For reference, I'm using 32-bit perl version 5.10.1, minimally supported version, by default, i.e. *all* the

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

> About openssl built/tested on AIX 7.1 , I have an AIX 7.1 machine. > Would you mind saying me which compiler was used ? GCC I guess. Which version > ? The reason for why I said "I'll look at it a bit later today" is that accessing that system is problematic for me for this very moment. And

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

> About the possible "linker quirk", the same linker is used also for version > 1.0.2h which runs perferctly. Yes, but 1.0.2 and 1.1 ppccap's are different. > Also, that does not explain why simply compiling ppccap.c only with -O0 makes > the issue to dispappear. Bugs seldom make sense. If

Re: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O

> Results: > > > In short: > - no issue with v1.0.2h on both machines > - issue appears with: > - XLC -O but only for 64bits > - GCC -O for both 64bits and 32bits > - issue disappears when building ppccap.c with -O0 . > > So, I think that the probability that both XLC and GCC

Re: [openssl-dev] [openssl.org #4664] Enhancement: better handling of CFLAGS and LDFLAGS

> With the current build system, user-defined CFLAGS are accepted as any > unrecognized command line argument passed to Configure. This seems a > little dangerous to me since it means a simple typo could end up > getting passed to the C compiler. Is it more dangerous than interactive access? But

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

There are two commits, one that addresses bio_enc problems and one adding test. Please double-check. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe:

Re: [openssl-dev] [openssl.org #4647] bug report: OpenSSL 1.0.2h: Segment fault on AIX Power8 using optimization code

Hi, > We are using libcurl for REST programming, which internally uses openssl > and libcrypto. > curl suggested to implement few callbacks related to locking, which would > be needed for openssl below 1.1 version(which is still in beta). > > The following callbacks were implemented: > >

Re: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw

> If goal actually is to execute openssl at msys command prompt, then > openssl should be compiled *for* msys, but we don't actually support > this configuration. On related note it appears that reason for why the question about msys support wasn't risen so far is because prior Windows 10,

Re: [openssl-dev] [openssl.org #4654] Failed OpenSSL 1.0.2 compile on Debian 8 with shared config option

> I'm working from the 1.0.2h tarball. The platform is Debian 8 (booted > with syscall.x32=y, but the X32 chroot was not entered). GCC is 5.2.1. > > '-fPIC' was manually added after 'shared' caused the initial > "relocation R_X86_64_32 ..." error. Omitting 'shared' does not witness > an error.

[openssl-dev] [openssl.org #4636] Re: [openssl.org #4625] Re: Are the point-at-infinity checks in ecp_nistz256 correct?

Consider attached diff. > The issue is particularly clear when we multiply the generator by > zero. Note that in general, an application shouldn't multiply the > generator by zero since there's no useful cryptographic purpose for > doing so. But, this is a convenient example. > > In the code we

Re: [openssl-dev] [openssl.org #4648] openssl doesn't work on mingw

> I tested the following command on fedora 24 and mingw64 (mingw64 installed > via git for windows): > > openssl genrsa -des3 -out server.key 1024 > > On fedora, it's instantaneous. > On mingw64, it's stuck before asking the key: > > Generating RSA private key, 1024 bit long modulus >

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

Hi, > I have no time to check with debugger now, Then no progress will be made. Problem needs to be identified first, and since similar problem was identified earlier, I'd have to insist on confirmation whether or not it's the same. > but I do not think it is caused by assembler, > because, > -

Re: [openssl-dev] [openssl.org #4584] Self test failures under X32

> ( cd test; \ > SRCTOP=../. \ > BLDTOP=../. \ > PERL="perl" \ > EXE_EXT= \ > OPENSSL_ENGINES=.././engines \ > perl .././test/run_tests.pl test_afalg ) > ../test/recipes/30-test_afalg.t .. > 1..1 > ALG_PERR: afalg_fin_cipher_aio: io_read failed : Bad address >

Re: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc

Hi, > make test stops on Solaris10 x64. > > > % ./Configure solaris64-x86_64-gcc > > % make > % make test >: > ../test/recipes/01-test_abort.t ok > ../test/recipes/01-test_sanity.t ... ok > ../test/recipes/01-test_symbol_presence.t .. ok >

Re: [openssl-dev] [openssl.org #4530] [BUG] OpenSSL crash on Windows 10

Hi, > Hi, our team have been experiencing a crash in some production > machines (which I cannot reproduce in development machines) caused by > the libeay32 module in 64 bits Windows 10 machines. > > I was able to create a simple "crash application" and was able to get > the dump of the crash

Re: [openssl-dev] [openssl.org #4628] EVP_f_cipher regression due to overlapping regions check

> Does current master work? I think Andy checked in a fix. Rich was few minutes ahead. Now it's committed. Provided test case was verified to work. Thanks for report. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4628 Please log in as guest with password guest if prompted --

Re: [openssl-dev] [openssl.org #4046] Fix xmm6 register clobbering in crypto/bn/asm/x86_64-mont5.pl:bn_power5() under Win64

Hi, > i had some problems on Win64 using BIO_do_handshake/BIO_should_retry in a > loop. The compiler optimizer placed a local variable value in the xmm6 > register. > The content of this register was destroyed after calling BIO_do_handshake. I > debugged this and found that the xmm6/xmm7

Re: [openssl-dev] [openssl.org #4569] Enhancement request: Macros for x86 capability bits

> For x86, define macros for capability bits (like for arm and pcc), according > to https://www.openssl.org/docs/manmaster/crypto/OPENSSL_ia32cap.html: As discussed in RT#4568 and RT#4570, these are internal interfaces and there is no intention to expose it to user, except through setting

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

>>> (gdb) r test/evptests.txt >>> Starting program: /home/jwalton/openssl/test/evp_test test/evptests.txt >>> [Thread debugging using libthread_db enabled] >>> Using host libthread_db library >>> "/lib/arm-linux-gnueabihf/libthread_db.so.1". >>> >>> Program received signal SIGBUS, Bus error. >>>

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

On 7/30/2016 8:18 PM, Andy Polyakov via RT wrote: >>> (gdb) bt full >>> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1 >>> No symbol table info available. >>> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1 >>> No sy

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

>> (gdb) bt full >> #0 0x76eef56c in CRYPTO_ccm128_decrypt () from ./libcrypto.so.1.1 >> No symbol table info available. >> #1 0x76ed6708 in aes_ccm_cipher () from ./libcrypto.so.1.1 >> No symbol table info available. >> #2 0x76edcac0 in EVP_DecryptUpdate () from ./libcrypto.so.1.1 >> No symbol

Re: [openssl-dev] [openssl.org #4630] Fatal error U1077: 'ias' : return code '0x1' on Skylake processor

Hi, > I'm trying to set up OpenSSL on Windows 10 64-bit (i7 Skylake), having > followed the instructions so far, after installing Visual Studio I > attempted to nmake in the openssl directory using Visual c++ 2008 command > prompt to get the following error: > >

Re: [openssl-dev] [openssl.org #4633] EVP self test failure with ARMv8 and Aarch32 flags

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry > Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto > extensions, but includes vmull and crc32 (vmull include arrangements > other than u8). ??? If you're referring to polynomial multiplication, then it's p8,

Re: [openssl-dev] [openssl.org #4632] AutoReply: Configure does not honor ARMv8 and Aarch32 flags

> Attached is a patch that adds two Configure targets: linux-aarch32 and > linux-aarch32hf. It might make a good starting point for Aarch32 > support. > > The patch enables CRC and Crypto extensions by default. Code that utilizes crypto extensions is compiled with -march=armv7-a by default. Or

Re: [openssl-dev] [openssl.org #4632] Configure does not honor ARMv8 and Aarch32 flags

> Working from 1a627771634adba9d4f3b5cf7be74d6bab428a5f on a Raspberry > Pi 3. Its ARMv8 with Broadcom SoC using A53 cores. It lacks Crypto > extensions, but includes vmull and crc32 (vmull include arrangements > other than u8). The gadget also runs Raspian, which is a 32-bit OS > with hard

Re: [openssl-dev] [openssl.org #4609] Configure does not honor requests for ld.gold

>> I don't know what you expect us to do. We don't use the LD variable. > > Right. I'm just pointing out gaps. > > It only gets worse for users. What happens when someone tries a > cross-compile by setting CC, AR, RANLIB, LD and a CFLAGS with > --sysroot? As far as I know, there is no RTFM for

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

A quick question about this configuration... Should Linux-x32 enable ec_nistp_64_gcc_128 by default? Does anything prohibit ec_nistp_64_gcc_128 in this configuration? # ./Configure linux-x32 Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) no-asan

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

> ... What one can discuss is to have > ./config (not ./Configure) detect x32 environment and pass alternative > config line to ./Configure. That's how it worked so far and I see no > reason to change it by moving platform detection logic to ./Configure. -- Ticket here:

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

>>> # ./config -mx32 >>> Operating system: x86_64-whatever-linux2 >>> Configuring for linux-x86_64 >>> >>> Perhaps the second case should fail at configure just like the first >>> case. Upon failure, it would be nice to tell the user what to do: >>> "Please configure with ./Configure linux-x32" >>

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

> Fair enough, agreed. > > But Configure ignored my instructions: > > # ./config CFLAGS="-mx32" > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) > target already defined - linux-x86_64 (offending arg:

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

>>> A quick question about this configuration... Should Linux-x32 enable >>> ec_nistp_64_gcc_128 by default? Does anything prohibit >>> ec_nistp_64_gcc_128 in this configuration? >>> >>> # ./Configure linux-x32 >>> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) >>> no-asan

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

> A quick question about this configuration... Should Linux-x32 enable > ec_nistp_64_gcc_128 by default? Does anything prohibit > ec_nistp_64_gcc_128 in this configuration? > > # ./Configure linux-x32 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) > no-asan [default]

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

> you're not allowed to break the compile, regardless of whether there's > a proper "X32" kernel. I don't understand what do you mean by "break the compile". I'd say it's the kind of thing that lies on both parties. We are responsible for providing code and config lines, but you have

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

>> Here's a couple more ways things don't work as expected: >> >> # ./config CFLAGS="-mx32" >> Operating system: x86_64-whatever-linux2 >> Configuring for linux-x86_64 >> Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) >> target already defined - linux-x86_64 (offending arg:

Re: [openssl-dev] [openssl.org #4583] AutoReply: Debian X32 and "fatal error: sys/cdefs.h: No such file or directory"

> Here's a couple more ways things don't work as expected: > > # ./config CFLAGS="-mx32" > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre6-dev (0x0x1016L) > target already defined - linux-x86_64 (offending arg: CFLAGS=-mx32) >

Re: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test

>>> ../test/recipes/30-test_evp.t .. >>> 1..1 >>> Test line 2163(aligned in-place): unexpected error VALUE_MISMATCH >>> Expected: >>>

Re: [openssl-dev] [openssl.org #4578] ARMv7a and failed self test

> The following is from a CubieBoard. I verified I performed a 'make > clean' and 'git pull'. > > $ git rev-parse HEAD > 13c03c8d6da334bb1cde6ce4133e7c75b3b76947 > > ** > > using V=1: > > ../test/recipes/30-test_evp.t .. > 1..1 > Test line 2163(aligned in-place): unexpected

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

> 1) Openssl works correctly (no crash, correct detection), as far as I > can judge. By error-prone I mean, very defensively, that I (or > others) could make a mistake, or that future versions of openssl > could not work exactly the same way. Well, this is effectively argument in favour of

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

> Thanks for the explanations. > > In the code I am working with, I see: > $ sed -n '657p' openssl-1.0.2h/crypto/cryptlib.c > unsigned long *OPENSSL_ia32cap_loc(void) > > You may want to verify it. Right! Sorry about confusion, my bad! It was long in 1.0.x and in became int in master. Anyway,

Re: [openssl-dev] [openssl.org #4568] Enhancement request: Capability vector accessor function for arm and ppc

> Two more observations. > > OPENSSL_ia32cap_loc() alters the underlying OPENSSL_ia32cap_P, the bits not > fitting into the expected integer size being zeroed. I do not know if it is > practically relevant, but it is strange that a read has side effects. It > would be a good reason for

Re: [openssl-dev] [openssl.org #4570] Enhancement request: Configuration option no-hw-aes

> Run-time checking works for x86, but not for arm (OPENSSL_armcap_P is > hidden, I still have to try over environment variables, which are not > as flexible for arm as for x86). > > > Anyway, it would be helpful to exclude hardware aes instructions at > compile-time: > > 1) Runtime checking is

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

> It will be in 1.0.2 shortly. Applied to 1.0.2. > It's not relevant for 1.1 which doesn't support FIPS. Because current 2.x version of FIPS module won't be supported with 1.1, so that solution in 1.1 would have to be different. -- Ticket here:

[openssl-dev] [openssl.org #3100] [patch] remove some useless code in BN_uadd

bn_add.c was modernized in https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=7d6284057b66458f6c99bd65ba67377d63411090 and suggested modifications were "accumulated". Case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=3100 Please log in as guest with

Re: [openssl-dev] [openssl.org #4563] OpenSSL 1.0.2 branch: mem.obj : error LNK2001: unresolved external symbol _cleanse_ctr

> Looking over your logs, you appear to be configuring with no-asm, "no-asm" is the culprit here, but problem is not reporter's but mine. mem_clr.c was updated, but build was not tested with no-asm. Fix is upcoming. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4563 Please log

Re: [openssl-dev] [openssl.org #4548] s390x build problem

>> In other words >> could you double-check attached patch instead? > > Thanks. Just tested and it compiles and the testsuite passes. Committed. Thanks. Case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4548 Please log in as guest with password guest if

Re: [openssl-dev] [openssl.org #4512] ChaCha20_ctr32 function increments 64 bit counter?

Hi, > I'm aware it doesn't affect anything because the caller shouldn't process > more than 2^32 * 64 bytes per key/nonce setup anyway. > > I was just wondering because it differs from the s390 asm implementation > (and whether there is a particular reason to do so). Implementation is

Re: [openssl-dev] [openssl.org #4548] s390x build problem

>>> I'm getting: >>> crypto/chacha/chacha-s390x.S: Assembler messages: >>> crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije' >>> >>> >>> A full build log is available on: >>> https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754 >> >> It's overly

Re: [openssl-dev] [openssl.org #4549] powerpc test problem: missing symbols

> I'm seeing this on powerpc: > ../test/recipes/01-test_ordinals.t . ok > > # Failed test 'check that there are no missing symbols in libcrypto.so' > # at ../test/recipes/01-test_symbol_presence.t line 112. > # Looks like you failed 1 test of 4. >

Re: [openssl-dev] [openssl.org #4550] hppa assembler problem

> I'm getting assembler errors on hppa that look like: > crypto/aes/aes-parisc.s: Assembler messages: > crypto/aes/aes-parisc.s:3: Error: unknown pseudo-op: `.subspa' > crypto/aes/aes-parisc.s:7: Error: Unknown opcode: `aes_encrypt' > crypto/aes/aes-parisc.s:11: Error: Missing function name for

Re: [openssl-dev] [openssl.org #4548] s390x build problem

> I'm getting: > crypto/chacha/chacha-s390x.S: Assembler messages: > crypto/chacha/chacha-s390x.S:7: Error: Unrecognized opcode: `clgije' > > > A full build log is available on: > https://buildd.debian.org/status/fetch.php?pkg=openssl=s390x=1.1.0~pre5-1=1464594754 It's overly easy to get

Re: [openssl-dev] [openssl.org #4491] [PATCH] VMX-crypto: Add XTS support

> Author: Leonidas Da Silva Barbosa > ASM implementation > > Signed-off-by: Paulo Flabiano Smorigo > Signed-off-by: Leonidas Da Silva Barbosa > --- > +my

Re: [openssl-dev] [openssl.org #4523] Failure - make test

Hi, > I got an failure at "make test" sea end of Mail Well, at the end of the mail it says that it failed to link. It's rather indication of something going wrong with *your* compiler setup. We more or less stand for correctness of code and you stand for providing sane compiler environment it

Re: [openssl-dev] [openssl.org #4333] openssl-1.1.0pre3 on IRIX: make test: Unrecognized escape \R passed through

> make test fails on IRIX 6.5 with perl 5.8.9 when building for irix-mips3-cc > and irix64-mips4-cc (the only platforms I've tried so far). Just like with RT#4332 you've got to have at least Perl 5.10. Case is being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4333

Re: [openssl-dev] [openssl.org #4332] openssl-1.1.0pre3 on IRIX: "Something wrong with" config --unified

> I'm trying to build openssl 1.1.0pre3 on IRIX 6.5 with the new unified > building system using perl 5.8.9. This fails with the error message > below. Building without --unified works as expected. Any hints > how to debug this or extract better logs would be appreciated. There is minimal

Re: [openssl-dev] [openssl.org #4463] Undefined behavior in cast/c_enc.c

> $ ./config -fsanitize=undefined Sanitized builds might have to be complemented with -DPEDANTIC. Quoting Configure: # ... Incidentally -DPEDANTIC has # to be used even in sanitized builds, because sanitizer too is # supposed to and does take notice of non-standard behaviour. Similar rule

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

>> Right. What I meant is that a fully reduced h has $h2 < 4. Is it possible >> that $h2, after that adc, ends up at 4, exceeding that bound? If it were, >> that would require one more reduction. >> >> In the non-SIMD paths, I believe this is fine because $r0's and $r1's >> cleared high bits mean

Re: [openssl-dev] [openssl.org #4508] BUG in openssl-1.1.0-pre4 (and current GIT master)

> Openssl-1.1.0-pre4 can't be built for linux-ppc with options no-chacha or > no-poly1305 since crypto/ppccap.c doesn't use OPENSSL_NO_CHACHA and > OPENSSL_NO_POLY1305. This was fixed. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4508 Please log in as guest

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

> Valgrind does not necessarily support all instructions, if > there’s > any optimized assembly, you might run into problems. > Are you able to compile a non-assembly version of the OpenSSL > library? > Are you able to update to a newer Valgrind? Or at least tell

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

> There is a bug in Hercules 3.12 and below as well as Hyperion. In other words, not OpenSSL problem, cases are being dismissed. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4500 Please log in as guest with password guest if prompted -- openssl-dev mailing list To

Re: [openssl-dev] [openssl.org #4500] Testing cipher AES-128-XTS(encrypt/decrypt) failure

> Hi Paul, It doesn't seem unlike that OP is not subscribed, so he won't see responses send to alone. To ensure delivery and or reply to . > I have not checked the code for the test, but I do get the expected > values with my little test program. But what is your host,

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

>>> Valgrind does not necessarily support all instructions, if there’s >>> any optimized assembly, you might run into problems. >>> Are you able to compile a non-assembly version of the OpenSSL >>> library? >>> Are you able to update to a newer Valgrind? >> Or at least tell valgrind version,

Re: [openssl-dev] [openssl.org #4509] ECC key generation under valgrind reports: impossible has happened

> Valgrind does not necessarily support all instructions, if there’s any > optimized assembly, you might run into problems. > Are you able to compile a non-assembly version of the OpenSSL library? > Are you able to update to a newer Valgrind? Or at least tell valgrind version, because I can't

Re: [openssl-dev] [openssl.org #4512] ChaCha20_ctr32 function increments 64 bit counter?

Hi, > The following code in the ChaCha20_ctr32 function in > crypto/chacha/chacha_enc.c looks like you are actually using an IV=[64bit > counter||64 bit nonce] as specified in the "original Bernstein ChaCha" > instead of IV=[32bit counter||96bit nonce] as specified in RFC7539. Correct. While

Re: [openssl-dev] [openssl.org #4520] Camellia asm build failure for 1.1.0pre5 on Solaris (typo in build.info)

> The change > > https://github.com/openssl/openssl/commit/5384d1e4ebd58f31a06b2f5d1f6c4b28f63d72ed > > introduced a typo in the last line of file crypto/camellia/build.info. Fixed. Thanks for report. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4520 Please log in as guest

Re: [openssl-dev] [openssl.org #4439] poly1305-x86.pl produces incorrect output

>>> No, it doesn't depend on call pattern. Please confirm that attached >>> patch solves the problem. Thanks. >>> >> >> (Right, sorry, I meant that the test vectors I have seem to only with >> their corresponding call patterns.) And I meant that I observed failure pattern other than suggested.

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

>>> In the final reduction, $h1 is all ones, so there is one more carry to >>> propagate. Though $h2 can then overflow its two bits, I think? I expect >>> that and the cleared bits of r mean the imulqs in poly1305_iteration are >>> still safe, so we can pick up that slack in poly1305_emit, but I'm

Re: [openssl-dev] [openssl.org #4483] Re: [openssl.org #4482] Wrong results with Poly1305 functions

>> Attached is a sample code that will test various inputs for the >> Poly1305 functions of openssl... > > I'm seeing compiler conversion warnings about size_t to int > truncation. Can you be more specific? > Do you have any vectors that cross the 2GB boundary? -- Ticket here:

Re: [openssl-dev] [openssl.org #4489] PATCH: fix Windows deprecated strdup in crypto\conf\conf_lib.c

On 03/28/16 15:16, Viktor Dukhovni via RT wrote: > >> On Mar 28, 2016, at 4:38 AM, noloa...@gmail.com via RT >> wrote: >> >> On Windows, the fix below also depends upon the patch from Issue 4488 >> ("The POSIX name for this item is deprecated. Instead, use the ISO C++ >>

Re: [openssl-dev] [openssl.org #4483] Wrong results with Poly1305 functions

> For x86-64, this seems to be the bug: > > $ git diff > diff --git a/crypto/poly1305/asm/poly1305-x86_64.pl b/crypto/poly1305/asm/ > poly1305-x86_64.pl > index 3c810c5..bc14ed1 100755 > --- a/crypto/poly1305/asm/poly1305-x86_64.pl > +++ b/crypto/poly1305/asm/poly1305-x86_64.pl > @@ -97,6 +97,7

Re: [openssl-dev] [openssl.org #4483] Re: [openssl.org #4482] Wrong results with Poly1305 functions

> Attached is an updated version of the test with an additional test > vector. This one happens on 64 bit and not on 32 bit. Got it. It will take some time to perform cross-checks. Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4483 Please log in as guest with password

Re: [openssl-dev] [openssl.org #4325] Unified Builds Don't Work With ARM

Hi, > There are a few problems that I am facing with unified builds with arm: > > 1. arm_arch.h is not in the include path. > fatal error: arm_arch.h: No such file or directory > > 2. The arm assembler scripts output to stdout > (see attached output.txt) This was addressed in a bigger sweep

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

On 03/14/16 17:12, Andy Polyakov via RT wrote: >> It looks like the ULL suffix should be safe today; > > This is misleading statement. *Today* U suffix should be safe, because > standard specifies that compiler should pick type automatically > depending on value of the consta

Re: [openssl-dev] [openssl.org #4439] poly1305-x86.pl produces incorrect output

Hi, > You know the drill. See the attached poly1305_test2.c. > > $ OPENSSL_ia32cap=0 ./poly1305_test2 > PASS > $ ./poly1305_test2 > Poly1305 test failed. > got: 2637408fe03086ea73f971e3425e2820 > expected: 2637408fe13086ea73f971e3425e2820 > > I believe this affects both the SSE2 and AVX2

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

>> Is it possible that real target is so called x32, i.e. x86_64 with >> 32-bit address space limitation? In such case linux-x32 would be the >> right target... > > I don't believe this is x32 since {x86_64|amd64} and __ILP32__ are not > defined; see preprocessor output below. Got it. But just

Re: [openssl-dev] [openssl.org #4367] FEATURE: Please add -headerpad_max_install_names to LDFLAGS for dynamic libraries on OS X builds

>> OS X side steps the problems with selecting the wrong runtime library >> and RPATHs by using something called an install name. Effectively, the >> install name should be placed in libcrypto.dylib and libssl.dylib, and >> it calls out the fully qualified path name. Programs linked to a >>

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

> Is it possible that real target is so called x32, i.e. x86_64 with > 32-bit address space limitation? In such case linux-x32 would be the > right target... On side note, I'm getting make test failures for linux-x32 target. I mean if it turns out that it's the right target for you, and you see

Re: [openssl-dev] [openssl.org #4422] OS X 32-bit PowerPC: blake2b.c:27: warning: integer constant is too large for 'unsigned long' type

> It looks like the ULL suffix should be safe today; This is misleading statement. *Today* U suffix should be safe, because standard specifies that compiler should pick type automatically depending on value of the constant. In order words suffices beyond U are required only if you need constant

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit. 32-bit tests OK. The relevant snippets are: $ make test ... ../test/recipes/90-test_async.t ... 1/1 # Failed test 'running asynctest' # at

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

>>> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit. >>> 32-bit tests OK. >>> >>> The relevant snippets are: >>> >>> $ make test >>> ... >>> ../test/recipes/90-test_async.t ... 1/1 >>> # Failed test 'running asynctest' >>> # at

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

> Bump... The issue is still present as of b36a2ef for OS X 10.6 64-bit. > 32-bit tests OK. > > The relevant snippets are: > > $ make test > ... > ../test/recipes/90-test_async.t ... 1/1 > # Failed test 'running asynctest' > # at ../test/testlib/OpenSSL/Test/Simple.pm line 70. > #

Re: [openssl-dev] [openssl.org #4428] Gentoo 12.1, x86_64: crypto/aes/aes_cfb.c:1:0: error: CPU you selected does not support x86-64 instruction set

On 03/14/16 03:58, noloa...@gmail.com via RT wrote: > Working from Master... > > gentoo@Gentoo-2012 ~/openssl $ ./config > Operating system: x86_64-whatever-linux2 > Configuring for linux-x86_64 > Configuring OpenSSL version 1.1.0-pre4-dev (0x0x1014L) > no-crypto-mdebug [default]

Re: [openssl-dev] [openssl.org #4367] FEATURE: Please add -headerpad_max_install_names to LDFLAGS for dynamic libraries on OS X builds

> OS X side steps the problems with selecting the wrong runtime library > and RPATHs by using something called an install name. Effectively, the > install name should be placed in libcrypto.dylib and libssl.dylib, and > it calls out the fully qualified path name. Programs linked to a > library

Re: [openssl-dev] [openssl.org #4366] OS X 10.5, 64-bit PPC, no-asm, and "Failed test 'running asynctest'"

On 03/02/16 03:54, noloa...@gmail.com via RT wrote: > $ make depend && make clean && make > ... > > $ make test > ... > > ../test/recipes/80-test_tsa.t . ok > ../test/recipes/90-test_async.t ... 1/1 > # Failed test 'running asynctest' > # at

Re: [openssl-dev] [openssl.org #4373] OS X 10.5, 32-bit PPC, and missing symbols (_ASYNC_get_current_job, _EVP_MD_meth_set_init, _RSA_PKCS1_OpenSSL, _EVP_MD_meth_new...)

> Working from master: > > $ git reset --hard HEAD && git pull > HEAD is now at e9b1c42 make errors > > Then: > > $ KERNEL_BITS=32 ./config > ... > > $ make depend && make clean && make > ... > > > $ make > ... > > LD_LIBRARY_PATH=..: cc -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_THREADS >

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

>>> If the other EVP ciphers universally allow this then I think we must >> treat this >>> as a bug, because people may be relying on this behaviour. There is also >>> sporadic documentation in lower-level APIs (AES source and des.pod) that >> the >>> buffers may overlap. >>> >>> If it's

Re: [openssl-dev] [openssl.org #4362] chacha-x86.pl has stricter aliasing requirements than other files

> If the other EVP ciphers universally allow this then I think we must treat > this > as a bug, because people may be relying on this behaviour. There is also > sporadic documentation in lower-level APIs (AES source and des.pod) that the > buffers may overlap. > > If it's inconsistent then, at

Re: [openssl-dev] 答复: [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

> 0x2b41740e8da7 <+2967>: je 0x2b41740e8f40 > > 0x2b41740e8dad <+2973>: movdqa 0x40(%r11),%xmm6 > 0x2b41740e8db3 <+2979>: movdqa (%r11),%xmm9 > => 0x2b41740e8db8 <+2984>:

Re: [openssl-dev] [openssl.org #4341] [PATCH] Consistently use arm_arch.h constants in armcap assembly code.

> Patch attached. This is just a little cleanup change to fix not everything > using the OPENSSL_armcap constants. (Existing ones already are using them, > so I'm assuming this is okay.) Applied. Thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4341 Please log in as guest

Re: [openssl-dev] [openssl.org #4360] [BUG] OpenSSL-1.0.1 crash on sha1_block_data_order_ssse3 asm

Hi, > we met crash of openssl (varely, 3 times i have seen) on linux x86_64. > openSSL version is 1.0.1r. > > The stack is as below: > Program terminated with signal 11, Segmentation fault. > Thread 1 (Thread 0x7f0654871700 (LWP 22383)): > #0 0x7f06a2cdddb8 in sha1_block_data_order_ssse3 ()

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not > attempted to debug this, but I have attached a test file which produces > different output in normal and AVX2 codepaths. Our existing poly1305 > implementation agrees with the former. > > $ OPENSSL_ia32cap=0

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

>> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not >> attempted to debug this, but I have attached a test file which produces >> different output in normal and AVX2 codepaths. Our existing poly1305 >> implementation agrees with the former. >> >> $ OPENSSL_ia32cap=0

Re: [openssl-dev] [openssl.org #4346] poly1305-x86.pl's AVX2 code

> There seems to be a bug in the AVX2 codepath in poly1305-x86.pl. I have not > attempted to debug this, but I have attached a test file which produces > different output in normal and AVX2 codepaths. Our existing poly1305 > implementation agrees with the former. > > $ OPENSSL_ia32cap=0

Re: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs

> The fix seems to work. On related note, a problem was reported with poly1305-armv4 module, which was traced down to assembler (different versions disagree about how to treat #-1 as argument to vmov.i64). If you run into problem, don't panic, fix is upcoming... -- Ticket here:

Re: [openssl-dev] [openssl.org #4323] chacha-armv4.pl bugs

Hi, > The partial-block tail code in chacha-armv4.pl also seems to have problems. > My colleague Steven and I made an attempt to debug it, but we're not > familiar enough with ARM to fix it. > > From playing with it in a debugger, it doesn't look like @t[3] contains the > length. We suspect

Re: [openssl-dev] [openssl.org #4305] ChaCha20 assembly bugs

>> 1. In chacha-x86_64.pl, .Ltail: >> >> 2. In chacha-x86_64.pl, .Loop_tail_ssse3: >> >> 3. In chacha-x86.pl, loop: > > Fix is upcoming. Thanks! > >> 4. The assembly versions crash if you pass in an empty input/output. The >> generic C code handles this fine. (I'll defer to you whether this is a

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

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

  1   2   3   4   5   6   7   8   >