Hardware accelerated encryption on GoFlex Net / Dockstar or is mv_cesa of any practical use?

I've been experimenting with hardware accelerated encryption via mv_cesa on my GoFlex Net but somehow I'm quite confused now. I'm not a cryptography expert whatsoever but after reading a lot of wikis and forums I found out that mv_cesa accelerates only a very limited number of ciphers. Here's a part of my /proc/crypto related to mv_cesa

name         : hmac(sha1)
driver       : mv-hmac-sha1
module       : mv_cesa
priority     : 300
refcnt       : 1
selftest     : passed
type         : ahash
async        : yes
blocksize    : 64
digestsize   : 20

name         : sha1
driver       : mv-sha1
module       : mv_cesa
priority     : 300
refcnt       : 1
selftest     : passed
type         : ahash
async        : yes
blocksize    : 64
digestsize   : 20

name         : cbc(aes)
driver       : mv-cbc-aes
module       : mv_cesa
priority     : 300
refcnt       : 1
selftest     : passed
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 16
geniv        : <default>

name         : ecb(aes)
driver       : mv-ecb-aes
module       : mv_cesa
priority     : 300
refcnt       : 1
selftest     : passed
type         : ablkcipher
async        : yes
blocksize    : 16
min keysize  : 16
max keysize  : 32
ivsize       : 0
geniv        : <default>

So, as we can see mv_cesa sort of supports aes-cbc,aes sha1 and aes-ecb. According to the Wikipedia, ecb is not a very secure cipher and better shouldn't be used at all. So one is out. As far as "aes sha1" is concened, once again Wikipedia tells that sha1 has some serious weaknesses and thus shouldn't be used too. Now we have only cbc left. But, as far as disk encryption is concerned, cbc is vulnerable to the so called watermarking attack This can be remedied by using cbc-essiv instead of cbc-plain, but (surprise, surprise) according to my experiments, mv_cesa doesn't accelerate cbc-essiv. Thus, if you want to encrypt a drive using mv_cesa you can use

cryptsetup luksFormat -c aes-cbc-plain -s 256 -h sha512 /dev/sdXY

or

cryptsetup luksFormat -c aes-ecb-plain -s 256 /dev/sdXY

or

cryptsetup luksFormat -c aes -h sha1 /dev/sdXY

But none of those is really safe. Most dm_crypt/LUKS related sites and blogs recommend using aes-xts-plain.

cryptsetup -y --cipher aes-xts-plain --key-size 512 luksFormat /dev/sdXY

which is considered to be one of the safest and fastest out there. I tested that too, but when using aes-xts-plain, reading and writing speed break down dramatically. Then, there's also twofish which is considered to be equally safe as AES

cryptsetup luksFormat -c twofish-xts-plain --key-size 512 /dev/sdXY

Funny enough, whereas Wikipedia claims that twofish is slower than aes, I found this forum where people recommend using twofish for maximal speed. I tried that on my GoFlex Net and must admit that twofish-xts-plain is really very fast, even though it's not accelerated by mv_cesa. It's like 1,6 times faster than aes-xts-plain and only slightly slower than those (unsafe) hardware accelerated ciphers.

Here is a small pseudo-benchmark I did on my GoFlex Net with one SATA drive using hdparm -tT

aes-cbc-plain -s 256 -h sha512          11,32 MB/s
aes-ecb-plain -s 256			11,52 MB/s
aes -h sha1				11,29 MB/s
twofish-xts-plain --key-size 512	10,89 MB/s
aes-xts-plain --key-size 512		6,70 MB/S

From these results I can draw the following conclusions

1. mv_cesa is pretty useless, as it can accelerate only ciphers that are not really safe. If you don't care about cryptograhic safety, why bother encrypting at all?
2. twofish-xts-plain seems to be the way to go on GoFlex Net. Not only it's safe but also very fast.

As I've already said, I really don't know much about cryptography, so I may be talking nonsense here. If someone knows more about all this stuff (especially concerning practical recommendations for GoFlex Net / Dockstar) he or she is cordially invited to participate in this discussion

Hi Vlad,

Thanks sharing your testing results with us.

Have you tried Openssl or SSH/SCP offload performance also ?

No I didn't. As far as I understand, to enable SSH or OpenSSL acceleration you need to compile a kernel with cryptodev engine.
https://newit.co.uk/forum/index.php?topic=2030.0
I believe that's to much effort to get unsafe ciphers accelerated.

Quote
Vlad
but (surprise, surprise) according to my experiments, mv_cesa doesn't accelerate cbc-essiv.

According to my tests (kernel 2.6.32-5-kirkwood on a sheevaplug) it does.

Just not very well. (Doesn't accelerate anything very well, possibly due to not implementing DMA)

# cryptsetup luksDump /dev/md0
LUKS header information for /dev/md0

Version:       	1
Cipher name:   	aes
Cipher mode:   	cbc-essiv:sha256
Hash spec:     	sha1
Payload offset:	2056
...
#  cryptsetup --key-file hughes_crypt.key luksOpen /dev/md0 hughes_crypt
# dd if=/dev/mapper/hughes_crypt of=/dev/null count=10240001024000+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 67.2462 s, 7.8 MB/s

Try again without mv_cesa:

# cryptsetup luksClose hughes_crypt
# rmmod mv_cesa
# cryptsetup --key-file hughes_crypt.key luksOpen /dev/md0 hughes_crypt 
# dd if=/dev/mapper/hughes_crypt of=/dev/null count=1024000
1024000+0 records in
1024000+0 records out
524288000 bytes (524 MB) copied, 94.3556 s, 5.6 MB/s

So mv_cesa is being used. (During the tests without mv_cesa the system is at 100% cpu busy. With mv_cesa around 30% of the time is in wait for I/O).

Thanks for your test. Nice to know that mv_cesa is not completely useless, although 2,2MB/s more are quite lame.

Currently I use twofish-xts-plain for most purposes. For backups, where I really need the full speed, I use iSCSI + client side encryption. That gives me pretty decent 25-30MB/s when writing to an aes-xts-plain encrypted ext4 partition.

Could someone provide a tutorial for enabling hardware acceleration with openssl? I'm very confused. Do I have to compile a new kernel or can I just use the cryptodev package?

As far as I understand you must not only compile a new kernel (to get proper sources and headers) but also compile cryptodev and finally patch and compile openssl.

Out of curiosity I decided to do some futher tests on "aes-cbc-essiv:sha256" vs "twofish-xts-plain --key-size 512"

As John Hughes has already said, aes-cbc-essiv is supported by mv_cesa, whereas twofish is not.
Moreover, I used a SATA HDD connected to my GoFlex Net in order to eliminate possible USB flash speed limitations.
For my benchmarks I used dd with the following parameters

dd count=100000 bs=1K if=/dev/zero of=/mnt/test1.img
dd count=25000 bs=4K if=/dev/zero of=/mnt/test2.img
dd count=6500 bs=16K if=/dev/zero of=/mnt/test3.img
dd count=1500 bs=64K if=/dev/zero of=/mnt/test4.img
dd count=200 bs=512K if=/dev/zero of=/mnt/test5.img
dd count=100 bs=1M if=/dev/zero of=/mnt/test6.img
dd count=100000 bs=1K if=/mnt/test1.img of=/dev/null
dd count=25000 bs=4K if=/mnt/test2.img of=/dev/null
dd count=6500 bs=16K  if=/mnt/test3.img of=/dev/null
dd count=1500 bs=64K if=/mnt/test4.img of=/dev/null
dd count=200 bs=512K if=/mnt/test5.img of=/dev/null
dd count=100 bs=1M if=/mnt/test6.img of=/dev/null

Here's what I got (first column: mv_cesa acceleration, second and third columns: no acceleration)

Reading speed (reading 100MB from an ext4 partition)

block size | aes-cbc-essiv + mv_cesa | aes-cbc-essiv | twofish-xts-plain
    1K     |            10,3 MB/s    |     7,5MB/s   |  12,5 MB/s
    4K     |            10,3 MB/s    |     7,3MB/s   |  12,2 MB/s
    16K    |            10,4 MB/s    |     7,4MB/s   |  12,3 MB/s
    64K    |            10,4 MB/s    |     7,4MB/s   |  12,3 MB/s
    512K   |            10,2 MB/s    |     7,3MB/s   |  12,3 MB/s
    1M     |             9,7 MB/s    |     7,3MB/s   |  12,3 MB/s

Writing speed (witing 100MB on an ext4 partition)

block size | aes-cbc-essiv + mv_cesa | aes-cbc-essiv | twofish-xts-plain
    1K     |            10,5 MB/s    |     6,3MB/s   |  8,0 MB/s
    4K     |            11,7 MB/s    |     8,1MB/s   |  11,9 MB/s
    16K    |            10,5 MB/s    |     6,7MB/s   |  11,0 MB/s
    64K    |            10,6 MB/s    |     7,4MB/s   |  11,9 MB/s
    512K   |            11,4 MB/s    |     7,7MB/s   |  11,7 MB/s
    1M     |            10,6 MB/s    |     7,3MB/s   |  10,7 MB/s

For some reason, twofish slightly outperforms aes-cbc-essiv even though the latter is using hardware acceleration. May be it's because mv_cesa doesn't support DMA. On the other hand, with twofish you have about 90% CPU load comapred to 20-40% when using accelerated aes-cbc-essiv. To sum it up, if you want to use mv_cesa, go with aes-cbc-essiv:sha256 as it is the only accelerated cipher which is also cryptographically safe.

La_Tristesse Wrote:
-------------------------------------------------------
> Could someone provide a tutorial for enabling
> hardware acceleration with openssl? I'm very
> confused. Do I have to compile a new kernel or can
> I just use the cryptodev package?


http://www.altechnative.net/?p=174

Looks like I was the first one to learn it, and I learned it the hard way. mv_cesa doesn't work with newer kernels (for instance 2.6.38.8 and 3.0.0). It compiles fine and the module can be loaded, but the data becomes corrupted leading to segfaults and kernel panics. Sad, but true.