Take the 2-minute tour ×

I want to compare different encryption solutions for encrypting my system, possibly different solutions for different parts of the system such as /usr or /home. In particular I look at dm-crypt partitions, containers, truecrypt, ecryptfs and encfs with different parameters. For several reasons I think that just measuring raw seq read and write speeds using dd is not enough:

  • seq read/write gives me different CPU loads, for example ecryptfs loads only one core (up to 100%) whereas dm-crypt is faster, but loads both cores, so in real use ecryptfs may be faster when the system is under load from other applications (maybe not, but how do I benchmark this?)
  • it's all about an SSD so I want to have benchmark, which indicates for which option the system will feel more responsive, so I should include some random read write tests or something like that as well (but I don't know how to do so)
  • benchmarking a solution for /usr may need other benchmarks than for /home since the i/o characteristics may be different

I should add that my CPU doesn't support AES instructions, so it is a limiting factor in performance. I don't want to isolate a part of the system but compare the different encryption solutions for the SSD in my particular system. So what's the best way to benchmark in my case and how to do it in detail?

share|improve this question
add comment

3 Answers

See if bonnie++ gives you the tests/results you're looking for. Bonnie++ may be available from your distro's repos.

This article, SSD Linux benchmarking: Comparing filesystems and encryption methods may also be interesting to you.

share|improve this answer
it might be a good idea to link to the benchmark if you don't describe at least roughly what it tests :) (+1) –  peterph Oct 10 '13 at 17:15
Can you add some details of how to use it in my case? –  student Oct 10 '13 at 18:00
How does bonnie++ solve my first problem? –  student Oct 11 '13 at 9:55
If by "first problem" you mean system CPU load, you could either generate real system load by executing processes and/or use taskset to restrict cpu usage of your encrypt/decrypt. –  rickhg12hs Oct 11 '13 at 10:07
add comment

The solutions you mention do differ vastly in what they actually do - dm-crypt is full file system encryption while ecryptfs/encfs are above the file system. If you want security, decide first what you really want and only then how to go about it.

That said, don't be surprised if your CPU becomes the bottleneck - I assume that since it doesn't support AES-NI, its performance is of the order of magnitude of e.g. Intel Core2 Duo - which I happened to test about a year ago. The speed of the in kernel crypto modules was roughly 38MB/s±10MB/s depending on the cipher and block size used (Twofish, AES, Serpent and Camellia, with block sizes 128/192/256b).

share|improve this answer
add comment

How about the built-in cryptsetup benchmark?

PBKDF2-sha1       633198 iterations per second
PBKDF2-sha256     329326 iterations per second
PBKDF2-sha512     216647 iterations per second
PBKDF2-ripemd160  474039 iterations per second
PBKDF2-whirlpool  248713 iterations per second
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   707.0 MiB/s  3120.9 MiB/s
 serpent-cbc   128b    98.3 MiB/s   307.2 MiB/s
 twofish-cbc   128b   195.0 MiB/s   381.7 MiB/s
     aes-cbc   256b   513.8 MiB/s  2373.9 MiB/s
 serpent-cbc   256b    97.4 MiB/s   315.1 MiB/s
 twofish-cbc   256b   198.8 MiB/s   383.9 MiB/s
     aes-xts   256b  2706.1 MiB/s  2634.1 MiB/s
 serpent-xts   256b   318.0 MiB/s   310.4 MiB/s
 twofish-xts   256b   370.5 MiB/s   380.1 MiB/s
     aes-xts   512b  2083.2 MiB/s  2073.8 MiB/s
 serpent-xts   512b   323.0 MiB/s   311.4 MiB/s
 twofish-xts   512b   375.9 MiB/s   380.2 MiB/s

Usually you'll want to use one of the AES ciphers. Even if your system does not support AES-NI today, your next box may...

share|improve this answer
add comment

Your Answer


