HW acceleration for Camellia cipher (x86_64/AES-NI/AVX2) Modern processors support hardware acceleration for various crypto functions such as AES directly, or general vector operations which can be used in crypto functions, such as SSE SSE2 SSSE3 AVX.

On my machine, I can see the difference in speed between AES in software and in hardware, which gives speeds up to 5 times faster:

openssl speed -evp aes-256-cbc
openssl speed      aes-256-cbc


(Note: I am using OpenSSL here only as an example, because it is easy to demonstrate.)

Also, the Linux kernel can be compiled with support for these functions as well. If so, all encryption in kernel space (for example IPsec, dm-crypt) can take advantage of these fast hardware instructions.



Again, the kernel compiled with AES-NI support is many times faster when uisng aes in software only.

I have noticed that there is also hardware support for the Camellia cipher and it looks as if Camellia could use the same instructions as AES, namely AES-NI and AVX.

However, I am unable to test/confirm this.

openssl speed      camellia-256-cbc
openssl speed -evp camellia-256-cbc


I see no difference in speed when tested with OpenSSL and I suspect the hardware acceleration is not being used for Camellia.

My cpu supports all above mentioned instructions: AES SSE SSE2 SSSE3 AVX.

Is it possible to speed up Camellia by using hardware instructions on supported cpu, same as with AES?
The obvious answer to your question is "yes". The kernel mode implementation pointed to by otus clearly shows that it can be done.

That it can be done doesn't mean it gets done however. Many Google searches for sourcecode don't show any OpenSSL code that implements this functionality. In general, OpenSSL doesn't rely on the crypto code of the kernel. So, that means the hardware acceleration is not available. In general you should not expect that hardware-crypto availability is automatically reflected in (higher level) API's.

To resolve this you could either implement an engine yourself or ask for a feature request at OpenSSL. Note that Camellia interest seems to be dwindling. Nobody picked up the - relatively new - feature request for Camellia in authenticated ciphers or ciphersuites so they got closed.

It seems that Camellia is seen as a "vanity algorithm" by many; let's not do AES because it is too American, but do something almost identical instead.