Comments on: Cipher benchmark for dm-crypt / LUKS http://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/ a technical IT blog Fri, 13 Jan 2012 23:16:03 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Flyerhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-4901 Flyer Sat, 03 Dec 2011 13:56:38 +0000 http://blog.wpkg.org/?p=70#comment-4901 CentOS 6 (2.6.32-71.29.1.el6.x86_64) with 16GB RAM (RAM-disk 11GB, file 10GB) - VM (only single)on ESXi5, 2 x Xeon E5530 48GB RAMScript from Heikki Salokanto, modifyed (error-control)Options (mode) Write Read default (aes-cbc-essiv:sha256 256) 82.77 102.76 -c aes (cbc-plain 256) 82.00 105.79 -c aes -s 128 (cbc-plain) 104.91 139.99 -c aes-ecb -s 128 121.56 151.59 -c aes-cbc-null -s 128 100.85 139.72 -c aes-cbc-plain -s 128 100.97 139.70 -c aes-cbc-benbi -s 128 100.71 139.66 -c aes-cbc-essiv:sha256 -s 128 98.02 134.77 -c aes-pcbc-null -s 128 95.89 105.71 -c aes-pcbc-plain -s 128 98.59 105.63 -c aes-pcbc-benbi -s 128 94.13 105.62 -c aes-pcbc-essiv:sha256 -s 128 95.51 102.86 -c aes-ctr-plain -s 128 111.94 137.34 -c aes -s 256 (cbc-plain) 83.59 105.71 -c aes-ecb -s 256 96.98 112.92 -c aes-cbc-null -s 256 84.46 105.69 -c aes-cbc-plain -s 256 84.22 105.70 -c aes-cbc-plain64 -s 256 80.44 105.73 -c aes-cbc-benbi -s 256 81.42 105.47 -c aes-cbc-essiv:sha256 -s 256 78.61 102.98 -c aes-pcbc-null -s 256 80.89 84.52 -c aes-pcbc-plain -s 256 80.37 84.62 -c aes-pcbc-plain64 -s 256 76.38 84.52 -c aes-pcbc-benbi -s 256 79.83 84.62 -c aes-pcbc-essiv:sha256 -s 256 75.48 82.71 -c aes-lrw-null -s 256 (128) 108.64 132.97 -c aes-lrw-plain -s 256 (128) 111.43 132.99 -c aes-lrw-plain64 -s 256 (128) 111.95 133.11 -c aes-lrw-benbi -s 256 (128) 111.83 133.26 -c aes-lrw-essiv:sha256 -s 256 (128) 104.83 127.86 -c aes-lrw-null -s 384 (256) 82.58 102.08 -c aes-lrw-plain -s 384 (256) 86.82 101.99 -c aes-lrw-plain64 -s 384 (256) 82.12 101.76 -c aes-lrw-benbi -s 384 (256) 86.64 102.04 -c aes-lrw-essiv:sha256 -s 384 (256) 84.30 98.58 -c aes-xts-null -s 256 (128) 112.00 137.21 -c aes-xts-plain -s 256 (128) 111.06 137.08 -c aes-xts-plain64 -s 256 (128) 109.64 136.95 -c aes-xts-benbi -s 256 (128) 113.97 137.12 -c aes-xts-essiv:sha256 -s 256 (128) 104.28 132.15 -c aes-xts-null -s 512 (256) 85.78 104.07 -c aes-xts-plain -s 512 (256) 88.78 103.80 -c aes-xts-plain64 -s 512 (256) 87.89 103.86 -c aes-xts-benbi -s 512 (256) 90.01 103.76 -c aes-xts-essiv:sha256 -s 512 (256) 85.81 101.25 -c aes-ctr-null -s 256 86.65 103.91 -c aes-ctr-plain -s 256 86.33 103.99 -c aes-ctr-plain64 -s 256 88.17 104.15 -c aes-ctr-benbi -s 256 85.65 103.93 -c aes-ctr-essiv:sha256 -s 256 87.09 101.47 -c des-ecb-plain -s 64 44.21 48.53 -c anubis -s 128 (cbc-plain) 84.57 106.66 -c anubis-ecb-plain -s 128 92.04 114.43 -c anubis-cbc-plain -s 128 79.48 104.86 -c anubis -s 256 (cbc-plain) 67.69 84.64 -c anubis-ecb-plain -s 256 75.93 90.33 -c anubis-cbc-plain -s 256 66.87 83.70 -c blowfish (cbc-plain 256) 62.40 85.50 -c blowfish-ecb-plain (256) 72.29 92.52 -c blowfish-cbc-plain (256) 61.70 85.49 -c blowfish-cbc-essiv:sha256 -s 256 63.32 84.16 -c twofish (cbc-plain 256) 88.63 116.51 -c twofish-cbc-essiv:sha256 -s 256 86.34 113.89 -c twofish-lrw-essiv:sha256 -s 256 (128) 84.76 109.01 -c twofish-xts-essiv:sha256 -s 256 (128) 88.70 111.03 -c twofish-xts-essiv:sha256 -s 512 (256) 91.41 111.04 -c camellia -s 128 (cbc-plain) 76.31 97.80 -c camellia -s 256 (cbc-plain) 61.67 75.75 -c cast5-cbc-plain -s 128 58.21 77.55 -c cast6 (cbc-plain 256) 49.44 55.25 -c cast6-cbc-plain -s 256 48.71 55.37 -c tea-ecb-plain -s 128 36.55 37.92 -c xtea-ecb-plain -s 128 38.67 42.21 -c tnepres (cbc-plain 256) 41.03 48.71 -c serpent (cbc-plain 256) 42.92 51.05 -c khazad-ecb-plain -s 128 95.62 115.29 -c xeta-ecb-plain -s 128 44.55 45.30 -c fcrypt-pcbc-plain -s 64 58.96 64.30 CentOS 6 (2.6.32-71.29.1.el6.x86_64) with 16GB RAM (RAM-disk 11GB, file 10GB)
– VM (only single)on ESXi5, 2 x Xeon E5530 48GB RAM

Script from Heikki Salokanto, modifyed (error-control)

Options (mode) Write Read
default (aes-cbc-essiv:sha256 256) 82.77 102.76
-c aes (cbc-plain 256) 82.00 105.79
-c aes -s 128 (cbc-plain) 104.91 139.99
-c aes-ecb -s 128 121.56 151.59
-c aes-cbc-null -s 128 100.85 139.72
-c aes-cbc-plain -s 128 100.97 139.70
-c aes-cbc-benbi -s 128 100.71 139.66
-c aes-cbc-essiv:sha256 -s 128 98.02 134.77
-c aes-pcbc-null -s 128 95.89 105.71
-c aes-pcbc-plain -s 128 98.59 105.63
-c aes-pcbc-benbi -s 128 94.13 105.62
-c aes-pcbc-essiv:sha256 -s 128 95.51 102.86
-c aes-ctr-plain -s 128 111.94 137.34
-c aes -s 256 (cbc-plain) 83.59 105.71
-c aes-ecb -s 256 96.98 112.92
-c aes-cbc-null -s 256 84.46 105.69
-c aes-cbc-plain -s 256 84.22 105.70
-c aes-cbc-plain64 -s 256 80.44 105.73
-c aes-cbc-benbi -s 256 81.42 105.47
-c aes-cbc-essiv:sha256 -s 256 78.61 102.98
-c aes-pcbc-null -s 256 80.89 84.52
-c aes-pcbc-plain -s 256 80.37 84.62
-c aes-pcbc-plain64 -s 256 76.38 84.52
-c aes-pcbc-benbi -s 256 79.83 84.62
-c aes-pcbc-essiv:sha256 -s 256 75.48 82.71
-c aes-lrw-null -s 256 (128) 108.64 132.97
-c aes-lrw-plain -s 256 (128) 111.43 132.99
-c aes-lrw-plain64 -s 256 (128) 111.95 133.11
-c aes-lrw-benbi -s 256 (128) 111.83 133.26
-c aes-lrw-essiv:sha256 -s 256 (128) 104.83 127.86
-c aes-lrw-null -s 384 (256) 82.58 102.08
-c aes-lrw-plain -s 384 (256) 86.82 101.99
-c aes-lrw-plain64 -s 384 (256) 82.12 101.76
-c aes-lrw-benbi -s 384 (256) 86.64 102.04
-c aes-lrw-essiv:sha256 -s 384 (256) 84.30 98.58
-c aes-xts-null -s 256 (128) 112.00 137.21
-c aes-xts-plain -s 256 (128) 111.06 137.08
-c aes-xts-plain64 -s 256 (128) 109.64 136.95
-c aes-xts-benbi -s 256 (128) 113.97 137.12
-c aes-xts-essiv:sha256 -s 256 (128) 104.28 132.15
-c aes-xts-null -s 512 (256) 85.78 104.07
-c aes-xts-plain -s 512 (256) 88.78 103.80
-c aes-xts-plain64 -s 512 (256) 87.89 103.86
-c aes-xts-benbi -s 512 (256) 90.01 103.76
-c aes-xts-essiv:sha256 -s 512 (256) 85.81 101.25
-c aes-ctr-null -s 256 86.65 103.91
-c aes-ctr-plain -s 256 86.33 103.99
-c aes-ctr-plain64 -s 256 88.17 104.15
-c aes-ctr-benbi -s 256 85.65 103.93
-c aes-ctr-essiv:sha256 -s 256 87.09 101.47
-c des-ecb-plain -s 64 44.21 48.53
-c anubis -s 128 (cbc-plain) 84.57 106.66
-c anubis-ecb-plain -s 128 92.04 114.43
-c anubis-cbc-plain -s 128 79.48 104.86
-c anubis -s 256 (cbc-plain) 67.69 84.64
-c anubis-ecb-plain -s 256 75.93 90.33
-c anubis-cbc-plain -s 256 66.87 83.70
-c blowfish (cbc-plain 256) 62.40 85.50
-c blowfish-ecb-plain (256) 72.29 92.52
-c blowfish-cbc-plain (256) 61.70 85.49
-c blowfish-cbc-essiv:sha256 -s 256 63.32 84.16
-c twofish (cbc-plain 256) 88.63 116.51
-c twofish-cbc-essiv:sha256 -s 256 86.34 113.89
-c twofish-lrw-essiv:sha256 -s 256 (128) 84.76 109.01
-c twofish-xts-essiv:sha256 -s 256 (128) 88.70 111.03
-c twofish-xts-essiv:sha256 -s 512 (256) 91.41 111.04
-c camellia -s 128 (cbc-plain) 76.31 97.80
-c camellia -s 256 (cbc-plain) 61.67 75.75
-c cast5-cbc-plain -s 128 58.21 77.55
-c cast6 (cbc-plain 256) 49.44 55.25
-c cast6-cbc-plain -s 256 48.71 55.37
-c tea-ecb-plain -s 128 36.55 37.92
-c xtea-ecb-plain -s 128 38.67 42.21
-c tnepres (cbc-plain 256) 41.03 48.71
-c serpent (cbc-plain 256) 42.92 51.05
-c khazad-ecb-plain -s 128 95.62 115.29
-c xeta-ecb-plain -s 128 44.55 45.30
-c fcrypt-pcbc-plain -s 64 58.96 64.30

]]> By: Heikki Salokantohttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-4795 Heikki Salokanto Sun, 30 Oct 2011 20:46:53 +0000 http://blog.wpkg.org/?p=70#comment-4795 Hi,I ran a few tests on my Atom D525 (dual core 1.8 GHz) NAS box. It is running Ubuntu 11.04, Linux 2.6.38-8. There's 4 GB of RAM, of which I used ~1 GB to create a ramdisk for the tests.The script is at http://www.salokanto.fi/linux/test-crypt-perf.sh. It's not pretty, but you can modify it for your needs.Results (in MiB/s):<code> Options Write Read -c aes-xts-plain -s 256 45.53 43.89 -c aes-cbc-essiv:sha256 -s 128 44.89 45.33 -c aes-xts-plain -s 384 46.55 38.61 -c aes-cbc-essiv:sha256 -s 192 33.56 39.07 -c aes-xts-plain -s 512 41.11 36.15 -c aes-cbc-essiv:sha256 -s 256 31.01 36.13 </code>My understanding is that xts-plain must use double the key length compared to that of aes-cbc-essiv:sha256 in order to attain similar strength. Hi,

I ran a few tests on my Atom D525 (dual core 1.8 GHz) NAS box. It is running Ubuntu 11.04, Linux 2.6.38-8. There’s 4 GB of RAM, of which I used ~1 GB to create a ramdisk for the tests.

The script is at http://www.salokanto.fi/linux/test-crypt-perf.sh. It’s not pretty, but you can modify it for your needs.

Results (in MiB/s):


Options Write Read
-c aes-xts-plain -s 256 45.53 43.89
-c aes-cbc-essiv:sha256 -s 128 44.89 45.33
-c aes-xts-plain -s 384 46.55 38.61
-c aes-cbc-essiv:sha256 -s 192 33.56 39.07
-c aes-xts-plain -s 512 41.11 36.15
-c aes-cbc-essiv:sha256 -s 256 31.01 36.13

My understanding is that xts-plain must use double the key length compared to that of aes-cbc-essiv:sha256 in order to attain similar strength.

]]> By: Aaron Toponcehttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-4767 Aaron Toponce Sun, 16 Oct 2011 14:25:18 +0000 http://blog.wpkg.org/?p=70#comment-4767 Even though ECB is a speed demon in terms of encryption, you should strongly avoid using it. https://secure.wikimedia.org/wikipedia/en/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 explains why, and gives a good demonstration. And because the first parts of the disk clearly show the algorithm, key size and hash used, it shouldn't even be an option, IMO.Check out the first part of an aes-ebc-null disk with a 128 byte key:<pre>0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000 LUKS....aes..... 0000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000020: 0000 0000 0000 0000 6563 622d 6e75 6c6c ........ecb-null 0000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000040: 0000 0000 0000 0000 7368 6131 0000 0000 ........sha1.... 0000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0000060: 0000 0000 0000 0000 0000 0800 0000 0010 ................ 0000070: 3ee5 e173 f1c9 1241 5eb8 da2e 4e96 5851 >..s...A^...N.XQ 0000080: d788 8016 447d 83ab 3d51 6fdb d077 c6fb ....D}..=Qo..w.. 0000090: 4059 74f3 07da f0b0 1743 1eb0 11d5 7ebb @Yt......C....~. 00000a0: 5fba 2011 0000 631f 6331 6138 3262 6564 _. ...c.c1a82bed 00000b0: 2d33 3661 362d 3464 3337 2d61 3863 612d -36a6-4d37-a8ca- 00000c0: 3032 3065 3233 3965 3062 6362 0000 0000 020e239e0bcb.... 00000d0: 00ac 71f3 0001 8dbc 598d f82b 50a4 a973 ..q.....Y..+P..s 00000e0: 6e8d c8eb 3c4f c22b b8d3 ed74 75b9 9550 n...<O.+...tu..P 00000f0: 632a d60e a232 ccc1 0000 0008 0000 0fa0 c*...2..........</pre> Even though ECB is a speed demon in terms of encryption, you should strongly avoid using it. https://secure.wikimedia.org/wikipedia/en/wiki/Block_cipher_modes_of_operation#Electronic_codebook_.28ECB.29 explains why, and gives a good demonstration. And because the first parts of the disk clearly show the algorithm, key size and hash used, it shouldn’t even be an option, IMO.

Check out the first part of an aes-ebc-null disk with a 128 byte key:

0000000: 4c55 4b53 babe 0001 6165 7300 0000 0000  LUKS....aes.....
0000010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000020: 0000 0000 0000 0000 6563 622d 6e75 6c6c  ........ecb-null
0000030: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000040: 0000 0000 0000 0000 7368 6131 0000 0000  ........sha1....
0000050: 0000 0000 0000 0000 0000 0000 0000 0000  ................
0000060: 0000 0000 0000 0000 0000 0800 0000 0010  ................
0000070: 3ee5 e173 f1c9 1241 5eb8 da2e 4e96 5851  >..s...A^...N.XQ
0000080: d788 8016 447d 83ab 3d51 6fdb d077 c6fb  ....D}..=Qo..w..
0000090: 4059 74f3 07da f0b0 1743 1eb0 11d5 7ebb  @Yt......C....~.
00000a0: 5fba 2011 0000 631f 6331 6138 3262 6564  _. ...c.c1a82bed
00000b0: 2d33 3661 362d 3464 3337 2d61 3863 612d  -36a6-4d37-a8ca-
00000c0: 3032 3065 3233 3965 3062 6362 0000 0000  020e239e0bcb....
00000d0: 00ac 71f3 0001 8dbc 598d f82b 50a4 a973  ..q.....Y..+P..s
00000e0: 6e8d c8eb 3c4f c22b b8d3 ed74 75b9 9550  n...<O.+...tu..P
00000f0: 632a d60e a232 ccc1 0000 0008 0000 0fa0  c*...2..........
]]> By: anonymoushttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-4424 anonymous Mon, 08 Aug 2011 11:33:44 +0000 http://blog.wpkg.org/?p=70#comment-4424 Shecky, you're a legend. Cheers for the .csv!It's certainly confusing how 512-bit xts is better compared to 256-bit cbc, especially when the double key length requirement seems to be a mistake by the spec writers :/ Shecky, you’re a legend. Cheers for the .csv!

It’s certainly confusing how 512-bit xts is better compared to 256-bit cbc, especially when the double key length requirement seems to be a mistake by the spec writers :/

]]> By: adminhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-3979 admin Sun, 01 May 2011 19:17:29 +0000 http://blog.wpkg.org/?p=70#comment-3979 @Jim: I don't think so, at least not without some really major effort.It would be easier to compile your own kernel, or use 2.6.38 provided by your distribution (developer build etc.). @Jim: I don’t think so, at least not without some really major effort.

It would be easier to compile your own kernel, or use 2.6.38 provided by your distribution (developer build etc.).

]]> By: Jimhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-3977 Jim Sun, 01 May 2011 18:24:28 +0000 http://blog.wpkg.org/?p=70#comment-3977 Thanks. Now I just have to wait until the distro vendors actually ship kernel 2.6.38. Is there any chance to apply the patch to older kernels (e.g. 2.6.32?) Thanks. Now I just have to wait until the distro vendors actually ship kernel 2.6.38. Is there any chance to apply the patch to older kernels (e.g. 2.6.32?)

]]> By: adminhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-3969 admin Fri, 29 Apr 2011 20:56:48 +0000 http://blog.wpkg.org/?p=70#comment-3969 Multi-CPU-support was added in 2.6.38 (look for "dm-crypt: scale to multiple cpu"):http://kernelnewbies.org/Linux_2_6_38 Multi-CPU-support was added in 2.6.38 (look for “dm-crypt: scale to multiple cpu”):

http://kernelnewbies.org/Linux_2_6_38

]]> By: Jimhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-3968 Jim Fri, 29 Apr 2011 20:42:35 +0000 http://blog.wpkg.org/?p=70#comment-3968 Are there any news concerning benchmarks and dm-crypt since the last comments were posted on this blog about a year ago? In particular, how is the multi-CPU-support coming that you mentioned on May 31 last year?By the way, I really appreciate this site, even if my previous comments may have sounded quite critical. Keep up the good work! Are there any news concerning benchmarks and dm-crypt since the last comments were posted on this blog about a year ago? In particular, how is the multi-CPU-support coming that you mentioned on May 31 last year?

By the way, I really appreciate this site, even if my previous comments may have sounded quite critical. Keep up the good work!

]]> By: Ubuntu encrypted home | welcome to the world of...http://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-3727 Ubuntu encrypted home | welcome to the world of... Fri, 18 Mar 2011 18:04:53 +0000 http://blog.wpkg.org/?p=70#comment-3727 [...] the encryption I decided to utilize aes-ebc-plain with key size 128 bits for its speed (I don’t need military grade safety). Partitions [...] [...] the encryption I decided to utilize aes-ebc-plain with key size 128 bits for its speed (I don’t need military grade safety). Partitions [...]

]]> By: Sheckyhttp://blog.wpkg.org/2009/04/23/cipher-benchmark-for-dm-crypt-luks/comment-page-1/#comment-1684 Shecky Tue, 25 May 2010 19:17:31 +0000 http://blog.wpkg.org/?p=70#comment-1684 I think I see the problem with Frank's benchmark results.In his test script, he runs "cryptsetup ... luksFormat ..." without checking for an error. If a previous iteration left a valid luks device AND the failed luksFormat left loop0 unmodified, the subsequent luksOpen would succeed and the benchmark would run for the previous cipher-mode-iv combination. This appears to explain why there are valid results for impossible modes such as "-c aes-xts-plain -s 128" (128 is an invalid blocksize for aes-xts), "-c blowfish-xts-X" and "cast5-xts-X" (blowfish and cast5 have 8 byte block size and won't work in XTS mode at all), anything with salsa20 (salsa20 is a stream cipher), and "-c arc4-xts-plain -s arc4" (interesting block size, that.) I think I see the problem with Frank’s benchmark results.

In his test script, he runs “cryptsetup … luksFormat …” without checking for an error. If a previous iteration left a valid luks device AND the failed luksFormat left loop0 unmodified, the subsequent luksOpen would succeed and the benchmark would run for the previous cipher-mode-iv combination. This appears to explain why there are valid results for impossible modes such as “-c aes-xts-plain -s 128″ (128 is an invalid blocksize for aes-xts), “-c blowfish-xts-X” and “cast5-xts-X” (blowfish and cast5 have 8 byte block size and won’t work in XTS mode at all), anything with salsa20 (salsa20 is a stream cipher), and “-c arc4-xts-plain -s arc4″ (interesting block size, that.)

]]>