>>>> So if you directly use the AES API you used to have a little better >>>> performance, >>>> but now you don't get the AES-NI support and so are a factor slower when >>>> using it. >>>> >>>> Is this the normal and expected behaviour? >>> I hope this isn't true. If it is, it means applications like OpenSSH >>> that directly use the cipher APIs in OpenSSL will not get the benefit >>> of AES-NI. >> objdump -T /usr/bin/ssh | grep -i AES >> 00000000 DF *UND* 00000000 AES_encrypt >> 00000000 DF *UND* 00000000 EVP_aes_192_cbc >> 00000000 DF *UND* 00000000 EVP_aes_256_cbc >> 00000000 DF *UND* 00000000 AES_set_encrypt_key >> 00000000 DF *UND* 00000000 EVP_aes_128_cbc >> 000xxxxx g DF .text 000xxxxx Base evp_aes_128_ctr >> >> OpenSSH does use EVP and benefits from AES-NI. > > Shouldn't it be using EVP_EncryptUpdate() instead of > AES_encrypt()? And isn't AES_encrypt() now always the one that > doesn't support AES-NI? > > It seems to be mixing different APIs to me.
You don't see EVP_Encrypt*, because I grep-ed for AES. AES_encrypt and AES_set_encrypt_key are used by evp_aes_128_ctr, which is OpenSSH's *own* *CTR* implementation. OpenSSH could/should have looked up if there is CTR EVP in OpenSSL and fall back to own implementation if there is no one. As it is now, OpenSSH's CTR won't utilize AES-NI, but CBC does. If anybody chooses to pursue the CTR issue with OpenSSH (I unfortunately don't have time), there is another possibility in 1.0.1 worth mentioning: stitched cipher-hash implementations offering respectable +40%-70% performance improvement in specific cases. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
