Hide Forgot
Description of problem: When running `openssl speed`, the reported performance is much lower than one achieved by encrypting /dev/zero using `openssl enc`. Version-Release number of selected component (if applicable): openssl-1.0.1e-10.el6 How reproducible: Always Steps to Reproduce: 1. openssl speed aes-128 2. dd if=/dev/zero bs=8129 count=$((1024*1024*1024/8192)) | openssl enc -aes-128-cbc -k test > /dev/null Actual results: Doing aes-128 cbc for 3s on 16 size blocks: 22353040 aes-128 cbc's in 2.99s Doing aes-128 cbc for 3s on 64 size blocks: 6053019 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 256 size blocks: 1634296 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 1024 size blocks: 885989 aes-128 cbc's in 3.00s Doing aes-128 cbc for 3s on 8192 size blocks: 109596 aes-128 cbc's in 3.00s OpenSSL 1.0.1e-fips 11 Feb 2013 built on: Mon Sep 2 09:53:33 EDT 2013 options:bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DPURIFY -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 119614.93k 129131.07k 139459.93k 302417.58k 299270.14k 131072+0 records in 131072+0 records out 1065484288 bytes (1.1 GB) copied, 2.35492 s, 452 MB/s Expected results: openssl speed being faster than openssl enc Additional info: When using the `openssl speed -evp aes-128-cbc` I get performance of around 640MiB/s so it looks to me that the "standard" encryption routines don't support AES-NI acceleration.
This is not a bug. When you do not use the -evp but the algo directly it will not utilize the AES-NI instructions. This is expected behaviour due to the AES-NI routines being completely separate and decision to which call them being done on the EVP layer. The direct routines should not be used directly by applications also due to FIPS validation requirements.