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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
