5
$\begingroup$

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.

screenshot showing available algos

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?

$\endgroup$
2
  • 2
    $\begingroup$ What sort of an answer are you looking for? Yes, Camellia can be accelerated using AES-NI+AVX. But how to make use of it with OpenSSL is off topic here. $\endgroup$
    – otus
    Feb 6, 2016 at 12:41
  • $\begingroup$ @otus - I am looking for the simplest way to test, on my aes sse sse2 ssse3 avx capable cpu, the performance for camellia in SW vs. HW. Also, I would like to make sure, that if applications (such as OpenSSL) use camellia, they take advantage of hw acceleration. But I am using OpenSSL here only as an example, because it is easy to demonstrate. $\endgroup$ Feb 6, 2016 at 13:58

1 Answer 1

7
$\begingroup$

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.

$\endgroup$
6
  • 1
    $\begingroup$ After looking at the Japanese information on it I tend to agree with this opinion. $\endgroup$
    – Maarten Bodewes
    Feb 6, 2016 at 14:42
  • 3
    $\begingroup$ Apparently OpenSSL 1.1 will be able to use Crypto API, so any kernel implementations would be automatically available. $\endgroup$
    – otus
    Feb 6, 2016 at 15:06
  • $\begingroup$ @otus That link just displays a login page unfortunately (without explaining what login is required). Interesting information though. It could still require some configuration - kinda hard to establish without more info. $\endgroup$
    – Maarten Bodewes
    Feb 6, 2016 at 15:11
  • $\begingroup$ Hmm, I get no login prompt unless I open in incognito, and I have no account or anything. Weird. Anyway, it only says that the feature is "in progress", so how it will/may work is anyone's guess. $\endgroup$
    – otus
    Feb 6, 2016 at 15:15
  • $\begingroup$ @otus An aside: same here… I’ld check those cookies because some cookie on your system must have allowed access to their ticket system – which requires login to access individual tickets. If you didn’t login there and no one else did, chances are you stumbled upon a glitch/bug in their authorisation sessions (potential problem: auth systems should not rely on potentially shared IPs)… or you’re using a network that caches a bit too much on it’s caching server (which is rather unlikely, as I don’t know many caching servers that would buffer session cookies). $\endgroup$
    – e-sushi
    Feb 6, 2016 at 22:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.