I followed this guide http://www.newit.co.uk/forum/index.php?topic=2030.0 loosely and used cryptodev-linux. Part of it was compiled on PC via code sorcery toolchain cross compile and other parts on the dockstar itself.

Some benchmark results:

root@debian:/usr/local/ssl/bin# uname -a  
Linux debian 3.1.10-dockstar #3 PREEMPT Fri Jan 20 20:42:45 SGT 2012 armv5tel GNU/Linux
root@debian:/usr/local/ssl/bin# 
root@debian:/usr/local/ssl/bin# ./openssl speed -evp aes-128-cbc
Doing aes-128-cbc for 3s on 16 size blocks: 105194 aes-128-cbc's in 0.10s
Doing aes-128-cbc for 3s on 64 size blocks: 101139 aes-128-cbc's in 0.11s
Doing aes-128-cbc for 3s on 256 size blocks: 68158 aes-128-cbc's in 0.06s
Doing aes-128-cbc for 3s on 1024 size blocks: 40824 aes-128-cbc's in 0.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 8529 aes-128-cbc's in 0.00s
OpenSSL 1.0.0g 18 Jan 2012
built on: Fri Jan 20 22:13:19 SGT 2012
options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) idea(int) blowfish(ptr) 
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DHASH_MAX_LEN=64 -DTERMIO -O3 -Wall -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_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      16831.04k    58844.51k   290807.47k         infk         infk

I would be very careful about using mv_cesa. As I wanted to find out, if it's possible to encrypt the whole rootfs (see http://forum.doozan.com/read.php?2,6039,6083#msg-6083) I learned that with mv_cesa loaded the kernel would boot approximately in one case out of ten. Then I decided to to encrypt the rootfs without mv_cesa, but to use hardware offloading at least for the swap. Unfortunately that didn't work that well either. Every time something really got swapped, I faced sudden segfaults. For example, when the RAM is almost full and you do an "apt-get update", apt-get segfaults after a few second for no reason. It took me a few days to realize that this was coming from the fact that I used hardware offloading for the swap.

In the upshot, although the mv_cesa module compiles and loads just fine, it seems to be somehow broken, in a sense that all the data that goes through it gets corrupted. So if you face any problems with data integrity, try disabling hardware offloading first, and see if it ultimately solves the problem.

Some updates from the arch linux arm folks: http://archlinuxarm.org/forum/viewtopic.php?f=30&t=2452

Will attempt to do the same for Debian ARM.

Looks like it is good to go: http://archlinuxarm.org/forum/viewtopic.php?f=30&t=2452&start=50#p15238

For what it's worth, I made a French howto available here :

http://blog.slucas.fr/blog/dockstar-archlinux-cryptodev

there is also some graph (near the end) that show what gain to expect from cryptodev.