OpenSSL Performance with a VIA Eden (padlock)

Encryption of gigabit lines should not be a problem with recent CPUs. But how about low-cost embedded devices that do the encryption in silicon on the chip? To find out I bought an Artigo A1200 embedded system and installed Linux. As a first test I wanted to check the encryption speed with OpenSSL. In this article I describe the installation and the results. In the next blog entry I will write about the systems' performance in a IPsec setup.

The Machine

The machine comes in a nice black box that looks kind of cool. A big plus is the fanless setup. So no noise will disturb you playing with the system. After I installed the RAM and a CF disk I could turn it on and install the latest Debian (7.1) in the 64 bit flavour. The installation went smooth and after the reboot I took a deeper look into /proc/cpuinfo:

Linux detected two cores VIA Eden X2 U4200 @ 1.0+ GHz. The command

# lsmod | grep padlock
padlock_sha            13367  2
padlock_aes            13024  2
aes_generic            33026  2 padlock_aes,aes_x86_64

showed that the 3.2.0 kernel already discovered the padlock hardware encryption engine and loaded the modules to use it. Bringing the machine up and running was really easy.

OpenSSL out of the Box

In the next step I wanted to see if OpenSSL also could use the padlock engine for its crypto operations. But the command

#  openssl engine padlock
139866731263656:error:260B606D:engine routines:DYNAMIC_LOAD:init failed:eng_dyn.c:521:
139866731263656:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:417:id=padlock

showed that the program had its problems with the engine. That is where the trouble started. After some searching the internet for a solution I found a site that provided the right clue.

OpenSSL Patches

David Mansfield describes a improvment to the four patches from alpine linux. It seems that these patches did not find their way into the upstream code.

No problem, that is why I use open source software. Downloading the latest sources and patching did work. The installation with ./config; make; make install also did not result in any errors. Now I had a working instance of OpenSSL in /usr/local/ssl/bin.

OpenSSL Performance

I choose OpenSSL for the first performace tests because it provides a very simple interface on the command line. the command provides the option speed that conducts all tests and simply prints out the results. The command

#   /usr/local/ssl/bin/openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 14419880 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 10741530 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 4936872 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 1560126 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 211517 aes-128-cbc's in 3.00s
OpenSSL 1.0.1e 11 Feb 2013
built on: Tue Sep 17 20:07:10 CEST 2013
options:bn(64,64) rc4(8x,int) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx)
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      76906.03k   229152.64k   421279.74k   532523.01k   577582.42k

shows impressive numbers for such a small system. 530 MByte/s (with 1024 byte blocks) was promising. For comparison I want to show the numbers for the Eden chip without the padlock engine:

The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128-cbc      38380.82k    42020.27k    42835.63k    43245.23k    43379.37k

about a order of magnitude worse. With the hardware encryption compiled into OpenSSL the VIA Eden is nearly as fast a my quad core i5 notebook. At least the figures with large blocks.

If you have any further questions, please mail me


Kommentare deaktiviert.