Re: [openssl.org #3042] [PATCH] Fast implementation of AES-XTS mode for AVX capable x86-64 processors

2013-05-13 Thread Andy Polyakov via RT
Hi, > This patch is a contribution to OpenSSL. > It demonstrates an efficient implementation of AES-XTS, using Intel's > AES-NI and AVX architecture. > The performance improvement provided here is achieved via: a slightly > improved reduction technique, For reference. Criteria for instruction cho

Re: [openssl.org #3003] Enhancement Request - RFC6698 (DANE) TLSA Support

2013-05-15 Thread Andy Polyakov via RT
Hi, > Would you consider adding support for RFC6698 Domain Authentication of > Named Entities (DANE) Transport Layer Association within OpenSSL to > facilitate the wide spread adoption of this technology. There is initial support committed to 1.0.2 branch. This goes against usual practice of de

Re: [openssl.org #3052] [PATCH] OpenSSL 1.0.1e bug fix for x86_64-gf2m.pl use of STDOUT

2013-05-24 Thread Andy Polyakov via RT
> Looks like this goes with bug #2963 ("Windows build bug (perl/nasm > race) on OpenSSL 1.0.0c"). > > Other .pl files were fixed, but this one was somehow missed. Always check repository or snapshots. This was reported and fixed a while ago.

Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included

2013-06-18 Thread Andy Polyakov via RT
Hi, and thanks for report! > I got a strange bug report claiming that "openssl md5" was dumping core on > old parisc hardware. Sure enough, it was generating the correct result > but then crashing: > > $ openssl md5 /dev/null > MD5(/dev/null)= d41d8cd98f00b204e9800998ecf8427e > Segmentatio

Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10

2013-06-18 Thread Andy Polyakov via RT
> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker > script and no longer a symlink. This breaks the config check on i386 for > what binary format to use when building with ASM support. The current > config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X > file

Re: [openssl.org #3074] On PA-RISC, OPENSSL_cleanse() causes crash when called from outside libcrypto, patch included

2013-06-30 Thread Andy Polyakov via RT
>> It's perplexing that it went unnoticed for this long. Is it possible >> that problem was compensated for in specific linker patch-level or >> something? > > It could be. I'm building on an old HP/UX 11.11 machine with a fairly old > toolchain, to ensure the resulting bits will work on a wide

Re: [openssl.org #3080] Android NEON and CFLAGS options

2013-06-30 Thread Andy Polyakov via RT
> In reference to > https://android.googlesource.com/platform/ndk/+/ics-mr0/docs/STANDALONE-TOOLCHAIN.html. > > It appears there are some flags that should be present when targeting > Neon on Android: > > CFLAGS='-march=armv7-a -mfloat-abi=softfp -mfpu=neon' What is the concern exactly? That

Re: [openssl.org #3075] [PATCH] Fix ASM support for FreeBSD 10

2013-06-30 Thread Andy Polyakov via RT
>>> For FreeBSD 10 we have changed /usr/lib/libc.so to be a text linker >>> script and no longer a symlink. This breaks the config check on i386 for >>> what binary format to use when building with ASM support. The current >>> config check expects /usr/lib/libc.so to symlink to a /usr/lib/libc.so.X

Re: [openssl.org #3080] Android NEON and CFLAGS options

2013-07-01 Thread Andy Polyakov via RT
>>> ... >> OpenSSL doesn't have any floating point, at least not on >> performance-critical paths, > I believe the PRNG interface uses floating point operations > (specifically, for the estimate of entropy). Yes, but this doesn't answer the question, what is the concern? That failure to compile Op

Re: [openssl.org #2582] AutoReply: [PATCH] Efficient and side channel analysis resistant 512-bit and 1024-bit modular exponentiation for optimizing RSA1024 and RSA2048 on x86_64 platforms")

2013-07-05 Thread Andy Polyakov via RT
Hi, > This is RSAZ version 2, patching over the new OpenSSL version 1.0.1. The 512-bit exponentiation, one useful for RSA1024 sign, is integrated in "dissected" form. Latter means that unlike original suggestion to implement whole exponentiation as one jumbo assembly subroutine taken approach

Re: [openssl.org #2850] [PATCH] Efficient and side channel analysis resistant 1024-bit modular exponentiation, for optimizing RSA2048 on AVX2 capable x86_64 platforms

2013-07-05 Thread Andy Polyakov via RT
Hi, > This patch offers an efficient and side-channel protected implementation of > 1024-bit Modular Exponentiation, which is useful for RSA2048. > > The implementation is based on the "redundant representation" method, that > Helps accelerating modular exponentiation, when using SIMD archite

Re: [openssl.org #3054] [PATCH] Efficient and side channel analysis resistant 1024-bit and 2048-bit modular exponentiation, optimizing RSA, DSA and DH of compatible sizes, for AVX2 capable x86_64 plat

2013-07-05 Thread Andy Polyakov via RT
Hi, > This patch is a contribution to OpenSSL. > > It offers an efficient and constant-time implementation of 1024-bit > and 2048-bit Modular Exponentiation. When the patch is applied to the > OpenSSL library, it accelerates RSA1024 (verify), RSA2048 (verify and > sign), DSA1024 (verify and sign)

Re: [openssl.org #3093] OpenSSL 1.0.1e masm failure with Visual Studio 11 VC-WIN64A.

2013-07-31 Thread Andy Polyakov via RT
Mike Inman via RT wrote: > crypto/bn/asm/x86_64-gf2m.pl was not finishing code generation before the > assembler started, resulting in errors that looked like: > > set ASM=ml64 /c /Cp /Cx /Zi > perl crypto\bn\asm\x86_64-gf2m.pl tmp32\x86_64-gf2m.asm > ml64 /c /Cp /Cx /Zi /Fotmp32\x86_6

Re: [openssl.org #3094] bug report: osx 10.8.4 won't build with enable-ec_nistp_64_gcc_128

2013-07-31 Thread Andy Polyakov via RT
> I did a quick test, and found that 'make test' succeeds for -O0, -O1, > -Os, and -Oz, but fails for -O2 and -O3. This is using Apple's cc > which is based on clang-3.3 (it describes itself as "clang-500.1.58 > based on LLVM 3.3svn") and openssl-1.0.1e. > > It fails in the "NIST test vectors" sta

Re: [openssl.org #3104] [BUG] Build broken on OSX (RSAZ assembly)

2013-08-03 Thread Andy Polyakov via RT
> it looks that the RSAZ assembly broke build on OSX. > > clang: > /opt/local/bin/perl5 asm/rsaz-x86_64.pl macosx > rsaz-x86_64.s > clang -c -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -DDSO_DLFCN -DHAVE_DLFCN_H -g -arch x86_64 -O3 -DL_ENDIAN -Wall > -DOPENSSL_IA32_SSE2 -DOPENSSL_

Re: [openssl.org #3126] [PATCH 1.0.1e] armcap.c: use getauxv on glibc to find caps

2013-09-15 Thread Andy Polyakov via RT
> More reliable than playing games with signal handling in libraries. While signal-free initialization of OPENSSL_armcap_P is indeed desirable, suggested code doesn't actually solve all the problems. Yes, it would reliably detect NEON capability. But the thing about tick counter is that it's le

Re: [openssl.org #3117] [PATCH] A fast vectorized implementation of binary elliptic curves on x86-64 processors

2013-09-15 Thread Andy Polyakov via RT
Hi, > This patch is a contribution to OpenSSL. > > It offers an efficient and constant-time implementation of the elliptic > curve point multiplication, for the following standard NIST/SECG binary > elliptic curves: > sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, > sect233r1,

Re: [openssl.org #3110] Adding support for x86_64 Cygwin

2013-09-15 Thread Andy Polyakov via RT
Hi, > the below patch adds support for the new 64 bit version of Cygwin, > running on x86_64. Only a few minor Configure and Makefile patches are > required to get it run. > > The patch is against git from today. I hope it's ok to apply this to the > upstream sources. Could you double-check h

Re: [openssl.org #3125] [PATCH 1.0.1e] openssl/crypto/armcap.c: fix a typo in OPENSSL_rdtsc

2013-09-15 Thread Andy Polyakov via RT
> a | 1 is always true, regardless of OPENSSL_armcap_P, and > mrc cp15 will fail on <= v6. > > --- a/crypto/armcap.c > +++ b/crypto/armcap.c > @@ -23,7 +23,7 @@ unsigned int _armv7_tick(void); > > unsigned int OPENSSL_rdtsc(void) > { > - if (OPENSSL_armcap_P|ARMV7_TICK) > + if (OP

Re: [openssl.org #3130] Bug report: Compilation of 1.0.2 fails on Solaris 10

2013-10-03 Thread Andy Polyakov via RT
> I am trying to build 1.0.2 on Solaris 10 with T4 support, the compilation of > both openssl-1.0.2-stable-SNAP-20130918 and openssl-SNAP-20130918 fail with > the following error: > > > cc: Warning: -xarch=v8plus is deprecated, use -m32 -xarch=sparc instead > /usr/bin/perl asm/dest4-sparcv9.pl

Re: [openssl.org #3139] Bug in AES XTS implementation for Windows x64 (truncating pointer to IV)

2013-10-12 Thread Andy Polyakov via RT
> File: openssl/crypto/aes/asm/bsaes-x86_64.pl > Function: bsaes_xts_[en|de]crypt > Commit: fa104be35e24f3fea895d55bb7042d6f4b2963e9 > > Pointer to IV is pulled to $arg6 (line 2109): > mov0xa8(%rsp),$arg6# pull ivp > > However, for x64 $arg6 is defined as r11d (line 1155): > my ($

Re: [openssl.org #3110] Adding support for x86_64 Cygwin

2013-10-14 Thread Andy Polyakov via RT
Hi, >>> the below patch adds support for the new 64 bit version of Cygwin, >>> running on x86_64. Only a few minor Configure and Makefile patches are >>> required to get it run. >>> >>> The patch is against git from today. I hope it's ok to apply this to the >>> upstream sources. >> Could you do

Re: [openssl.org #3151] Bug report: openssl-1.0.1e-28.fc19.i686 on Fedora 19: OPENSSL_ia32_cpuid() misdetects RDRAND instruction on old Cyrix M II i686 CPU

2013-10-28 Thread Andy Polyakov via RT
> I have an old i686 machine with a Cyrix M II CPU running Fedora 19. The > latest version of openssl (openssl-1.0.1e-28.fc19.i686) doesn't work > properly with it due to OPENSSL_ia32_cpuid() misdetecting the RDRAND > instruction (see https://bugzilla.redhat.com/show_bug.cgi?id=1022346 ). > All pre

Re: [openssl.org #3148] Can't compile OpenSSL 1.0.1e on OpenIndiana x86_64 GCC 4.4.4

2013-10-28 Thread Andy Polyakov via RT
> I'm compiling OpenSSL 1.0.1e on OI 151a8 x86_64, using Illumos-GCC 4.4.4 but > failed: > # ./config > # gmakemaking all in crypto...gmake[1]: Entering directory > `/usr/share/src/openssl-1.0.1e/crypto'( echo "#ifndef MK1MF_BUILD"; \ > echo ' /* auto-generated by crypto/Makefile for cry

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

2013-11-08 Thread Andy Polyakov via RT
>> Here is an updated version of the patch. >> >> Addressing a) "pointer to the function" (to select ADCX/ADOX) and b) >> multiple points addition >> >> There is (only) ~1% performance deterioration in due to the pointer being >> passed now, instead of (originally) being static. You can choose whic

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-08 Thread Andy Polyakov via RT
> I encountered a number of unusual (but mostly minor) errors in building > 1.0.1e on Tru64 V4.0G, configuration tru64-alpha-cc. I've addressed the > majority of these in the 20131106 snapshot, and the changes are in the > attached patch. Here is a walk-through: > > crypto/Makefile, > crypto/bn/Ma

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-09 Thread Andy Polyakov via RT
>>> * Tru64 cc(1) can't preprocess stdin; it needs a file >> You can't make such broad statement, as it was verified to work on >> 5.x. > > Well, it doesn't work for 5.1: > > $ uname -a > OSF1 darkstar V5.1 732 alpha > $ echo __osf__ | cc -E - > cc: Error: No source or object file

Re: [openssl.org #3149] [patch] Fast and side channel protected implementation of the NIST P-256 Elliptic Curve, for x86-64 platforms

2013-11-09 Thread Andy Polyakov via RT
>> Do you have any comment from Intel on the concerns regarding the scattering >> technique (http://cryptojedi.org/peter/data/chesrump-20130822.pdf)? > > As discussed off-list in this case the discrepancy is because so called > memory disambiguation logic attempting to move loads ahead of stores,

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-10 Thread Andy Polyakov via RT
>>> Is there an e-mail thread discussing that somewhere? >> No. I was struggling with it from the beginning and it simply was a >> compromise kludge. > > I'm just curious as to what the behavior was. (Was the preprocessor > returning non-zero even though it had correctly processed the file?) If '

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2013-11-12 Thread Andy Polyakov via RT
http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=2df9ec01d563f9cc2deab07e8c3391059d476592 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=5b63a392411822ef4252463cfb914a2ddeee06c6 http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2

Re: [openssl.org #3189] Bugreport & patch: error restoring xmm6 and xmm7 registers in bn_scatter5 on win64 compilation

2013-12-03 Thread Andy Polyakov via RT
Hi, > xmm6 and xmm7 registers are not correctly restored on bn_scatter5 return. > The diff was generated using git HEAD. > > I am using openssl-1.0.1e that contains the bug. On openssl git logs it > appears the bug is present since the first commit when bn_scatter5 was > implemented. Good ca

Re: [openssl.org #3202] Request to remove _sparcv9_random

2013-12-28 Thread Andy Polyakov via RT
Feels like Oracle convention all of a sudden... > I think we need to clarify why this should be done. The lesson is to always report underlying reasons. Because as we see here, it might turn out misleading. > ... The SPARC "random" > instruction was never implemented and never will be implemen

Re: [openssl.org #3235] Re: AES256-SHA256 test failed on OpenSSL-1.0.1f ARM64( compiled with -O3 optimization)

2014-02-24 Thread Andy Polyakov via RT
> Compiled OpenSSL with GCC -O3 optimization on ARM64 might cause > AES256-SHA256 testing fails: > - > [ 3022s] Testing AES256-SHA256 > [ 3024s] Available compression methods: > [ 3024s] NO

Re: [openssl.org #3261] ID1729

2014-02-24 Thread Andy Polyakov via RT
> This bug is still present in lastest release. > > Type: bug > Version: openssl-1.0.1f > Operating system: linux x86_64 ( +all ) http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=758954e0d8232d370ed72b7f86640e40443e1778 thanks for report.

Re: [openssl.org #3252] OpenSSL v1.0.1f issue: decryption failed or bad record mac:s3_pkt.c:484

2014-02-24 Thread Andy Polyakov via RT
> When I’m trying to run > > openssl s_client -connect courtapps.utcourts.gov:443 > > I constantly get an error: > > CONNECTED(0003) > depth=3 C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary > Certification Authority > verify error:num=19:self signed certificate in certificate cha

Re: [openssl.org #3251] Small updates to be able to compile OpenSSL 0.9.8y and 1.0.1f on Borland Builder 4/5 successors

2014-02-24 Thread Andy Polyakov via RT
Hi, > yesterday I needed to build OpenSSL on my own for the first time using > an Embarcadero C++ Builder XE 4, which is a successor of Borland > Builder 4 and 5. I tried the versions 0.9.8y and 1.0.1f just to see > which of both works best. In the end I was able to build both of them > by just fo

Re: [openssl.org #3250] openssl 1.0.1e : compil on win64a creates a NUL file

2014-02-24 Thread Andy Polyakov via RT
Hi, > there is a syntax problem in file ms/do_win64a.bat > "NUL:" must be "NUL" > > possible patch: > --- temp/orig/openssl-1.0.1e/ms/do_win64a.bat2013-02-11 > 16:26:04.0 +0100 > +++ temp/current/openssl-1.0.1e/ms/do_win64a.bat2014-01-31 > 09:13:20.861517000 +0100 > @@ -1,6 +1,6

Re: [openssl.org #3250] openssl 1.0.1e : compil on win64a creates a NUL file

2014-02-24 Thread Andy Polyakov via RT
>>> there is a syntax problem in file ms/do_win64a.bat >>> "NUL:" must be "NUL" >>> >>> possible patch: >>> --- temp/orig/openssl-1.0.1e/ms/do_win64a.bat2013-02-11 >>> 16:26:04.0 +0100 >>> +++ temp/current/openssl-1.0.1e/ms/do_win64a.bat2014-01-31 >>> 09:13:20.861517000 +0100 >>> @@

Re: [openssl.org #3201] EVP_DigestUpdate crashes because of a NULL pointer

2014-02-25 Thread Andy Polyakov via RT
> We have encountered a Segmentation Fault while trying to send a SSL > packet via Oracle VM agent. > > The Segmentation Fault occurred when EVP_MD_CTX_copy() failed in tls1_mac(). > tls1_mac() doesn't check the return code of EVP_MD_CTX_copy() and keep > going, which results in Segmentation Fau

Re: [openssl.org #3087] OpenSSL 1.0.2: seg fault with AES_CBC

2014-02-25 Thread Andy Polyakov via RT
Hi, > We've been testing OpenSSL 1.0.2 AES-CBC, and we encountered a seg fault > when the input length is less than a block size. > > Looking at e_aes.c, aes_cbc_cipher() doesn't have the length check seen > in aes_ecb_cipher(). > I patched aes_cbc_cipher() as follows, and that seems to fix the

Re: [openssl.org #3269] 1.0.2 beta1 on UnixWare

2014-02-26 Thread Andy Polyakov via RT
> Platform: UnixWare 7.1.4 MP4 > OpenSSL 1.0.2 beta1 > > It looks like the latest assembler changes to sha and aes break > on USL assemblers. > > -- > making all in crypto/sha... > cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -DOPENSSL_THREADS -Kthread -DDSO_DLF

Re: [openssl.org #3269] 1.0.2 beta1 on UnixWare

2014-02-26 Thread Andy Polyakov via RT
> | > -- > | > making all in crypto/aes... > | > cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -DOPENSSL_THREADS -Kthread -DDSO_DLFCN -DHAVE_DLFCN_H -D__i386__ -O -DFILIO_H > -Kalloca -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_AS

Re: [openssl.org #3269] 1.0.2 beta1 on UnixWare

2014-02-27 Thread Andy Polyakov via RT
> | Now to track down the next error. > | I took a couple @'s out of Makefile to get more info > | .. > | making all in crypto/cmac... > | if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \ > | (cd ..; make libcrypto.so.1.0.0); \ > | fi > | [ -z "" ] || cc -Kpic -DOP

Re: [openssl.org #3269] 1.0.2 beta1 on UnixWare

2014-02-27 Thread Andy Polyakov via RT
>>> --- Xopenssl-1.0.1f/crypto/aes/aes-586.s2014-02-24 23:09:12.771751012 >>> -0800 >>> +++ openssl-1.0.2-beta1/crypto/aes/aes-586.s2014-02-24 >>> 22:07:47.869751012 -0800 >>> @@ -994,8 +1000,7 @@ >>> call.L004pic_point >>> .L004pic_point: >>> popl%ebp >>> - leal

Re: [openssl.org #3270] 1.0.2 Beta 1 on Solaris 10 Sparc: Assembler warnings

2014-02-28 Thread Andy Polyakov via RT
> 260 new warnings for OpenSSL 1.0.2 Beta 1 on Solaris 10 Sparc. > > /usr/ccs/bin/as: SunOS 5.10 118683-08 Patch 07/05/2012 > > uname -A: SunOS apache 5.10 Generic_142900-07 sun4u sparc SUNW,Sun-Fire-V240 > > gcc (GCC) 4.8.2 > > Problem maybe related to http://cvs.openssl.org/chngview?cn=22016

Re: [openssl.org #3271] OpenSSL 1.0.2 Beta 1 Solaris 10 Sparc Shell error during make install

2014-02-28 Thread Andy Polyakov via RT
> Change > http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=b3ef742cbbc1c8bf0e33dca60f08c65031647b07 > broke "make install" on Solaris. Error message: > > /bin/sh: !: not found > > The new syntax > > - if [ "$(PLATFORM)" != "Cygwin" ]; then \ > + if ! expr "$(PLATFORM)" : "Cygwin" >

Re: [openssl.org #3087] OpenSSL 1.0.2: seg fault with AES_CBC

2014-03-07 Thread Andy Polyakov via RT
>> We've been testing OpenSSL 1.0.2 AES-CBC, and we encountered a seg fault >> when the input length is less than a block size. >> >> Looking at e_aes.c, aes_cbc_cipher() doesn't have the length check seen >> in aes_ecb_cipher(). >> I patched aes_cbc_cipher() as follows, and that seems to fix the

Re: [openssl.org #3275] Bug: GOST HMAC not checking input length

2014-03-07 Thread Andy Polyakov via RT
> The GOST HMAC code using NID_id_GostR3411_94 will segfault if you use > HMAC_Update with zero length input data. This is not complete truth. It crashes with zero length only if data pointer is NULL (or more accurately less that 32) as well. It's not a justification, it's purely for protocol. ht

Re: [openssl.org #3287] [bug] compilation with gcc 4.8.2 of openssl 1.0.1 generate strict-aliasing warnings

2014-04-06 Thread Andy Polyakov via RT
> Got those kind of messages when compiling openssl 1.0.1: > cbc128.c:175:6: warning: dereferencing type-punned pointer will break > strict-aliasing rules [-Wstrict-aliasing] > *(size_t *)(tmp.c+n) ^ *(size_t *)(ivec+n); > ^ > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -DOPE

Re: [openssl.org #3290] 1.0.1e compile issue

2014-04-06 Thread Andy Polyakov via RT
> I am currently building using OpenSSL 0.9.8w > The compile flags etc all come from Intel drop > I would like to move to 1.0.1e (which I know is not the latest) but I have > other SW which uses 1.0.1e > If I look at the delta from 0.9.8w to what Intel provides with their > changes there are mayb

Re: [openssl.org #3191] [BUG] OpenSSL-1.0.2 segfaulting on sha1_block_data_order asm

2014-04-25 Thread Andy Polyakov via RT
> after moving from OpenSSL-1.0.1e to OpenSSL-1.0.2-5ff68e8 our nginx > instances started crashing (very rarely, but still...) with backtraces > pointing to either "sha1_block_data_order_avx" or > "sha1_block_data_order_ssse3", depending on machine. This is happening > when nginx is acting as a cli

Re: [openssl.org #3405] 1.0.2 trunk doesn't build on 64-bit linux

2014-06-14 Thread Andy Polyakov via RT
> The following error occurs using the 20140613 snapshot on the 1.0.2 > trunk. The host is a 64-bit CentOS system. This problem does > not occur on 32-bit CentOS. > > > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H

Re: [openssl.org #3390] Bug report: cannot build with MSVC14

2014-07-01 Thread Andy Polyakov via RT
Hi, > The recently released preview of MSVC14 has changed the ABI for the C > Runtime library. The intent is to avoid having to change it again in > the future, so that DLLs linked against the current version will be > able to safely use later versions. > > In e_os.h there is the following code w

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

2014-07-02 Thread Andy Polyakov via RT
> Discovered this problem while trying to fix > https://github.com/joyent/node/issues/7704. > > Attached is a fix for it. Trouble is that modified code might avoid crash, but it doesn't produce correct result either. [No, not even Adam's suggestion]. Actually bn_mul_mont is abused in bn_exp.c, be

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

2014-07-02 Thread Andy Polyakov via RT
> I'd still pull Adam's changes, at least for consistency reasons. Other > assembly files seems to be using signed comparison for the same kinds of > operations. > > What do you think about it? I think it's appropriate to harmonize branches with interface. But it takes deal of concentration and u

Re: [openssl.org #3397] Fwd: [PATCH] x86_64 asm: fix bn_mul_mont on odd-len BNs

2014-07-02 Thread Andy Polyakov via RT
> I'm totally willing to cooperate on this, and may have enough skills to do > it. > > Do you think it could be possible for us to collaborate on this topic? Sure! I'd appreciate it. Start by preparing patch harmonizing branches with interface. Still I can't promise swift review and reply, so ple

Re: [openssl.org #3390] Bug report: cannot build with MSVC14

2014-07-02 Thread Andy Polyakov via RT
>> As for what to do. As far as I recall the "tangible" reason for redefine was >> that [by 1300 time] definition depended on compiler command line options (or >> wasn't a call to function). If definition does not depend on command line >> *now*, >> *and* always resort to function call, then it wo

Re: [openssl.org #3401] Bug report: compilation fails for OpenSSL_1_0_2-stable on darwin64-x86_64-cc

2014-07-02 Thread Andy Polyakov via RT
> I'm on the OpenSSL_1_0_2-stable branch, commit d85a772, and compilation > fails for darwin64-x86_64-cc with the error reported at the bottom. The > commit that introduced the compilation issue is > 70fddbe32a7b3400a6ad0a9265f2c0ed72988d27. > > If instructed, I can try to help by running more tes

Re: [openssl.org #3431] typo (?) in crypto/sha/asm/sha512-x86_64.pl

2014-07-05 Thread Andy Polyakov via RT
Hi, > As of 04-07-2014, the latest version of crypto/sha/asm/sha512-x86_64.pl > (commit 29be3f6411) in the master branch shows the following at line 2309: > > $code.=<<___ if ($SZ==4 && $shext); > > > Seeing that the variable $shext doesn't exist, but $shaext does, this > might be a typo. > Ple

Re: [openssl.org #3383] ASM support questions for openssl 1.0.1g. in MIPS64 CPU.

2014-07-06 Thread Andy Polyakov via RT
>I am porting Openssl 1.0.1g in Embedded which is developed with OpenWRT - > MIPS64 CPU. > I found SHA is not working and it will always dead when calling > sha1_block_data_order defined in sha1-mips.pl. If I ./configure with no-asm > then everything is fine. > My questions is does sha1-

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
> Running `make test` with Clang sanitizers results in some issues with > unaligned pointers surrounding some uses of buffers cast to a size_t*. > The sanitizers used were `-fsanitize=undefined -fsanitize=address`. Those are conscious choices based on the fact that some CPUs, x86_64 included, are

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
>>> Running `make test` with Clang sanitizers results in some issues with >>> unaligned pointers surrounding some uses of buffers cast to a size_t*. >>> The sanitizers used were `-fsanitize=undefined -fsanitize=address`. >> Those are conscious choices based on the fact that some CPUs, x86_64 >> inc

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
>> ... So that above results >> don't tell anything about benefits of STRICT_ALIGNMENT being undefined. >> And it's usually around 10%. And indeed, I just measured 12.5% on my >> computer. [You have to configure with no-asm, and rig apps/speed.c to >> use misaligned buffers]. > > If I then turn on

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-06 Thread Andy Polyakov via RT
Basically this discussion applies even to tickets #3422 and #3423. This means that I'm not going to comment on those tickets, but do whatever we agree on doing here and close them simultaneously. > I think the main question is if this speed difference is a good > excuse to use undefined behavior o

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-07 Thread Andy Polyakov via RT
>>> As for warning. I personally would argue that we are looking at >>> platform-specific i.e. implementation-defined behaviour, not undefined. >>> Once again, this applies to all three tickets. One is effectively >>> identical to this one, second is about variable shift in CAST. As >>> mentioned t

Re: [openssl.org #3421] PATCH: return appropriate error if RDRAND not available

2014-07-07 Thread Andy Polyakov via RT
For protocol sake, I've taken the case to look into it. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread Andy Polyakov via RT
As for warning. I personally would argue that we are looking at platform-specific i.e. implementation-defined behaviour, not undefined. Once again, this applies to all three tickets. One is effectively identical to this one, second is about variable shift in CAST. As mentio

Re: [openssl.org #3424] Misaligned pointers for buffers cast to a size_t*

2014-07-08 Thread Andy Polyakov via RT
>> ... if you compile with >> -fsanitize, you should also add -DPEDANTIC. >> >> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=021e5043e524b1cb28a929ef902548a987c16e65 >> >> As mentioned this applies to tickets #3422-4. > Looks good to me. Self tests were fine with -DPEDANTIC. > > And

Re: [openssl.org #3435] I updated George Shaw's 0.9.8e port to OS/400 from 2007

2014-07-08 Thread Andy Polyakov via RT
> We will try and look at this again at a later time. I'd argue that it would be more appropriate to handle this by giving it a spot at http://www.openssl.org/contrib/. Well, at the same time we should be open to modifications that can *facilitate* ports to exotic platforms. I mean it doesn't have

Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command

2014-07-11 Thread Andy Polyakov via RT
>> openssl enc command with -aes-xxx-xts doesnt work if an IV is specified > > When you say it "doesn't work", what do you mean? Do you get an error? If so > what is it? If only it was the actual problem. The thing is that *if* one wants to make enc work with XTS, it has to be treated specially,

Re: [openssl.org #3471] [PATCH] md5-asm-aarch64-29regs

2014-07-24 Thread Andy Polyakov via RT
Hi, > I would like to submit a patch for md5 calculation on aarch64 architectures. Thanks for submission, but because of time constraints it will be looked into later. __ OpenSSL Project http://w

Re: [openssl.org #3475] test suite failure on sparc

2014-08-17 Thread Andy Polyakov via RT
Hi, > 1.0.2 beta2 has a testsuite failure on sparc: > Testing cipher CAMELLIA-192-OFB(encrypt) > Key > 8e 73 b0 f7 da 0e 64 52 c8 10 f3 2b 80 90 79 e5 > 0010 62 f8 ea d2 52 2c 6b 7b > IV > 52 ef 01 da 52 60 2f e0 97 5f 78 ac 84 bf 8a 50 > Plaintext > 30 c8 1Makefile:149: recipe for

Re: [openssl.org #3475] test suite failure on sparc

2014-08-17 Thread Andy Polyakov via RT
Kurt Roeckx via RT wrote: > On Sun, Aug 17, 2014 at 04:26:53PM +0200, Andy Polyakov via RT wrote: >> Hi, >> >>> 1.0.2 beta2 has a testsuite failure on sparc: >>> Testing cipher CAMELLIA-192-OFB(encrypt) >>> Key >>> 8e 73 b0 f7 da 0e 64 52 c8

Re: [openssl.org #3471] [PATCH] md5-asm-aarch64-29regs

2014-08-30 Thread Andy Polyakov via RT
Hi, > I would like to submit a patch for md5 calculation on aarch64 architectures. First of all we have to recognize that MD5 is effectively dead and therefore implementing it in assembly is basically just a useful exercise. This doesn't mean rejection, it only affects the priority. And now to th

Re: [openssl.org #3333] [PATCH] Revert "Make Makefiles OSF-make-friendly."

2014-09-12 Thread Andy Polyakov via RT
Hi, > This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. > > When gcc is given a .s file and told to preprocess it, it outputs nothing. > Since gcc targets are more common/important than OSF, revert it and let > the original submitter sort out the problem. > > URL: https://bugs.gentoo

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2014-09-12 Thread Andy Polyakov via RT
> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34 With cross-reference to http://rt.openssl.org/Ticket/Display.html?id= can you confirm that preproc=/tmp/.$@.S assignment works? _

Re: [openssl.org #3333] [PATCH] Revert "Make Makefiles OSF-make-friendly."

2014-09-15 Thread Andy Polyakov via RT
>>> This reverts commit d1cf23ac86c05b22b8780e2c03b67230564d2d34. >>> >>> When gcc is given a .s file and told to preprocess it, it outputs nothing. >>> Since gcc targets are more common/important than OSF, revert it and let >>> the original submitter sort out the problem. >>> >>> URL: https://bugs

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2014-09-19 Thread Andy Polyakov via RT
Hi, >>> http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=d1cf23ac86c05b22b8780e2c03b67230564d2d34 >> With cross-reference to >> http://rt.openssl.org/Ticket/Display.html?id= can you confirm that >> preproc=/tmp/.$@.S assignment works? > > Thanks for following this up. > > The

Re: [openssl.org #3165] tru64-alpha-cc compatibility fixes

2014-09-19 Thread Andy Polyakov via RT
>> I suggest to resort for adding -DOPENSSL_USE_IPV6=0 at config time. I >> couldn't reproduce the problem on two different systems, so it's some >> problem with yours. > > What system(s) are you testing on? We have discussed it earlier, 5.1. And was under impression that you target 5.1 too. You

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

2014-09-23 Thread Andy Polyakov via RT
> When compiling OpenSSL optimized on ARM using the Microsoft compiler, Out of curiosity, which version? There is record of it generating bad code specifically in bn_nist.c. At one occasion it was reported that it generates bad code when optimization is switched off. > the wrong code is being emi

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

2014-09-23 Thread Andy Polyakov via RT
>> When compiling OpenSSL optimized on ARM using the Microsoft compiler, >> the wrong code is being emitted for BN_nist_mod_521 (in bn_nist.c). >> The compiler seems to think that val and temp represent the same item >> when they are clearly one index apart. I've coded a fix that simply >> avoid us

Re: [openssl.org #3550] patch

2014-10-01 Thread Andy Polyakov via RT
Hi, > This is the ppccap.c's patch for Mac OS X with PowerPC G3. > OpenSSL with PowerPC G3 is working fine. But always clash without > OPENSSL_ppccap=0. If by crash you mean http://www.openssl.org/support/faq.html#PROG17, i.e. you suffer from it when debugging, then answer is deal with it. E.g.

Re: [openssl.org #3552] aesni_ecb_encrypt clobbers Win64 callee-save registers

2014-10-01 Thread Andy Polyakov via RT
> crypto/aes/asm/aesni-x86_64.pl: aesni_ecb_encrypt (unlike the other > AES-NI functions) does not save and restore the Win64 ABI callee-save > XMM registers. Oh! The reason must be that originally the module used lower instruction interleave factor and ECB didn't need to off-load any XMM register

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

2014-10-01 Thread Andy Polyakov via RT
> All internal exports: Zeroize XMM registers that may contain secret > data before returning. (At 4x pxors per cycle, the overhead is > negligible.) > > _ctr32: Zeroize $key0 and $ctr. Question is why just aesni module? Why not everywhere? Why not demand that compiler does it too? Why just regis

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

2014-10-01 Thread Andy Polyakov via RT
>> All internal exports: Zeroize XMM registers that may contain secret >> data before returning. (At 4x pxors per cycle, the overhead is >> negligible.) >> >> _ctr32: Zeroize $key0 and $ctr. > > Question is why just aesni module? Why not everywhere? Why not demand > that compiler does it too? Why

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

2014-10-01 Thread Andy Polyakov via RT
>> If you can present >> coherent argument and consensus is reached, then it would have to be >> implemented universally, not only in aesni-x86_64 module. > > So, hopefully my cross-posted message convinced you. No, not really. What I meant was that as long as you can't ask even compiler to wipe

Re: [openssl.org #3149]

2014-10-01 Thread Andy Polyakov via RT
For public reference. The final version committed to repository with following changes: - nameing re-biased to ecp_nistz256, both filenames and functions; - assembly optimized for processors other than Intel Core family; - assembly modules adapted even for non-ELF platforms; - some of higher level

[openssl.org #3552] aesni_ecb_encrypt clobbers Win64 callee-save registers

2014-10-15 Thread Andy Polyakov via RT
The ABI fix is committed, unfortunately RT number is off by one in commit message, 3553 instead of 3552. __ OpenSSL Project http://www.openssl.org Development Mailing List open

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

2014-10-22 Thread Andy Polyakov via RT
> 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 NS

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

2014-10-23 Thread Andy Polyakov via RT
> 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 compl

Re: [openssl.org #3564]

2014-10-23 Thread Andy Polyakov via RT
> 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\libeay

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

2014-10-23 Thread Andy Polyakov via RT
> 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 t

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

2014-10-27 Thread Andy Polyakov via RT
> Followed your instructions regarding changing the target. > But received different problems with the assembler. > See below > > Y:\OpenSSL\openssl-1.0.1i>cmd /c "nasm -f win64 -v" 1>NUL 2>&1 > > Y:\OpenSSL\openssl-1.0.1i>if 1 NEQ 0 goto ml64 > > Y:\OpenSSL\openssl-1.0.1i>perl ms\uplink-x86_64

Re: [openssl.org #3287] [bug] compilation with gcc 4.8.2 of openssl 1.0.1 generate strict-aliasing warnings

2014-11-04 Thread Andy Polyakov via RT
> Building openssl-fips-2.0.6 for linux-x86_64, using gcc 4.8.2 and I am > seeing these same warnings on three files: > cbc128.c > ccm128.c > gcm128.c > > This is first time I've built the FIPS module for this target. For other > targets I've built (using much older gcc cross-compilers, admittedly

Re: [openssl.org #3593] [BUG] 0.9.8 head introduces Win32 compile error C4146

2014-11-08 Thread Andy Polyakov via RT
On 11/07/14 21:54, Kurt Roeckx via RT wrote: > On Fri, Nov 07, 2014 at 11:47:23AM +0100, Kraft, Matthias via RT wrote: >> Hi OpenSSL team, >> >> in an overly eager attempt to fix the compile errors of OpenSSL 0.9.8zc I >> applied all commits that meanwhile arrived against OpenSSL_0_9_8-stable. I

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

2016-02-11 Thread Andy Polyakov via RT
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 #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

2016-02-11 Thread Andy Polyakov via RT
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 #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e

2016-02-12 Thread Andy Polyakov via RT
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 #3759] [PATCH] crypto: use bigint in x86-64 perl

2016-02-12 Thread Andy Polyakov via RT
> 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 #4218] Invalid typecasting in CRYPTO_ctr128_encrypt

2016-02-12 Thread Andy Polyakov via RT
>>> 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

  1   2   3   4   5   6   7   8   9   >