>>> 1.0.1: >>> $ openssl speed aes-128-cbc: >>> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 >>> bytes >>> aes-128 cbc 110450.10k 120831.36k 122216.11k 123465.05k >>> 123909.46k >>> >>> $ openssl speed -evp aes-128-cbc: >>> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 >>> bytes >>> aes-128-cbc 669703.39k 709092.05k 721489.25k 714057.39k >>> 724320.26k >>> >>> 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. >> ??? AES-NI was *never* available through "AES API", always through EVP, >> either through ["3rd party"] engine or starting with 1.0.1 integrated >> directly at EVP level. Well, it is possible to slightly modify AES-NI >> assembler and compile it as drop-in *replacement* for vanilla AES >> module, but it was never "offered" as supported option nor "advertised". >> Somebody might have done it, but in such case it's something to settle >> between you and that vendor. It should be noted that such drop-in won't >> provide adequate performance for parallelizable modes other than CBC >> decrypt. >> >> Or did I misunderstand the question? > > I guess my question is basicly why the selection between the > different assembler implementations happens at the EVP level > and not some lower level. I was expecting the lower level > to also use AES NI when it was available.
One hint is in "drop-in won't provide adequate performance for parallelizeable modes". If we wanted to *fully* utilize AES-NI potential at lower level, we would have to implement [and support] a number of mode-specific low-level subroutines for all processors. It's too much work. EVP provides the kind of flexibility that allows to optimize the burden. Another essential point is that AES-NI key schedule is incompatible with one returned by plain AES. Therefore it's more than appropriate to [so to say] glue together key schedule and matching mode subroutines. EVP is the right spot for this. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org