Hide Forgot
# rpm -qa | grep openssl | sort openssl-1.0.1e-51.el7_2.7.x86_64 openssl-libs-1.0.1e-51.el7_2.7.x86_64 When running some benchmarks on a PC Engines APU2 (https://pcengines.ch/apu2c4.htm), I am getting strange results depending on what options I use. eg: # openssl speed -evp aes-256-cbc .... The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256-cbc 101025.07k 130968.21k 151159.89k 157963.82k 158736.38k When running two benchmarks at once, the performance of aes-256-cbc tanks: # openssl speed -evp aes-128-cbc aes-256-cbc .... The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 10813.46k 11304.28k 11498.41k 31695.19k 31970.65k aes-128-cbc 123505.79k 170275.01k 205196.76k 216287.57k 219275.26k When running without the -evp option, I get the 'tanked' speed: # openssl speed aes-256-cbc .... The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-256 cbc 10798.20k 11277.01k 11475.63k 31700.65k 31989.76k This doesn't seem to be the expected behaviour for how I understand this should work. Is there a way to verify that the EVP instruction set is being used by default with applications such as apache / openvpn etc?
If the applications use the high level - EVP_Encrypt... API, they'll use AES-NI if available. THe openssl speed without the -evp option uses the low level AES_encrypt API which does not use AES-NI. This is expected behaviour. Your second example uses EVP interface for the algorithm after the -evp option and the low-level interface for the second one. The speed command manual page could be more comprehensive though.