Why the results of Truecrypt and cryptsetup (LUKS) benchmarking are so different?
I want to encrypt a part of my HDD. But before that I wanted to benchmark the different algorithm available wondering if I should choose aes-xts-256
or aes-xts-512
.
Note: I don't have aes
hardware acceleration. The benchmarks were repeated multiple times without much change. I'd like to state clearly that these benchmark are only valid on my computer (Debian, core 2 duo). This is not intended to be a complete LUKS-TrueCrypt comparison.
TL;DR: go to part 4
1- Cryptsetup
So I downloaded cryptsetup v1.6.0
to make use of the new cryptsetup benchmark
command.
Command
$cryptsetup benchmark
Results
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 128,2 MiB/s 157,2 MiB/s
serpent-cbc 128b 49,6 MiB/s 57,7 MiB/s
twofish-cbc 128b 138,0 MiB/s 183,8 MiB/s
aes-cbc 256b 97,5 MiB/s 121,9 MiB/s
serpent-cbc 256b 51,8 MiB/s 57,7 MiB/s
twofish-cbc 256b 139,0 MiB/s 183,8 MiB/s
aes-xts 256b 156,4 MiB/s 157,8 MiB/s
serpent-xts 256b 55,7 MiB/s 58,7 MiB/s
twofish-xts 256b 161,5 MiB/s 165,9 MiB/s
aes-xts 512b 120,5 MiB/s 120,9 MiB/s
serpent-xts 512b 55,7 MiB/s 58,5 MiB/s
twofish-xts 512b 161,5 MiB/s 165,3 MiB/s
Thoughts
Incbc
mode,serpent
is surprisingly fast at decrypting!Inxts
mode,serpent
is clearly the fastest.- The key size seem to have almost no noticable effect on
serpent
twofish
. -
aes
does not behave well when the key size is increased.
Updates out of VM
2- TrueCrypt
I was really surprised as aes
is known to be the fastest (even without hardware acceleration). So I downloaded TrueCrypt
to double-check these results. TrueCrypt
uses the xts
mode by default so I assume it also use it in its benchmarks.
Method
- Tools > Benchmark
- Choose any buffer size (here, 5MB)
- Click on "Benchmark"
Results
# Algorithm | Encryption | Decryption
AES 106 MB/s 107 MB/s
Twofish 78 MB/s 76 MB/s
Serpent 41 MB/s 42 MB/s
Thoughts
These results corresponds much more to what is expected but do not match well with cryptsetup
's results.
3- General thoughts
-
cryptsetup
provided better general performance thanTrueCrypt
in this case. This could be explained the following way:-
cryptsetup
was compiled on my system with compiler optimization routines whileTrueCrypt
was already compiled in a generic way; - AFAIK
cryptsetup
uses kernelspace crypto modules whileTrueCrypt
uses userspace crypto routines.
-
- However, I can't explain why
serpent-xts-512
seems to be the way to go withcryptsetup
whileaes-xts
the only cipher worth using.
4- Question
cryptsetup
and TrueCrypt
give completely different qualitative (relative cipher speed) and quantitative (actual speed of each cipher) results in in-RAM benchmarks.
- Is that something you have already noticed?
- Should I trust
cryptsetup
and useserpent-xts-512
cipher for speed?
You don't have AES hardware acceleration, and were running the tests in a virtual machine. It's unlikely that your test results would be reflective of real-world results, as the encryption/decryption speeds heavily depend on the current CPU & disk loads. Your best bet is to create two independent Truecrypt partitions, and perform manual benchmarks by copying some large files to/from each partition.
LUKS and Truecrypt also have slightly different implementations, and as you said, "these benchmark are only valid on my computer". You need to actually test both on your system with actual file transfers to determine the true performance.
As for the differences, Truecrypt uses FUSE to implement a userspace filesystem, whereas LUKS is usually done in the actual kernel. For this reason, it's likely that you would get better throughput in a Linux system using LUKS/dm-crypt/cryptsetup as opposed to Truecrypt, although which option you choose depends on the requirements of your encryption (e.g. Truecrypt partitions can be transfered between operating systems if needed).
Linux kernel has SSE2 and AVX optimized Serpent modules to accelerate parallelizable workloads (such as CBC decryption and XTS enc&dec).
Performance of Serpent in CBC decryption and XTS with those module(s) loaded should be at near same level as software AES and Twofish (slightly faster or slower depending your exact CPU model).