Hardware Cryptography for BUBBA3 Kirkwood?

Good ideas? Share with us!
Post Reply
jallee
Posts: 46
Joined: 12 Jun 2009, 13:15

Hardware Cryptography for BUBBA3 Kirkwood?

Post by jallee » 11 Mar 2012, 13:24

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

Algol
Posts: 1
Joined: 02 Aug 2012, 08:43

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by Algol » 02 Aug 2012, 08:59

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
Posts: 1
Joined: 09 Oct 2012, 09:37

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by drahnr » 09 Oct 2012, 09:40

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
Posts: 40
Joined: 16 Sep 2010, 14:15

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by kurt2000 » 21 Oct 2013, 14:44

Hi,

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

Wkr.

stasheck
Posts: 107
Joined: 15 Jan 2014, 13:13

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by stasheck » 19 Dec 2014, 05:08

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
Posts: 1470
Joined: 31 Dec 2006, 07:12
Location: Sweden
Contact:

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by johannes » 19 Dec 2014, 05:15

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?
/Johannes (Excito co-founder a long time ago, but now I'm just Johannes)

Gordon
Posts: 1363
Joined: 10 Aug 2011, 03:18

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by Gordon » 13 Feb 2015, 12:26

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
Posts: 56
Joined: 17 Oct 2013, 11:03

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by Stryker » 13 Feb 2015, 17:45

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

Gordon
Posts: 1363
Joined: 10 Aug 2011, 03:18

Re: Hardware Cryptography for BUBBA3 Kirkwood?

Post by Gordon » 14 Feb 2015, 05:57

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).

Post Reply