Hardware Cryptography for BUBBA3 Kirkwood?

[jallee]

Hi!
This is something i like to see on the B3 if it’s supported by the hardware.
http://www.altechnative.net/2011/05/22/ ... -on-fedora
Regards // Jallee

[Algol]

For anyone wondering I repeated the steps in that article for the excito b3 about a year ago and got similar results:

w/o cryptodev

Code: Select all

openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 1549545 aes-128-cbc's in 2.98s
Doing aes-128-cbc for 3s on 64 size blocks: 454785 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 256 size blocks: 118991 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 30072 aes-128-cbc's in 2.99s
Doing aes-128-cbc for 3s on 8192 size blocks: 3772 aes-128-cbc's in 2.99s
OpenSSL 0.9.8o 01 Jun 2010
built on: Thu Feb 10 21:19:23 UTC 2011
options:bn(64,32) md2(int) rc4(ptr,int) des(idx,risc1,4,long) aes(partial) blowfish(idx) 
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -O2 -Wa,--noexecstack -g -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc       8319.70k     9734.53k    10153.90k    10298.91k    10334.52k

w/ cryptodev

Code: Select all

openssl speed -evp aes-128-cbc
...
Doing aes-128-cbc for 3s on 16 size blocks: 99593 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 64 size blocks: 90804 aes-128-cbc's in 0.09s
Doing aes-128-cbc for 3s on 256 size blocks: 67523 aes-128-cbc's in 0.09s
Doing aes-128-cbc for 3s on 1024 size blocks: 40755 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 8192 size blocks: 7586 aes-128-cbc's in 0.01s
OpenSSL 0.9.8n 24 Mar 2010
built on: Sat Aug  6 09:38:04 CEST 2011
options:bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) 
compiler: gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer -Wall
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      15934.88k    64571.73k   192065.42k   695552.00k  6214451.20k

So I guess the hardware is there...

[drahnr]

Could you post the output of

Code: Select all

openssl engine

as well as your openssl.cnf
and the cryptodev version via

Code: Select all

modinfo cryptodev

Thanks in advance! (Packages are in progress)

[kurt2000]

Hi,

when using aes-128 for ipsec vpn i got 40 mbit throughput with openssl.

Wkr.

[stasheck]

Guys, I've been trying to enable hardware acceleration to make SSH file transfers faster, but it seems that I'm doing something wrong, because openssl speed test doesn't show improvement.

I downloaded source using 'apt-get source openssl', which downloads OpenSSL 0.9.8o. Then I changed openssl.spec to include the line:

Code: Select all

%define CONFIG_FLAGS -DSSL_ALLOW_ADH --prefix=/usr --openssldir=%{openssldir} zlib enable-camellia enable-seed enable-tlsext enable-rfc3779 enable-cms enable-md2 no-idea no-mdc2 no-rc5 no-ec no-ecdh no-ecdsa -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64 shared threads ${sslarch} fips

After that: make, make install and openssl landed in /usr/local/bin/openssl. Sadly, the performance is the same.

I'm pretty sure I forgot about something or are doing something wrong, but while I'm decent with configuring stuff, building stuff is something I do as rarely as possible. Any help will be appreciated.


EDIT: Right, I totally forgot - before building OpenSSL, I of course downloaded cryptodev from http://download.gna.org/cryptodev-linux/ and run make&make install.

[johannes]

I have a faint memory of that the hw acceleration did not support the default encryption scheme used by openssl, I think you need to define a custom encryption type.. Could that be it?

[Gordon]

Thinking of adding this to the gentoo overlay I've been experimenting with this today. The conclusion has to be that it doesn't really make things a lot quicker. In fact when I do `openssl speed -elapsed -evp aes-128-cbc` I get less than a third of the amount of 16 byte aes-128-cbc blocks through with cryptodev enabled. I get a marginal improvement on 8192 byte blocks.

So I tried whether I could see some difference running rsync over ssh and my first results showed no difference at all. As it turns out you have to specify the right cipher to use for the hardware crypto to be able to take over and the next surprise was that current releases of openssl have this cipher disabled by default because it is considered unsafe. I ran rsync on a folder containing some 2,000 digital photo's, summing up to about 6Gb. Without cryptodev I got:

Code: Select all

real	15m1.057s
user	3m7.250s
sys	0m31.503s

With cryptodev enabled I got:

Code: Select all

real	13m40.579s
user	1m6.401s
sys	0m30.590s

So while 'user' appears to say that offloading means a great deal for the CPU, there's no real gain in overall time and you are bound to use an encryption protocol that doesn't appear to be very useful in real world. I also found that letting apache use cryptodev prohibits me from using personal certificates for identifying users, so for me that is a no go.

I guess cryptodev might be useful if you want to encrypt your disk. If anyone is thinking of other uses my advise is to leave it alone.

[Stryker]

short summary:
The hardware-crypto-engine can only accelerate outdated ciphers which are considered unsafe by today's standards?

[Gordon]

As a fact it does not even accelerate as much as some people hinted. It's not anywhere near times 10, but only about 9% time decrease, which may even be caused by other processes using less CPU during my benchmark.

What it does do is off-load, from which you may benefit if you have other processes requiring heavy CPU at the same time. The supported cipher is aes-cbc and while your ssh client will not complain about using it, the current ssh daemon has this cipher disabled by default (but you can still enable it).