benchmark, kernel, libgcrypt, comparisons

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

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.

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.

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

Milan Broz:

thanks
i compiled with openssl to see and hash algos were approx 2x 'speedier' for me

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