I gave openssl 1.0 a shot, compared the “openssl speed” output to my ubuntu openssl 0.9.8g.
green indicates openssl 1.0 is faster.
the numbers are in 1000 bytes per second.
click the image for large version
Versions & Flags:
OpenSSL 0.9.8g 19 Oct 2007
built on: Wed Jan 13 19:52:30 UTC 2010
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -O3 -Wa,--noexecstack -g -Wall -DMD32_REG_T=int -DMD5_ASM
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
OpenSSL 1.0.0 29 Mar 2010
built on: Tue Mar 30 09:37:02 CEST 2010
options:bn(64,64) rc4(1x,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -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
update on 10.04.2010
Victor Duchovni posted similar numbers to the openssl-users list, and David Woodhouse accompanied by git-bisect identified the commit which caused the problem.
That would be:
Likely this is in part intended to address timing attacks. At first
glance, the assembly code seems to have two implementations of AES, a fast
one and a slow one, and some code at the top to choose between them. There
is also a magic number (512 I think) that I am guessing selects the fast
path for blocks of 512 bytes and up and the slow path for smaller blocks.
Can someone confirm that what we are seeing is a work-around for DJB's
cache timing attack on AES? If so, I would guess that the timing attack
is believed to be impractical for large blocks, so the fast path is used
only for sufficiently large inputs...
Are there sound estimates of how quickly the timing signal degrades with
the input size? How conservative is the 512-byte cutoff