Re: [dm-crypt] hardware encryption

[Matthias Schniedermeyer <ms@citd.de>]

On 14.03.2013 21:50, Yves-Alexis Perez wrote:
> On jeu., 2013-03-14 at 14:14 +0100, Matthias Schniedermeyer wrote:
> > Given that openssl doesn't support AES-NI i'm not surprized.
> 
> Where did you get that impression?
> > 
> > Last time i looked AES-NI support in openssl was "in Limbo" and it
> > may 
> > still take quite some time(years) until there is a release which 
> > officially supports AES-NI. This is despite first patches beeing made 
> > available before there was silicon, so openssl is quite a few years 
> > behind.
> 
> Actually, OpenSSL supports AES-NI since 1.0.1 (see
> http://www.openssl.org/news/changelog.html)

I stand corrected.
I appears the last time i look was january 2012 which was about 2 month 
before 1.0.1.
Which is still quite a few years late and only just before the 3rd 
generation of silicon (a.k.a. Ivy Bridge) was released.

> > I'm using an unofficial "something" (Can't remember what it is excatly
> > ) 
> > so that openssl can utelize AES-NI which in turn enables AES-NI usage 
> > for SSH, so i can use it for scp or rsync over SSH.
> > The difference is quite noticable, altough in LANs i just use
> > ARCFOUR. 
> > No patching necesarry to saturate Gigabit. :-)
> > 
> > When i tested it some time back over loopback both AES-128-CBC(*)
> > (with 
> > AES-NI) and ARCFOUR peaked at about 400MB/s(IIRC), so no problem
> > doing 
> > the 110MB/s needed to saturate Gigabit.
> 
> It all really depends on block size. But on my (Core i7 L640) laptop,
> there's really no reason to use rc4 anymore. CBC is not the best
> example, aes-128-cbc is indeed accelerated by AES-NI instructions but
> you really go fast with a mode using PCLMULQDQD like XTS:

Not for SSH. It's either CBC or CTR.
Core i7 2600, openssl 1.0.1e:
aes-128-cbc     664319.53k   725474.88k   734899.20k   739633.83k   741460.93k
aes-128-ctr     435376.52k  1366581.94k  2590570.68k  3404566.09k  3712237.79k

ctr benchmarks good, but SSH does something wrong, copying a 1GB file 
from tmpfs to tmpfs via loopback:
scp -c aes128-cbc .... 100% 1024MB 256.0MB/s   00:04
scp -c aes128-ctr .... 100% 1024MB  78.8MB/s   00:13

That is the same speed as software AES, maybe it doesn't select the 
right engine or something like that.

ssh -V
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013

> type             16 bytes     64 bytes    256 bytes   1024 bytes   8192
> bytes
> rc4             255340.98k   469098.47k   599298.65k   658621.73k
> 679368.02k
> aes-128 cbc      85363.96k    91553.34k    93105.32k    93570.31k
> 93784.75k
> aes-128-xts     272573.48k   849359.06k  1540640.28k  1956586.50k
> 2111556.27k
> 
> It's even stronger when you use authenticated ciphers like GCM if you
> compare it against enc+mac. You can't openssl speed on those but using
> 1k blocs:
> 
> for cipher in aes-128-cbc-hmac-sha1 aes-128-gcm rc4-hmac-md5; do echo
> $cipher; dd if=/dev/zero bs=1k count=1M | openssl enc -${cipher} -pass
> pass:foo > /dev/null; done 
> aes-128-cbc-hmac-sha1
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 3,27757 s, 328 MB/s
> aes-128-gcm
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 1,90992 s, 562 MB/s
> rc4-hmac-md5
> 1048576+0 records in
> 1048576+0 records out
> 1073741824 bytes (1,1 GB) copied, 3,40679 s, 315 MB/s
> 
> It's a bit out of scope for this list, but that means using dm-crypt
> aes-xts-plain64 on an AES-NI CPU really makes sense. On those boxes it
> might be even faster to use aes-256-xts than aes-128-cbc.

You would have to try it with cryptsetup and i can say XTS, on a Core i7 
3770, peaks at over 1GB/s. I'd say that is plenty fast. :-)

Highest number i personally achieved was decrypting an old loopaes 
DVD-image-file with aespipe (V1 format, which means: aes-128-CBC). It 
took about 3 seconds to decrypt the 4489 MB file (tmpfs to tmpfs) so 
nearly 1.5 GB/s. :-)





-- 

Matthias