Bad performance

[shargon]

The peformance compared with OpenSSL is very bad, BigInteger mul and ECDSA, is almost 5 times better in OpenSSL. What it happend?

[busterb]

What OS and CPU?

[shargon]

You can see the difference here:

https://github.com/CityOfZion/neo-hypervm/pull/73#issuecomment-414716688

The tests are made with:

Intel Core i7-6700HQ CPU 2.60GHz (Skylake), 1 CPU, 8 logical and 4 physical cores
Frequency=2531248 Hz, Resolution=395.0620 ns, Timer=TSC
.NET Core SDK=2.1.400
  [Host]     : .NET Core 2.1.2 (CoreCLR 4.6.26628.05, CoreFX 4.6.26629.01), 64bit RyuJIT
  Job-CAVTBJ : .NET Core 2.1.2 (CoreCLR 4.6.26628.05, CoreFX 4.6.26629.01), 64bit RyuJIT

[botovq]

One major factor contributing to the difference is probably' that we use constant time for our internal BN operations. See this mail for more information.

[shargon]

Is 5.4 time slower :S ?

[busterb]

I'm guessing you're also testing on Windows? We literally do not enable any assembly optimizations when building on Windows.

[shargon]

I tested now on linux and is slower too

With libressl (HyperVM)

with openssl (HyperVM)

[0181532686cf4a31163be0bf3e6bb6732bf]

I think it's because for some reason they didn't backport asm speedups from mainline openssl: https://github.com/libressl-portable/openbsd/issues/68

[hdatma]

This is on centos linux, latest version, up to date, running on SuperMicro with Intel(R) Atom(TM) CPU C3558 @ 2.20GHz.

>openssl speed ecdhp521
Doing 521 bit  ecdh's for 10s: 1331 521-bit ECDH ops in 9.98s
LibreSSL 2.8.2
built on: date not available
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: information not available
                              op      op/s
 521 bit ecdh (nistp521)   0.0075s    133.3

> /usr/bin/openssl speed ecdhp521                                                                                                                                                    
Doing 521 bit  ecdh's for 10s: 7187 521-bit ECDH ops in 9.99s
OpenSSL 1.0.2k-fips  26 Jan 2017
built on: reproducible build, date unspecified
options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -Wall -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong 
--param=ssp-buffer-size=4 -grecord-gcc-switches   -m64 -mtune=generic -Wa,--noexecstack 
-DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
-DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM
                              op      op/s
 521 bit ecdh (nistp521)   0.0014s    719.4

[busterb]

ecdhp521 and related optimizations were disabled in 2014 due to issues with gcc and uint128_t on some OpenBSD architectures causing ssh to break with ecdsa keys.

To enable it, you could uncomment #define OPENSSL_NO_EC_NISTP_64_GCC_128 in opensslfeatures.h in LibreSSL 2.7.x and earlier, but in 2.8.x it needs further updates for the constant-time ECC changes.

[busterb]

#460 enabled some optimizations on CMake builds that were disabled by default. Worth about 50% depending on the compiler.

[tysonclugg]

https://resources.infosecinstitute.com/libressl-the-secure-openssl-alternative/:

Memory Sanitization Memory sanitization is a central feature in LibreSSL that is lacking in OpenSSL. Prior to the deallocation of objects, LibreSSL explicitly zeros out memory using OpenBSD’s explicit_bzero(3) function. This proactively reduces the impact of memory exposure in the event of a future vulnerability or an unprivileged process that gains control of a tainted memory segment. The LibreSSL team created portable a module for OSs that do not have these OpenBSD-specific API calls. ... In terms of speed, OpenSSL outperforms or is at best comparable to LibreSSL across all tested ciphers. The performance impact is attributed to the explicit memory sanitization operations within LibreSSL that are not present in OpenSSL and optimization features that were disabled in LibreSSL.

[Vaelatern]

This is a recent test of speed, and it appears the slowdown is quite substantial these days on, in this case, ppc64. Is there any hope of a performance improvement?

https://gist.githubusercontent.com/q66/4f4dc63565cdfafb10c6dde1d3067648/raw/8d2243c22324212af35d3133455c0c7067ab088f/bench.txt

[bob-beck]

This seems to have been fixed by the release of OpenSSL 3. New testing is probably in order.

[Vaelatern]

Are you saying the OpenSSL performance tanked, or that LibreSSL had a release that now contains faster routines?