The OpenSSL status page is out of date
Hi, The OpenSSL status page, https://openssl.org/news/status.html, is a bit out of date. According to it, the next minor releases are 0.9.8x, 1.0.0j, and 1.0.1c. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1 released
On Wed, Mar 14, 2012 at 10:09:22 -0500, OpenSSL wrote: -BEGIN PGP SIGNED MESSAGE- We consider OpenSSL 1.0.1 to be the best version of OpenSSL available and we strongly recommend that users of older versions upgrade as soon as possible. OpenSSL 1.0.1 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ It seems to be missing from the FTP site. -- Iain Morgan PS: Contrats (and thanks) on releasing 1.0.1! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Call for OpenSSL FIPS Object Module v2.0 review
On Wed, Apr 06, 2011 at 16:11:40 -0500, Steve Marquess wrote: On 04/06/2011 04:03 PM, Roumen Petrov wrote: Steve Marquess wrote: The ongoing effort to obtain a new FIPS 140-2 validation for an OpenSSL based cryptographic module has committed enough source code to permit general review and feedback. If you have an interest in this upcoming validated module please feel free to examine the current results in CVS HEAD (see http://www.openssl.org/source/repos.html). [SNIP] -Steve M. May be is good to be documented that fips-2.0 module require sse2. As I understand no-asm build is not in the validation list yet as work-around for old i?386 processors. Correct, we have no sponsors yet for any no-asm builds, and I don't expect to get any. It's not to late to sign additional platform sponsors, though (hint, hint). -Steve M. To add to Steve's hint, from my perspective it would certainly be nice to see a sponsor step up for a *nix platform using the AES-NI instructions. It would seem to be a reasonable investment for one of the major OS distributors. But that is just my opinion. -- Iain Morgan The views expressed above do not necessarily reflect those of the Federal government or any of its agencies. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Getting OpenSSL to use special Intel AES Hardware on Westmere
On Sun, Jun 27, 2010 at 23:52:45 -0500, Nick Lindberg wrote: Hello, I'm trying to figure out the best way to run OpenSSL on a Westmere system and have it leverage the new AES instructions built into the Westmere ISA. I've read about trying to run a patched version, such as suggested here: If you are using code from cvs HEAD and your applications call OPENSSL_config(), then it is just a matter of setting up a suitable openssl.cnf file. A minimalistic file would look something like this: openssl_conf = openssl_init [openssl_init] engines = engine_section [engine_section] aesni = aesni_engine [aesni_engine] default_algorithms = ALL Note also that with the recent creation of the 1.0.1 branch, there will hopefully be a release version that includes the AES-NI support in the near future. However, the support hasn't been backported yet. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2271] bug report / enhancement request
On Thu, May 20, 2010 at 02:34:27 -0500, Skelton, Roch via RT wrote: To ensure compliance with high security environments, I would like to build my copy of openssl without support for the LOW and MEDIUM ciphers. After reviewing the various cipher and config options, I decided to use the following configuration: ./config zlib shared no-RC2 no-RC4 no-SEED no-IDEA no-DES This command line was acceptable to configure, but unfortunately the actual build process fails. Disabling any cipher results in a fatal error to the build when completing the make in ./crypto/(cipher). Hmm, have you tried using lower-case names for the ciphers? This worked for me: $ ./config zlib no-rc2 no-idea no-seed no-des $ make depend $ make Note that the build _did_ fail if no-rc4 was specified. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Slow AES and RC4 performance on Intel Westmere
cbc 74433.59k80153.79k82086.91k 175156.05k 177280.34k aes-256 cbc 64822.50k69178.15k70595.58k 150416.73k 151677.19k Note the difference in the RC4 performance between these two systems which are both nominally running at 3.0 GHz. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Q] AES performance with 1.0.0 beta 2
I tested the 20090515 1.0 snapshot on both of the two systems mentioned in the previous posts as well as several other Intel systems. In all of the cases, the AES performance is now in the range I would expact. Thanks Iain On Thu, May 14, 2009 at 16:14:04 -0700, Iain Morgan wrote: Hi Andy, Thanks. I tried the latest from CVS this morning and it fixed the Athlon 64 issue but not the Xeon one. To play it safe, I'll test the snaphost tomorrow on both systems and let you know the results. Iain On Thu, May 14, 2009 at 14:30:08 -0500, Andy Polyakov wrote: Hi, For the Athlon64 system, I get the following: $ gcc -o cpuid cpuid.c Thanks for feedback. Recent commits refine shared cache detection logic and should provide usual large block performance on AMD and Core2. Verify tomorrow snapshot or patch according to http://cvs.openssl.org/chngview?cn=18161. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Iain Morgan -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [Q] AES performance with 1.0.0 beta 2
Hi Andy,
For the Athlon64 system, I get the following:
$ gcc -o cpuid cpuid.c
$ ./cpuid
0001:68747541:444d4163:69746e65
00020f32:01020800:0001:178bfbff
I also see similar behaviour on an Intel Xeon system also using the
linux-x86_64 target. Using the 8192 byte column from the speed output for
aes-128-cbc, I get the following:
0.9.8k: 209117.18k
1.0.0 beta2: 98832.30k
1.0.0 beta2 (no-asm): 185606.83k
For that system, the cpuid output is:
$ ~/cpuid
000a:756e6547:6c65746e:49656e69
00010676:03040800:000ce3bd:bfebfbff
0c000121:01c0003f:003f:0001
On Wed, May 06, 2009 at 15:13:32 -0500, Andy Polyakov wrote:
I'm not sure if this topic has been brought up previously, but I've
noticed that the AES performance with the linux-x86_64 target seems to
have dropped relative to 0.9.8k. This is on an AMD Athlon64 X2 with GCC
4.1.2.
Could you compile attached problem and submit its output? This is for
reference and to double-check that everything is detected correctly.
I'm curious as to the cause of this and whether it is intentional (to
mitigate a timing attack, perhaps)
Bullseye. For further information see crypto/aes/asm/aes-596.pl, second
half of commentary section.
or whether it is an accidental side-effect.
No.
Strangely, the AES performance is actaully _better_ with the no-asm flag,
although not as good as 0.9.8k.
But it would still be faster is C would implement equivalent code. A.
Content-Description: cpuid.c
#include stdio.h
main()
{ unsigned int eax,ebx,ecx,edx,max;
max=0;
__asm volatile (cpuid :
=a(max),=b(ebx),=c(ecx),=d(edx):0(max));
printf(%08x:%08x:%08x:%08x\n,max,ebx,ecx,edx);
eax=1;
__asm volatile (cpuid :
=a(eax),=b(ebx),=c(ecx),=d(edx):0(eax));
printf(%08x:%08x:%08x:%08x\n,eax,ebx,ecx,edx);
if (max4) return 0;
eax=4; ecx=0;
__asm volatile (cpuid :
=a(eax),=b(ebx),=c(ecx),=d(edx):0(eax),2(ecx));
printf(%08x:%08x:%08x:%08x\n,eax,ebx,ecx,edx);
}
--
Iain Morgan
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[Q] AES performance with 1.0.0 beta 2
Greetings, I'm not sure if this topic has been brought up previously, but I've noticed that the AES performance with the linux-x86_64 target seems to have dropped relative to 0.9.8k. This is on an AMD Athlon64 X2 with GCC 4.1.2. I'm curious as to the cause of this and whether it is intentional (to mitigate a timing attack, perhaps) or whether it is an accidental side-effect. Strangely, the AES performance is actaully _better_ with the no-asm flag, although not as good as 0.9.8k. $ apps/openssl speed aes 2/dev/null OpenSSL 1.0.0-beta2 21 Apr 2009 built on: Mon May 4 11:30:22 PDT 2009 options:bn(64,64) md2(int) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 62629.24k66329.47k67789.31k68298.75k68444.16k aes-192 cbc 53112.54k55611.33k56815.96k56963.41k57103.70k aes-256 cbc 45772.33k48082.33k48698.60k49045.85k49116.50k $ apps/openssl speed aes 2/dev/null OpenSSL 0.9.8k 25 Mar 2009 built on: Mon May 4 11:14:36 PDT 2009 options:bn(64,64) md2(int) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(ptr2) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=100 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-128 cbc 81646.60k 127745.62k 152414.09k 159444.31k 161783.81k aes-192 cbc 72642.27k 110940.37k 129796.27k 135063.56k 137297.92k aes-256 cbc 67243.52k99031.17k 113838.59k 118624.75k 119619.58k Thanks -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: sha1-ia64.s compile problems on SUSE LINUX Enterprise Server 9 (ia64) with icc 10.0.026
On Thu, Sep 06, 2007 at 14:29:17 +0200, Andy Polyakov wrote: I am testing out the newest version of icc (10.0.026) on a SLES 9 ia64 system and having troubles building openssl-0.9.8e. I recieve the following errors: make[2]: Entering directory `/home/scottra/src/openssl-0.9.8e/crypto/sha' icc -I.. -I../.. -I../../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt -Dmemcpy=__builtin_memcpy -Dmemset=__builtin_memset -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -c -o sha1-ia64.o sha1-ia64.s icc: command line remark #10010: option '-no_cpprt' is deprecated and will be removed in a future release. See '-help deprecated' First of all! Could you send output from 'icc -help deprecated'. Question basically is if there is suggested alternative. Not having seen a response yet, here's the output from the 10.0.026 compiler: cfe2.imorgan icc -help deprecated Deprecated Options -- -alias-argsuse -fargument-alias -Obuse -inline-level=n -c99 use -std=c99 -create-pchuse -pch-create -cxxlib-gcc[=dir] use -cxxlib[=dir] -cxxlib-iccNo replacement -fpuse -fomit-frame-pointer -fpstkchk use -fp-stack-check -fwritable-strings No replacement -i-dynamic use -shared-intel -i-static use -static-intel -Kc++ use -x c++ -no-c99use -std=c89 -no-cpprt use -no-cxxlib -nobss-inituse -no-bss-init -norestrictuse -no-restrict -openmpP use -openmp -openmpS use -openmp-stubs -opt-report-level use -opt-report -qpuse -p -use-pch use -pch-use -IPF-fp-speculationuse -fp-speculation cfe2.imorgan So, -no-cxxlib would be the right choice, but -static-intel it might be helpful to also use -static-intel. /home/scottra/src/openssl-0.9.8e/crypto/sha/sha1-ia64.s(21) : error A2132: operand no 2: illegal register value: 0 /home/scottra/src/openssl-0.9.8e/crypto/sha/sha1-ia64.s(1597) : error A2132: operand no 2: illegal register value: 0 sha1-ia64.s:21 and 1597 have the same line: .save ar.pfs,r0 I believe these lines come from asm/sha1-ia64.pl lines 255 and 410 respectively. I briefly read through the IA-64 Architecture Assembly Language Reference Guide and based on my read it sure seems that r0 is one of the general purpose 64-bit registers. I wonder if this is a bug in icc 10.0.026? Well, r0 is special. It's a sink/wired-zero register, i.e. you can write to it, but if you try to read it you'll always get 0. I can't recall the reason why .save ar.pfs,r0 lines were added, but essentially it's equivalent to no-operation and you should simply *remove* them. Do not replace r0 with anything, but simply remove all occurrences of .save ar.pfs,r0. A. Good to see this explanation. I had likewise encountered this problem a while back, but due to a lack of time I don't think I reported it. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
On Sat, Jun 09, 2007 at 14:52:27 +0200, Frank Büttner wrote: Kurt Roeckx schrieb: On Fri, Jun 08, 2007 at 05:00:37PM -0700, David Schwartz wrote: Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? You should compare with the best optimization flags for each compiler. I don't see any of the typical icc optimization flags used, like -ip, -march=pentium4, -msse3, -xP, or whatever is appropriate for your CPU. I don't think -march=pentium4 is going to work on an IA64, and I have my doubts about sse3 too. Note that IA64 is not an x86_64/amd64/x64. Kurt Have you try the last version of the intel compiler(10.0)? Not yet, the system I'm building on does not have the 10.0 compilers. However, that is something I intend to try. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
On Mon, Jun 11, 2007 at 11:18:53 -0700, Rick Jones wrote: My favorite starting point, when I have little else to go on is to try to pick something close from a SPECint suite and use the settings the submittor used for it. Still would be nice to know if the stuff that was supposed to be assembly was still assembly when using icc rather than gcc. rick jones I hadn't thought of comparing against something from SPECint, but that's an interesting idea. Yes, it does look like icc is using the assembly language code. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
OK, I've made some headway on this. First, I'd like to thank all those who have provided input. It looks like the issue might not be the lack of an additional optimization option, but the adverse affect of one of the optimizations included by -O2. I tried a build with -O1 instead and got much better results: cfe2.imorgan apps/openssl speed aes bf rc4 md5 sha1 2/dev/null OpenSSL 0.9.8e 23 Feb 2007 built on: Mon Jun 11 12:12:59 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: icc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O1 -Wall -no_cpprt -i-static -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 8507.03k27722.30k75531.10k 132557.28k 169630.22k sha1 9792.46k27468.37k81129.39k 159646.12k 222044.16k rc4 239281.42k 298509.16k 312526.86k 317020.73k 317904.21k blowfish cbc 51905.17k55981.70k57137.15k57406.12k57450.08k aes-128 cbc 80270.47k91255.53k94353.92k95308.12k94093.90k aes-192 cbc 73833.99k83016.73k85580.54k86355.07k85327.87k aes-256 cbc 68343.73k76161.19k78277.94k78952.79k77976.92k Iain Morgan wrote: Hello, Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? Thanks -- Iain Morgan cfe2.imorgan apps/openssl speed aes bf rc4 md5 sha 2/dev/null OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 10:46:48 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 8388.37k27899.28k73067.45k 123142.98k 153932.33k sha1 10270.44k33538.23k93979.13k 171431.58k 224889.51k rc4 248141.11k 299502.68k 312819.11k 316454.57k 317876.62k blowfish cbc 52879.87k56659.39k57974.95k58306.56k58335.11k aes-128 cbc 56603.67k78418.22k86639.62k89007.75k88984.23k aes-192 cbc 53353.86k72285.93k79266.68k81229.82k81267.37k aes-256 cbc 50445.43k67040.72k72999.08k74656.43k74604.54k sha256 10808.77k29896.92k62069.85k84877.31k95065.43k sha5127113.80k28534.17k72103.59k 134958.08k 181021.35k cfe2.imorgan $NOBACKUP/build/bin/openssl speed aes bf rc4 md5 sha 2/dev/nul OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 09:27:49 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: icc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt -i-static -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 5835.63k20437.19k60845.48k 119983.98k 166928.38k sha1 6356.02k19805.21k63273.44k 140241.24k 216834.46k rc4 247902.49k 299131.32k 314115.67k 317933.50k 318111.74k blowfish cbc 50625.69k59182.33k61785.80k62476.09k62615.65k aes-128 cbc 47999.54k51204.48k52011.06k52207.27k51920.38k aes-192 cbc 45619.43k48507.73k49234.01k49402.50k49119.23k aes-256 cbc 43471.76k46080.66k46732.78k46890.42k46632.80k sha2566729.22k21080.31k50995.71k79001.82k94085.12k sha5124036.13k16274.26k48357.42k 109740.71k 174342.74k __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED] -- Iain Morgan __ OpenSSL Project
Performance on IA64 using icc vs gcc
Hello, Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? Thanks -- Iain Morgan cfe2.imorgan apps/openssl speed aes bf rc4 md5 sha 2/dev/null OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 10:46:48 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O3 -Wall -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 8388.37k27899.28k73067.45k 123142.98k 153932.33k sha1 10270.44k33538.23k93979.13k 171431.58k 224889.51k rc4 248141.11k 299502.68k 312819.11k 316454.57k 317876.62k blowfish cbc 52879.87k56659.39k57974.95k58306.56k58335.11k aes-128 cbc 56603.67k78418.22k86639.62k89007.75k88984.23k aes-192 cbc 53353.86k72285.93k79266.68k81229.82k81267.37k aes-256 cbc 50445.43k67040.72k72999.08k74656.43k74604.54k sha256 10808.77k29896.92k62069.85k84877.31k95065.43k sha5127113.80k28534.17k72103.59k 134958.08k 181021.35k cfe2.imorgan $NOBACKUP/build/bin/openssl speed aes bf rc4 md5 sha 2/dev/nul OpenSSL 0.9.8e 23 Feb 2007 built on: Fri Jun 8 09:27:49 PDT 2007 options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) aes(partial) idea(int) blowfish(idx) compiler: icc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wall -no_cpprt -i-static -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM available timing options: TIMES TIMEB HZ=1024 [sysconf value] timing function used: times The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes md5 5835.63k20437.19k60845.48k 119983.98k 166928.38k sha1 6356.02k19805.21k63273.44k 140241.24k 216834.46k rc4 247902.49k 299131.32k 314115.67k 317933.50k 318111.74k blowfish cbc 50625.69k59182.33k61785.80k62476.09k62615.65k aes-128 cbc 47999.54k51204.48k52011.06k52207.27k51920.38k aes-192 cbc 45619.43k48507.73k49234.01k49402.50k49119.23k aes-256 cbc 43471.76k46080.66k46732.78k46890.42k46632.80k sha2566729.22k21080.31k50995.71k79001.82k94085.12k sha5124036.13k16274.26k48357.42k 109740.71k 174342.74k __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Performance on IA64 using icc vs gcc
On Fri, Jun 08, 2007 at 17:00:37 -0700, David Schwartz wrote: Using the Intel 9.1 compiler on an IA64 system the performance of AES and (to a lesser extent) other algorithms implemented in assembly language is less than that using gcc. I've included the speed output for several of the algorithms below. Is this a know issue and is there a workaround other than switching to gcc? You should compare with the best optimization flags for each compiler. I don't see any of the typical icc optimization flags used, like -ip, -march=pentium4, -msse3, -xP, or whatever is appropriate for your CPU. DS The options used in the icc case were simply those set by ./Configure linux-ia64-icc. The one option that I added was -i-static to force static linking to libimf. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1114] Bug: RC4 on IA64 and OpenSSH
On Sun Jun 26 10:42:05 2005, Andy Polyakov via RT wrote: When building OpenSSH 4.1p1 against OpenSSL 0.9.7g on Itanium (Linux) the OpenSSH 'make tests' regression tests fail wrt the RC4 cipher. Verify ftp://ftp.openssl.org/snapshot/openssl-0.9.7-stable-SNAP-20050627.tar.gz *as it becomes available* and report back. A. Yes! That seems to do the trick. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1114] Bug: RC4 on IA64 and OpenSSH
On Tue Jun 14 13:12:00 2005, Iain Morgan via RT wrote: If OpenSSL is built with the 'no_asm' flag, the problem goes away. Alternatively, if RC4_CHAR is set and SZ in crypto/rc4/asm/rc4-ia64.S is changed from 4 to 1, the problem also goes away. Oops. These workarounds don't actually work. I had modified try-ciphers.sh in the OpenSSH regression suite in order to bypass any testing of the RC4 cipher so that the rest of the regression tests could be completed. Unfortunately, I forgot to clean up after myself after that. Repeating those tests, with a clean distribution, shows that the workarounds don't actually work. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1114] Bug: RC4 on IA64 and OpenSSH
When building OpenSSH 4.1p1 against OpenSSL 0.9.7g on Itanium (Linux) the OpenSSH 'make tests' regression tests fail wrt the RC4 cipher. At first glance, this appears to be an OpenSSL issue: The tests are successful when OpenSSH is built against 0.9.7e, but later versions fail. Specifically, the following versions have been tried: 0.9.7f, 0.9.7g, and 0.9.8-beta4. Both OpenSSH 4.1p1 and OpenSSH 3.9po1 have been tried. However, the OpenSSL test suite reveals no problem. The ciphertext output from the tests is identical between 0.9.7e and 0.9.7g. It should also be noted that the issue with OpenSSH seems to only occur after the authentication stage when the daemon rekeys the session. If OpenSSL is built with the 'no_asm' flag, the problem goes away. Alternatively, if RC4_CHAR is set and SZ in crypto/rc4/asm/rc4-ia64.S is changed from 4 to 1, the problem also goes away. This has also been filed as bug #1055 with the OpenSSH folks. -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Timeframe for release of 0.9.7f
Hi, I was wondering if there is a timeframe for the release of 0.9.7f (or 0.9.8). There's a project that I'm working on that would benefit from some of the changes in the current 0.9.7 snapshot, but I'd prefer to use a release version rather than a snapshot. Thanks -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: RC4 optimized for AMD64 (+130% speedup)
On Mon Nov 29 14:34:33 2004, Andy Polyakov wrote: [snip] Note that 32-bit code delivers almost 80% of 64-bit performance on AMD. As mentioned in commentary section in rc4-586.pl it's actually possible to achieve 224MBps in 32-bit mode, but I chose to stop at the above figure in order to avoid performance deterioration on legacy platforms and provide best all-round performance. It's trivial to back-port IA-64 and AMD improvements to 0.9.7, but not P4. Is there interest for this? IA-64 code can be improved [as discussed in commentary section], and might be at some later point. Cheers. A. Yes, a back-port of the IA-64 stuff to 0.9.7 would be appreciated! -- Iain Morgan __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
