* [dm-crypt] benchmark, kernel, libgcrypt, comparisons
@ 2014-01-29 14:22 shmick
2014-01-29 14:59 ` Milan Broz
2014-01-30 22:10 ` Matthias Schniedermeyer
0 siblings, 2 replies; 4+ messages in thread
From: shmick @ 2014-01-29 14:22 UTC (permalink / raw)
To: dm-crypt
i came across a text file benchmark i did with the 2nd latest cryptsetup
and thought id see how 1.6.3 would look
i have different kernel and libgcrpyt versions since 1.6.2 as well and
it was said on the gnupg list when libgcrypt 1.6.0 came out there were
some speed improvements
what would likely be the main source of speed increases - kernel or
libgcrypt ?
serpent decryption is vastly faster, twofish in general but seems AES isn't
$ cryptsetup benchmark
1.6.2
libgcrypt 1.5.3
kernel 3.2.0-58
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 337814 iterations per second
PBKDF2-sha256 175229 iterations per second
PBKDF2-sha512 111455 iterations per second
PBKDF2-ripemd160 255500 iterations per second
PBKDF2-whirlpool 142935 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 150.0 MiB/s 181.1 MiB/s
serpent-cbc 128b 56.7 MiB/s 61.2 MiB/s
twofish-cbc 128b 140.0 MiB/s 192.8 MiB/s
aes-cbc 256b 119.5 MiB/s 137.3 MiB/s
serpent-cbc 256b 56.7 MiB/s 60.9 MiB/s
twofish-cbc 256b 140.4 MiB/s 192.8 MiB/s
aes-xts 256b 172.0 MiB/s 176.8 MiB/s
serpent-xts 256b 58.2 MiB/s 60.7 MiB/s
twofish-xts 256b 132.5 MiB/s 138.3 MiB/s
aes-xts 512b 132.0 MiB/s 134.3 MiB/s
serpent-xts 512b 58.9 MiB/s 61.2 MiB/s
twofish-xts 512b 132.0 MiB/s 137.9 MiB/s
$ cryptsetup benchmark
1.6.3
libgcrypt 1.6.0
kernel 3.11.0-15
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 680010 iterations per second
PBKDF2-sha256 468114 iterations per second
PBKDF2-sha512 315076 iterations per second
PBKDF2-ripemd160 458293 iterations per second
PBKDF2-whirlpool 154748 iterations per second
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 150.2 MiB/s 180.4 MiB/s
serpent-cbc 128b 52.3 MiB/s 228.2 MiB/s
twofish-cbc 128b 138.4 MiB/s 190.4 MiB/s
aes-cbc 256b 117.5 MiB/s 136.0 MiB/s
serpent-cbc 256b 56.9 MiB/s 237.8 MiB/s
twofish-cbc 256b 139.9 MiB/s 190.2 MiB/s
aes-xts 256b 171.3 MiB/s 176.6 MiB/s
serpent-xts 256b 207.1 MiB/s 215.0 MiB/s
twofish-xts 256b 175.8 MiB/s 175.8 MiB/s
aes-xts 512b 131.4 MiB/s 134.1 MiB/s
serpent-xts 512b 209.4 MiB/s 214.8 MiB/s
twofish-xts 512b 175.7 MiB/s 175.7 MiB/s
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] benchmark, kernel, libgcrypt, comparisons
2014-01-29 14:22 [dm-crypt] benchmark, kernel, libgcrypt, comparisons shmick
@ 2014-01-29 14:59 ` Milan Broz
2014-01-29 15:52 ` shmick
2014-01-30 22:10 ` Matthias Schniedermeyer
1 sibling, 1 reply; 4+ messages in thread
From: Milan Broz @ 2014-01-29 14:59 UTC (permalink / raw)
To: shmick@riseup.net, dm-crypt
On 01/29/2014 03:22 PM, shmick@riseup.net wrote:
> i came across a text file benchmark i did with the 2nd latest cryptsetup
> and thought id see how 1.6.3 would look
>
> i have different kernel and libgcrpyt versions since 1.6.2 as well and
> it was said on the gnupg list when libgcrypt 1.6.0 came out there were
> some speed improvements
In fact, gcrypt 1.6.0 was major slowdown for PBKDF2 (previously cryptsetup
used own implementation because it was not available in gcrypt), but it will
be fixed in gcrypt 1.6.1.
> what would likely be the main source of speed increases - kernel or
> libgcrypt ?
In general, for hash algorithm used in header parsing or key derivation
user space library is important (gcrypt), for block ciphers it is kernel.
Usually in userspace openssl backend is faster, but gcrypt is default.
It is not much important because this is used only during device unlocking,
data access later is pure kernel dm-crypt job.
> serpent decryption is vastly faster, twofish in general but seems AES isn't
This depends on machine (and which cipher implementation - it can be accelerated
through AES-NI, SSE instruction etc, depends on your arch and kernel config).
I think kernel API has continuous improvement, so check crypt modules available
(dmcrypt will simply use what crypto API provides).
Milan
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] benchmark, kernel, libgcrypt, comparisons
2014-01-29 14:59 ` Milan Broz
@ 2014-01-29 15:52 ` shmick
0 siblings, 0 replies; 4+ messages in thread
From: shmick @ 2014-01-29 15:52 UTC (permalink / raw)
To: dm-crypt
Milan Broz:
> On 01/29/2014 03:22 PM, shmick@riseup.net wrote:
>> i came across a text file benchmark i did with the 2nd latest cryptsetup
>> and thought id see how 1.6.3 would look
>>
>> i have different kernel and libgcrpyt versions since 1.6.2 as well and
>> it was said on the gnupg list when libgcrypt 1.6.0 came out there were
>> some speed improvements
>
> In fact, gcrypt 1.6.0 was major slowdown for PBKDF2 (previously cryptsetup
> used own implementation because it was not available in gcrypt), but it will
> be fixed in gcrypt 1.6.1.
>
>> what would likely be the main source of speed increases - kernel or
>> libgcrypt ?
>
> In general, for hash algorithm used in header parsing or key derivation
> user space library is important (gcrypt), for block ciphers it is kernel.
>
> Usually in userspace openssl backend is faster, but gcrypt is default.
thanks
i compiled with openssl to see and hash algos were approx 2x 'speedier'
for me
>
> It is not much important because this is used only during device unlocking,
> data access later is pure kernel dm-crypt job.
>
>> serpent decryption is vastly faster, twofish in general but seems AES isn't
>
> This depends on machine (and which cipher implementation - it can be accelerated
> through AES-NI, SSE instruction etc, depends on your arch and kernel config).
> I think kernel API has continuous improvement, so check crypt modules available
> (dmcrypt will simply use what crypto API provides).
>
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [dm-crypt] benchmark, kernel, libgcrypt, comparisons
2014-01-29 14:22 [dm-crypt] benchmark, kernel, libgcrypt, comparisons shmick
2014-01-29 14:59 ` Milan Broz
@ 2014-01-30 22:10 ` Matthias Schniedermeyer
1 sibling, 0 replies; 4+ messages in thread
From: Matthias Schniedermeyer @ 2014-01-30 22:10 UTC (permalink / raw)
To: shmick@riseup.net; +Cc: dm-crypt
On 30.01.2014 01:22, shmick@riseup.net wrote:
> serpent decryption is vastly faster, twofish in general but seems AES isn't
>
> # Algorithm | Key | Encryption | Decryption
> aes-cbc 128b 150.2 MiB/s 180.4 MiB/s
> aes-cbc 256b 117.5 MiB/s 136.0 MiB/s
> aes-xts 256b 171.3 MiB/s 176.6 MiB/s
> aes-xts 512b 131.4 MiB/s 134.1 MiB/s
Just to get a little indication of the "smidge" better performance of
hardware accelerated AES.
This is what i get for AES on Core i7 4770 (a.k.a. Haswell)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 753.2 MiB/s 3305.0 MiB/s
aes-cbc 256b 551.4 MiB/s 2509.0 MiB/s
aes-xts 256b 2799.0 MiB/s 2853.0 MiB/s
aes-xts 512b 2154.0 MiB/s 2162.0 MiB/s
--
Matthias
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-01-30 22:10 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-29 14:22 [dm-crypt] benchmark, kernel, libgcrypt, comparisons shmick
2014-01-29 14:59 ` Milan Broz
2014-01-29 15:52 ` shmick
2014-01-30 22:10 ` Matthias Schniedermeyer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox