Hardware Cryptography cryptodev/openssl On arm5/Debian Wheezy/GoFlex Net

This is self-documentary as opposed to a precise how-to, if in doubt do your own research and due diligence, I had to !

Marvell kirkwood arm5 processor in my GoFlex Net has a HARDWARE cryptography co-processor. And basically from what I can understand it lies idle whilst encryption/decryption is done in the CPU. This makes the box slower and perform worse.

A solution - cryptodev-linux PLUS openssl compiled to use the cryptodev library and therefore the build in hardware co-processor.

Easy, no it wasn't, I've been at this for nearly a week.


Before you begin


cryptodev is a project maintained by Nikos Mavrogiannopoulos - http://cryptodev-linux.org

It would be nice to see cryptodev-linux as a mainstream package in Debian, but this is above and beyond my capbilities. So we'll need to compile and set it up ourselves.

openssl is the defacto decryption/encryption library used just about everywhere on linux for just about everything. Without recompiling it, it won't be default use the hardware encryption co-processor.

SO, in order to get hardware cryptography up and running, we first need to install cryptodev, and then a patched version of openssl. There maybe other software which takes advantage of cryptodev engine, I'm not a linux expert so I don't know :D

NB. This was a very long process, I'm writing a lot memory, may have missed a step or two. OFTEN/usually Debian tells you of missing packages etc, so install them if what you're doing depends on them ... etc ...

Turning GoFlex Net Into A Ferrari :)

cryptodev

First off I tried to compile 1.6 of cryptodev, it didn't work. So I got it from their git repositoty instead. Along these lines :

# a couple of benchmarks, records the results and do these after you've installed

openssl speed -evp aes-128-cbc
openssl speed -evp sha1

# may be some others here like build-essential and make, I forget exactly which !
apt-get install git

cd /home
mkdir cryptodev
cd cryptodev
git clone https://github.com/cryptodev-linux/cryptodev-linux
cd cryptodev-linux
# refer to file INSTALL
make

make install

# If alls well then run this to check alls well

make check

That should be cryptodev installed ( or mostly installed ) ... adding modules so kernel knows about them isn't my strong suit, so I think this is how it's done :

echo "cryptodev" >> /etc/modules

Arch linux seems to think this is needed - http://archlinuxarm.org/forum/viewtopic.php?t=2452

# make cryptodev load at boot -> edit /etc/rc.conf
MODULES=(cryptodev)

# and ....
echo 'KERNEL=="crypto", MODE="0666"' > /etc/udev/rules.d/99-cryptodev.rules

# and ....
echo "cryptodev" > /etc/modules-load.d/cryptodev.conf

If anyone can tell me which is/isn't correct or both, I'll edit later :D

You can list the cryptodev module with either :

cat /proc/modules
or
lsmod

# AND you should have this :
ls /dev/crypto

Also my dmesg has a message to tell me cryptodev has been loaded -

dmesg | grep cryptodev
[   34.832269] cryptodev: driver 1.6 loaded.

My cryptodev kernel module lives here :

ls -l /lib/modules/3.16.0-kirkwood-tld-3/extra
total 48
-rw-r--r-- 1 root root 46752 Oct 18 09:06 cryptodev.ko

So hopefully you should now have cryptodev installed ... phew !

openssl

Now this was a real BITCH to install. Partly I'm not a C++/Make/Linux expert and partly, well looking at 15 different versions of a piece of code etc etc etc ... anyway I persevered and eventually saw this :

openssl engine cryptodev
(cryptodev) cryptodev engine

The problem seems to be openssl aren't maintaining the crytodev aspect of openssl properly and haven't included Nikos's patches in their code. Add to this that Nikos's patches wouldn't patch the openssl code, and it get's confusing. So I've just attached the eng_cryptodev.c you'll need, already patched. It's the best of various versions, and compiles and works on my machine. It's based on the eng_cryptodev.c from cryptodev-linux release 1.6 from the "extras" folder.

So, down to the easy stuff (ref - https://wiki.debian.org/SourcePackage)

Get my patched eng_cryptodev.c at the ready :D

cd /home
mkdir openssl
cd openssl

# this will get openssl-1.0.1e
# you need to have the deb-src lines in your /etc/apt/sources.list
apt-get source openssl

cd openssl-1.0.1e

# YOU NEED TO NOW PUT MY eng_cryptodev in the ./crypto/engine/ folder
# YOU WILL ALSO NEED TO EDIT ./debian/rules , and edit the CONFARGS variable like so :

vi ./debian/rules

CONFARGS  = --prefix=/usr --openssldir=/usr/lib/ssl --libdir=lib/$(DEB_HOST_MULTIARCH) no-idea no-mdc2 no-rc5 shared threads zlib  enable-tlsext no-ssl2

# I'm not sure if editting the CONFARGS is 100% neccessary, but I couldn't find out what "shared threads" means
# and ArchLinux suggest that it's needed. So I figured it is needed.

# Build/Compile/Package
DEB_CFLAGS_APPEND='-DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64' dpkg-buildpackage -b -us
# if all goes well the parent directory will contain deb packages to install

cd ..

# Not sure if all these steps are neccessary, you might just need openssl, but be on safe side

dpkg -i libssl1.0.0_1.0.1e-2+deb7u13_armel.deb      
dpkg -i libssl-doc_1.0.1e-2+deb7u13_all.deb
dpkg -i libssl1.0.0-dbg_1.0.1e-2+deb7u13_armel.deb
dpkg -i libssl-dev_1.0.1e-2+deb7u13_armel.deb
dpkg -i openssl_1.0.1e-2+deb7u13_armel.deb

# With any luck, and some prayers, try this :
openssl engine cryptodev

#And you should see this :

(cryptodev) cryptodev engine

# If all's well then you can run the tests you did at the begining to verify cryptodev actually using hardware

openssl speed -evp aes-128-cbc
openssl speed -evp sha1

Job done if I remember correctly, hopefully have missed too many steps !

Questions

I've said a few times, I'm not a Linux/C++/Hardware expert, just persistent mostly. I wasn't sure whether to include the "shared threads" argument - does anyone know what this does and whether it's needed/helpful ?

It doesn't appear to affect the overall operation ! ... and it seems there isn't a libcryptodev, or at least I could find one or a way to make one :D

ALSO the -DHASH_MAX_LEN=64 flag has been included from what I understand because the hardware cryptography engine works better on smaller hashes and gets slower on larger hashes. HOWEVER my question is this, wouldn't it be better overall on the machine to be offloading ALL of the cryptography, so the rest of the CPU is available for other work ?

Complaints to /dev/null ... Questions and comments welcome, provided you can string a polite and relevant sentence together :D

Cheers

DC

PS I'm running a bodhi 3.15 tld 3 kernel, Debian Wheezy, GoFlex Net

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com



Edited 6 time(s). Last edit at 10/19/2014 03:38PM by DonCharisma.

Hi Don,
I also have a passing interest in cryptography and looked at the hardware crypto engine in the ARM processors some time back. I think the prevailing notion a few years ago was that unless you had a dedicated use for it, the crypto engine was not efficient because you had to queue up for its use if you had multiple users.

I interpret your data a bit differently than you do, although I may be wrong since I am no expert on openssl. However, what I believe the "speed" invocation does is iterate the selected cipher for 3 real-time seconds and then print the number of iterations which have occurred and the actual CPU time allotted in that three second interval. So I interpret

Doing aes-128-cbc for 3s on 256 size blocks: 110394 aes-128-cbc's in 1.67s

to mean that openssl iterated AES-128-cbc 110394 time while using 1.67 actual seconds of CPU. (What else is going on on your machine which would be competing with openssl for that CPU? When I run this on my Pogo E2 I get

Doing aes-128-cbc for 3s on 256 size blocks: 196065 aes-128-cbc's in 2.95s

or nearly 100% CPU utilization as compared to your 55% utilization.)

The reason your hardware numbers show such low utilization is that the computation time in the hardware engine is being charged to the kernel, and the user-level process is not using the CPU at this point but simply in a wait state awaiting the results. Contrary to your assessment, it looks to me like the hardware numbers are pretty low when compared to the software numbers, although if they are adequate for what you need, it could be argued that the CPU could be being used for something else while the hardware engine is grinding away in parallel.

The real numbers to compare are those given at the end -- the "1000s of bytes per second processed". To use the above benchmark (256 byte chunks), I see about 17MB/sec throughput on my E02 in software. I calculate about the same for your system in software (110394*256/1.67 = 16.9MB/sec). For the hardware engine, I see much less throughput, although without further investigation it is difficult to say where the bottleneck is, and I doubt it is in the engine itself.

YMMV

@restamp, LOL, so fair to say you won't be enabling your hardware crypto anytime soon ?

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

To answer your (probably rehtorical) question, well, no, I gave up early on trying to integrate the the ARM processor's hardware crypto engine into a general package like openssl. The crypto engine only implements one or two cipher/modes which are considered "strong" by today's standards, so it would not be usable for a large portion of what openssl supports anyway.

There are several instances where I think the crypto engine might be viable. One would be if someone were to use it to implement an encrypting file system (or generic disk) driver (or LVM?). I believe if the engine was strictly accessed from within the kernel, and the engine were dedicated strictly to this one use, you could likely get disk encryption thrown in for little or no processor overhead. Implementing such a driver (or module) would take more effort than I'd care to expend, though.

Another scenario would be if someone were writing their own program on a machine where it could be dedicated for that purpose. If I recall, the normal access to the crypto engine is via a /dev entry. I believe this interface has proven itself rather slow, but it might still be useful, depending on how much encryption one required.

A final possibility would be to use the engine to stir a random (or pseudo-random) number generator so as to leverage the amount of randomness available on the system.

Anyway, those are my thoughts.

FWIW,

I'm still not convinced that cryptodev on our plugs is stable yet. There have been reports of problems (memory corruption), some were fixed with certain patches or backports. But be careful to trust it with your important data, it should be considered experimental.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 10/19/2014 04:03PM by bodhi.

@restamp, I count 11 modes in the current version, probably you didn't look at the attached file ... a conflictory argument is sometimes helpful, you seem to know something about this, so thanks for sharing your thoughts ... however if your experiences stem from several years ago, then how could you be sure that the situation hasn't changed without further investigation or testing ?

@bodhi, it'd be nice to be convinced of the stability :D ... we are on a hardware hacking forum, talking about software installed on devices that's outside the manufacturer's instructions (in most cases) ... so I think most of what is done here is probably experimental, or at least that's been my experience ... as for risky, that's a different matter, I'd never encourage someone to risk their critical data, it's all too easy to lose ... so generally I treat pretty much everything I'm doing with my GFN as risky, goes with the territory ... the alternative is a rather expensive door stop, there was nothing I liked about the GFN in it's pogo form, and wouldn't have bought it if I didn't think it had potential :D

Do you know which of the commands for starting cryptodev at boot are correct, I wasn't sure, ArchLinux provided 3 ?

@all, I started this project looking for ways to speed up encryption and the general process of my Crashplan server. Ironically, I found in the end a much simpler configuration solution, which gives me full bandwidth uploads without the massive CPU overhead. For me the experimentation and learning was the useful bit, not the end result.

Also without experimentation and people testing and improving cryptodev, then I think probably it'll gradually be ignored (more than it already is). Seems a shame to me to be ignoring part of the CPU, on devices which aren't all that powerful in the first place ... but I don't know all the factors, so possible it's unworkable or better to use the main CPU ... Marvell and Texas instruments seem to think otherwise ... anyway, I've said already I'm not an expert, so all feedback is helpful, paints a broader picture :D

The main point was to try and make use of a part of the CPU which is currently dormant in most cases. If people are using their devices to store and process critical data, then I would STRONGLY ADVISE NOT USING a hacked arm device, and migrate their data to something a bit more stable, like the original software/OS included with their device or perhaps a RAID6 array in a datacenter mirrored to other remote locations, but who's got the money for that ...

Cheers

DC

@restamp ... PS, just got a chance to run the aes-128-cbc test again on box without load :

root@GoFlexNet1:~# openssl speed -evp aes-128-cbc -engine cryptodev
engine "cryptodev" set.
Doing aes-128-cbc for 3s on 16 size blocks: 60298 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 64 size blocks: 58852 aes-128-cbc's in 0.08s
Doing aes-128-cbc for 3s on 256 size blocks: 49341 aes-128-cbc's in 0.04s
Doing aes-128-cbc for 3s on 1024 size blocks: 32524 aes-128-cbc's in 0.05s
Doing aes-128-cbc for 3s on 8192 size blocks: 7124 aes-128-cbc's in 0.01s
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Oct 19 15:13:41 ICT 2014
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr)

compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DL
FCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buff
er-size=4 -Wformat -Werror=format-security -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGE
STS -DHASH_MAX_LEN=64 -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -
DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 19295.36k 47081.60k 315782.40k 666091.52k 5835980.80k

If I read this correctly, from you what you said above, I'm getting 315MB/sec on the 256 byte test, as opposed to 16MB/s ? On the 8192 bytes, seems to read 5.8GB/s as opposed to 17MB/s on my prior test given below ?

Prior test, which I have no idea what was on the CPU at the time, seems to concur with your no-cryptodev numbers :

type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
aes-128-cbc 11844.12k 15639.30k 16922.67k 17209.87k 17422.63k

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

@all, I just received an email back from Nikos. The package maintainer for cryptodev-linux is now Phil Sutter, not Nikos ...
In regard to problems and issues people were seeing with it, Nikos says this :

Quote
Nikos
It also requires the following patches to
openssl:
http://rt.openssl.org/Ticket/Display.html?id=2770&user=guest&pass=guest

Otherwise it may cause some random corruption on your SSL/TLS
connections. If these patches works for you, I'd suggest to bug the
openssl folks to include them.

These are the very same patches I've applied in the modified "end_cryptodev.c" attached to the post.

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

deleted



Edited 2 time(s). Last edit at 10/20/2014 03:35PM by Almaz.

I think I already know this answer to this, but what does this give :

ls /lib/modules/3.12.0-kirkwood-tld-3/build

No such file or directory ?

Somebody correct me if I'm wrong, but I think this directory and underlying files were created when I installed bodhi's kernel with his .deb package ... as described here : http://forum.doozan.com/read.php?2,12096 , specifically :

"dpkg -i linux-image-3.16.0-kirkwood-tld-3_3_armel.deb" on my system ...

Mine says this :

# ls -l /lib/modules/3.16.0-kirkwood-tld-3/build
lrwxrwxrwx 1 root root 44 Sep 27 17:08 /lib/modules/3.16.0-kirkwood-tld-3/build
-> /usr/src/linux-headers-3.16.0-kirkwood-tld-3

Which I believe is a symbolic link to the headers ... So a) do you have such a link to your headers ? and b) do you have your headers in /usr/src ?

If a) NO/ b) NO, then would ask how the kernel was installed ?

The solution is probably going to be make a directory called build and put a symbolic link to your headers, but let me know the info requested before you do that :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

PS my previous kernel has a slightly different layout, the "build" directory is called "kernel" :

/lib/modules/3.3.2-kirkwood-dg/kernel

Let me know what you dig up :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

Thanks for replying. I guess you posted the answer before I created the symbolic link and edited my original post. Now I'm past that problem and facing another problem :) It looks like it wants all .h files in /usr/src/linux-headers-3.12.0-kirkwood-tld-3/arch/arm/include/mach directory. I don't know why but I have to create a symbolic link for each missing file such as timex.h, irq.h.



Edited 2 time(s). Last edit at 10/20/2014 02:11PM by Almaz.

Are you using the git version or the 1.6 of crytodev-linux ?

And thanks for sharing where you got stuck, I was working on this for nearly a week and don't remember all the steps !

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

I'm following your directions from the git

Awesome, the 1.6 version didn't work well for me, probably "fixable", but git version went straight through :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

I guess I'm doing something wrong. I've had that problem before with kernel source files. I downloaded the files from kernel.org and extracted them to /usr/src/linux-headers-3.12.0-kirkwood-tld-3 How did you install headers? What's the proper way to install them. I'm stuck with an error which can't find irq.h I already put the file in mach folder similar to the problem I had with timex.h.

make[1]: Entering directory `/usr/src/linux-headers-3.12.0-kirkwood-tld-3'
  CC [M]  /tmp/1/cryptodev-linux/ioctl.o
In file included from /usr/src/linux-headers-3.12.0-kirkwood-tld-3/arch/arm/include/asm/hardirq.h:6:0,
                 from include/linux/preempt_mask.h:5,
                 from include/linux/hardirq.h:4,
                 from include/linux/highmem.h:9,
                 from /tmp/1/cryptodev-linux/ioctl.c:39:
/usr/src/linux-headers-3.12.0-kirkwood-tld-3/arch/arm/include/asm/irq.h:7:23: fatal error: mach/irqs.h: No such file or directory
compilation terminated.
make[2]: *** [/tmp/1/cryptodev-linux/ioctl.o] Error 1
make[1]: *** [_module_/tmp/1/cryptodev-linux] Error 2
make[1]: Leaving directory `/usr/src/linux-headers-3.12.0-kirkwood-tld-3'
make: *** [build] Error 2
root@debian:/tmp/1/cryptodev-linux#

EDIT: I guess I missed it. All I had to do rename irq.h to irqs.h for some reason I didn't see "s" at the end.



Edited 1 time(s). Last edit at 10/20/2014 02:44PM by Almaz.

:D alls well dude, I got stuck on this error for several hours until I figured out the typo :

# openssl engine crytodev
3070035152:error:25066067:DSO support routines:DLFCN_LOAD:could not load the sha
red library:dso_dlfcn.c:185:filename(/usr/lib/arm-linux-gnueabi/openssl-1.0.0/en
gines/libcrytodev.so): /usr/lib/arm-linux-gnueabi/openssl-1.0.0/engines/libcryto
dev.so: cannot open shared object file: No such file or directory
3070035152:error:25070067:DSO support routines:DSO_load:could not load the share
d library:dso_lib.c:244:
3070035152:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:4
50:
3070035152:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c
:417:id=crytodev

DOH !

... I think the headers are installed via the .deb file that bodhi puts out ... presumably the same for mainline headers from Debian in their .deb packages ... my davygravy headers are layed out slightly different to bodhi's ones, so possible Debian may have changed the directory structure, or it my be "more proper" to put them in /usr/src and symlink it.

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

n/a



Edited 2 time(s). Last edit at 10/22/2014 04:02AM by Almaz.

Awesome :) ... drop me a PM, I'm not on hangout !

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

>
> EDIT: problem solved by installing Bodhi headers.

This.

If you plan to compile any module, the 1st step is to install the kernel headers.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------
> >
> > EDIT: problem solved by installing Bodhi
> headers.
>
> This.
>
> If you plan to compile any module, the 1st step is
> to install the kernel headers.

Thanks Bodhi, I did have headers from linux.org and that's why I was having troubles. Once I installed your headers, problem got solved.

n/a



Edited 2 time(s). Last edit at 10/22/2014 04:04AM by Almaz.

Does

grep -r "stack-protector" *

yield any clue to where it's originating from ?

My base level Makefile has this :

Makefile:CFLAG= -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_
DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-bu
ffer-size=4 -Wformat -Werror=format-security -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DI
GESTS -DHASH_MAX_LEN=64 -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall
 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_AS
M -DAES_ASM -DGHASH_ASM

And this is my openssl version -a :

# openssl version -a
OpenSSL 1.0.1e 11 Feb 2013
built on: Sun Oct 19 15:13:41 ICT 2014
platform: debian-armel
options:  bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) blowfish(ptr)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DL
FCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buff
er-size=4 -Wformat -Werror=format-security -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGE
STS -DHASH_MAX_LEN=64 -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -
DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM
-DAES_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Also when you did the apt-get source command did you see a bunch of patches being applied ? ....

My (1st) suggestion is to edit the base level Makefile ... (2nd) if that doesn't work you could try add -fstack-protector the DEB_CFLAGS_APPEND ...

This might be of interest also : http://blog.maestropublishing.com/2014/08/21/installing-cython-x86_64-linux-gnu-gcc-error-unrecognized-command-line-option-fstack-protector-strong/

Is there any reason your system might think you have a gcc version >= 4.9 (like a previous hack perhaps) ? Mines :

apt-cache show gcc
#bla bla bla
Version: 4:4.6.3-8
#bla bla bla

As for karma, some say it's a bitch :) ... do some good deeds tomorrow you'll feel better !

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

n/a



Edited 1 time(s). Last edit at 10/22/2014 04:05AM by Almaz.

@Almaz ... OK, let me know how you get on ... another way to get the necessary flags in (I think) which isn't updated by dpkg-buildpackage is in the debian/rules file ...

I put together a test script, call it test_cryptodev.sh if you like :

#!/bin/bash

openssl speed -evp md4 2>&1 | tail -2
openssl speed -evp md5 -engine cryptodev 2>&1 | tail -1
openssl speed -evp sha1 -engine cryptodev 2>&1 | tail -1
openssl speed -evp sha1 -engine cryptodev 2>&1 | tail -1
openssl speed -evp sha256 -engine cryptodev 2>&1 | tail -1
openssl speed -evp sha512 -engine cryptodev 2>&1 | tail -1
openssl speed -evp seed-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp rc2-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp bf-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp des-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp des-ede3 -engine cryptodev 2>&1 | tail -1
openssl speed -evp aes-128-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp aes-192-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp aes-256-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp camellia-128-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp camellia-192-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp camellia-256-cbc -engine cryptodev 2>&1 | tail -1
openssl speed -evp rc4 -engine cryptodev 2>&1 | tail -1
openssl speed -evp cast -engine cryptodev 2>&1 | tail -1

Don't forget :

chmod 0755 test_cryptodev.sh

# and useful too :

./test_cryptodev.sh | tee test_cryptodev.log

I'll check the PM and reply there :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

n/a



Edited 1 time(s). Last edit at 10/22/2014 04:03AM by Almaz.

That's the error openssl throws up when you specify an engine it doesn't recognise ...

try this :

openssl engine Almaz

What I think is happening there is that openssl may have the ability to dynamically plug in a new engine, provided there's a compatible libAlmaz.so file available ... .so is a shared object like a dll file on Windows ... don't bother looking for libcryptodev.so, it doesn't exist, "find -name 'libcryptodev.so'" from / won't find it ...

Probably this is caused by the openssl you're calling with the command not being the same as the one you just installed ... ie it's the same version that was installed before.

Also presumably the gcc switch was caused by the Wheezy/Jessie issue ... Did you manage to rollback the Jessie packages or are you still half way between the two ?

My approach was to do an apt-get remove openssl (when I had a similar error message), build the new openssl using the dpkg-buildpackage method and then install the .deb files ... I normally use apt-get install for "ordinary" debian packages, but we're installing patched code, so can't be done like that ... the dpkg-buildpackage allows building a modified package (us = unsigned source), which generates the .deb files, which they in turn install everything in the same place as if you'd done an apt-get install ... I was also tempted by the make && make install direction, but I don't think it installs in the same place Debian would ... hence the debian folder and the debian/rules file ...

Without the .deb packages, it's gonna be either a case of finding out where files have been misplaced and adding symlinks or copying the files around to the correct locations ... time consuming probably !

What I suggest is rolling back what you can, if anything, then fixing the original error with the compiler first. Once you're getting a happy dpkg-buildpackage -b -us, ctrl + c out of it ... apt-get remove openssl ... restart the dpkg-buildpackage process, and install the deb packages in the order I did.

Hope it helps :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com

DonCharisma Wrote:
-------------------------------------------------------
> @restamp, I count 11 modes in the current version,
> probably you didn't look at the attached file ...
> a conflictory argument is sometimes helpful, you
> seem to know something about this, so thanks for
> sharing your thoughts ... however if your
> experiences stem from several years ago, then how
> could you be sure that the situation hasn't
> changed without further investigation or testing

What I meant was that only several of the modes that the Crypto Engine and Security Accelerator handles are considered viable today. For instance, AES and 3DES are still considered usable ciphers, but DES is considered too weak today to be of any practical value. And other ciphers that are not certified but find wide use in greater Internet, like blowfish, are not included at all. Furthermore, there is a similar gamut of viability in the methods of employing the good ciphers; for instance CBC mode is generally considered good, some of the others the CESA implements, such as ECB, not as good by today's standards.

Don't get me wrong: The CESA is a neat little tool in the ARM's arsenal, but a lot of it is becoming increasingly dated in today's world.

I had to recompile again openssl, something went wrong during the last compile. It took almost 2.5 hours to compile it on PogoPlug E02 but now it works like a charm. Here is the output

With Hardware Encryption
openssl 1.0.1e
Kernel linux-3.16.0-kirkwood-tld-2

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4               1888.78k     7023.04k    24279.93k    60463.70k   107171.84k
md5                702.17k     3094.53k    12916.87k    54358.65k   513966.08k
sha1               760.67k     3536.64k    12044.80k    47183.64k   416823.85k
sha1               791.39k     2820.64k    10835.59k    53232.00k   386048.00k
sha256             645.60k     3009.89k    12674.69k    52314.58k   350208.00k
sha512             553.42k     2697.08k    12141.99k    39128.18k   383931.73k
seed-cbc          9169.27k    11454.44k    12279.62k    12528.20k    12677.12k
rc2-cbc           8774.90k     9905.71k    10241.41k    10584.73k    10302.06k
bf-cbc           17436.57k    37553.45k   156690.29k   269858.13k  1339118.93k
des-cbc          17393.48k    40492.80k   161518.08k   781312.00k         infk
des-ede3          3031.62k     3153.57k     3174.14k     3179.95k     3177.17k
aes-128-cbc      23825.20k    33785.60k   135773.87k   464047.54k  2881536.00k
aes-192-cbc      47808.00k    46655.20k   205405.87k   651161.60k  2813542.40k
aes-256-cbc      11898.60k    92960.00k   112291.84k   397964.80k  1822446.93k
camellia-128-cbc    10215.05k    12979.09k    13904.53k    14197.62k    14212.43k
camellia-192-cbc     8537.04k    10361.64k    10956.28k    11122.38k    11153.30k
camellia-256-cbc     8554.34k    10342.14k    10978.41k    11138.69k    11139.46k
rc4              32509.28k    46819.94k    52510.03k    54268.54k    54622.59k
cast5-cbc        13678.16k    16339.92k    17249.82k    17436.81k    17665.38k

Without hardware encryption
openssl 1.0.1g-3
Kernel 3.12.0-kirkwood-tld-3

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md4               5202.66k    18155.21k    51247.27k    93648.28k   123130.78k
md5               4807.57k    16208.84k    42361.82k    71206.62k    87673.84k
sha1              3696.67k    11038.03k    24585.68k    35641.10k    41082.31k
sha1              3689.18k    11037.00k    24628.94k    35554.05k    40979.50k
sha256            3081.80k     8605.30k    18079.76k    24776.96k    27724.19k
sha512            1209.35k     4836.46k     7730.68k    10948.98k    12555.49k
seed-cbc          9796.35k    12241.75k    13022.24k    13295.69k    13345.67k
rc2-cbc           8990.13k    10172.57k    10531.32k    10630.79k    10624.69k
bf-cbc           14460.52k    17821.00k    18956.49k    19345.53k    19284.64k
des-cbc           7661.51k     8764.82k     9145.64k     9217.77k     9248.04k
des-ede3          3031.85k     3134.21k     3172.75k     3163.95k     3174.05k
aes-128-cbc      12081.12k    15684.09k    16972.80k    17311.48k    17460.42k
aes-192-cbc      10924.88k    13629.04k    14663.40k    14859.11k    15044.76k
aes-256-cbc       9858.65k    12076.43k    12884.31k    13040.69k    13121.18k
camellia-128-cbc    10465.21k    13259.40k    14326.60k    14583.93k    14670.62k
camellia-192-cbc     8715.39k    10605.02k    11240.76k    11434.44k    11421.43k
camellia-256-cbc     8700.24k    10597.89k    11290.39k    11401.23k    11493.96k
rc4              42813.40k    59951.86k    66336.42k    68387.96k    68933.02k
cast5-cbc        14482.54k    18073.60k    19210.54k    19591.14k    19610.81k

Conclusion: Looks like using hardware encryption helps a lot to break 5 digit speed compare to CPU encryption. It's only good for certain encryptions but for others hardware encryption makes it slower. The performance seems to be reduced probably due to FLAGS -DUSE_CRYPTODEV_DIGESTS. The next step recompile without hash support and check the performance. Would be probably the best way to configure which can be processed by cpu or hardware but I don't know how or even if possible. Probably with the right encryption such as AES OpenVPN might work better. Somebody must do some benchmarks with OpenVPN.

DUSE_CRYPTODEV_DIGESTS: include hash support via cryptodev (disabled by default as it is usually too slow to be useful



Edited 11 time(s). Last edit at 10/22/2014 03:38AM by Almaz.

Good work and nice results, persistence pays off ... mine are fairly similar ... the slower speeds with cryptodev on smaller byte sizes I think are due to an overhead in the process' setup ... where the numbers were almost identical I assumed that the the hardware wasn't being used ...

AES is extremely fast, I believe that's used by Seagate for disk encryption, from reading their blurb ...

I'll dig up results and post later :D

Cheers

DC

Don Charisma ... because anything is possible with Charisma

My blog - http://DonCharisma.org
Our commercial site - http://DonCharisma.com