I did a small performance test yesterday and was very surprised by the results. I wanted to see which encrypted filesystem was faster betweeen Truecrypt and LUKS. I created 2 20-gig files, one with Truecrypt and the other with LUKS encryption. Then I mounted the encrypted files and copied a 180 meg file 10 times, synced, and then reported the time taken. Here’s the results:
Truecrypt test:
time (for f in $(seq 1 10); do; cp bigfile truecrypt-mnt/bigfile-$f; done;)0.22s user 26.30s system 15% cpu 2:47.06 total
LUKS test:
time (for f in $(seq 1 10); do; cp bigfile luks-mnt/bigfile-$f; done;)0.20s user 8.40s system 15% cpu 55.169 total
Wow. Now, granted, this is a simple enough test, but does anyone have any ideas why LUKS would be 3 times faster in writing 1.8 Gigs than Truecrypt?
Stay in touch with the conversation, subscribe to the RSS feed for comments on this post.
I just encrypted my whole linux server (Athlon 1400, 1000 RAM) three days ago using 256bit aes and LUKS. Generally, the whole system does feel really slow now.
CPing a 700MB file from an encrypted LUKS-ext3-partition to /dev/null takes 40 seconds (thats 17.5 MB/s).
DDing 719MB of /dev/zero onto the LUKS partition takes 35 seconds, that makes almost 21MB/s.
Not exactly the values you’d hope for after installing a new 500GB SATA drive ;( I’d really like to know about your ciphers, keysizes and system specs for comparison…
Friday October 26, 2007 at 6:58 pm
ben: if you had an idea how many steps any secure encryption algorithm requires you’d wonder why it still works so *fast*. Linux even contains an assembly optimized implementation of AES. An interesting experiment would be to verify if, on a modern processor, the C version with profiling and all optimizations is still slower than the assembly version. The assembly version is hand-optimized for pentium class CPUs. I’ve never tried profiling the kernel but it is possible AFAIK.
Friday October 26, 2007 at 9:31 pm
Did you run the LUKS test right after the TrueCrypt test? If so, the speed gain may very well be due to caching of ‘bigfile’.
The test should be done in the very same conditions: hard disks already working and ‘bigfile’ cached or not cached for both algorithms. I’d suggest retrying using this methodology:
1. Cold start your computer, TrueCrypt test. This is the “cold test time”.
2. TrueCrypt test again. This is the “cached test time”, as ‘bigfile’ is probably cached wholly or in part.
Shutdown your computer and repeat for LUKS. Then compare the “cold test times” for LUKS and TrueCrypt and the “cached test time” for LUKS and TrueCrypt.
Probably LUKS would still be faster than TrueCrypt, but this way we will be sure.
Saturday October 27, 2007 at 4:29 am
ben: you compare reading/decoding with writing/encoding. Thats not fair…
I tried following with loop-AES on a Pentium III-M 1.2GHz
time dd if=/dev/zero of=/tmp/testfile bs=1M count=700
Without encryption:
24,3748 seconds, 30,1 MB/s
0,00s user 4,15s system 16% cpu 24,503 total
With AES-256:
41,2084 seconds, 17,8 MB/s
0,00s user 12,30s system 29% cpu 41,213 total
I don’t have TrueCrypt or LUKS to compare with, sorry
Saturday October 27, 2007 at 6:05 amfrank: Huh? I just listed the performance of both processes. I don’t want to compare encoding with decoding, I want to compare to other machines.
In essence, I’d really like to know what an upgrade to e.g. a Core2Duo would give me. And whether the en/decryption would use both CPUs.
Saturday October 27, 2007 at 7:05 amben: Uh, sorry. I thought you would compare LUKS with TrueCrypt. Must have been too fast reading…
Saturday October 27, 2007 at 7:31 amHere it comes:
Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat /dev/sda3
cryptsetup luksOpen /dev/sda3 crypt
mkfs.ext3 -m 0 -j -L test /dev/mapper/crypt
mount /dev/mapper/crypt /mnt/temp1/
time dd if=/dev/zero of=/mnt/temp1/file.zero bs=1M count=700 takes 10.7 seconds
time cp /mnt/temp1/file.zero /dev/null takes 10.3 seconds
During these ten seconds, both CPUs are saturated. Nice 
this might be old just as tipp th mode cbc is not secure anymore (cryptsetup -c aes-cbc-essiv:sha25)
truecrypt uses xts the mode wich is adviced only the newest kernel supports it now.
but at least lrw mode is needed to havea secure entcryption
in case of big HDDs modes a far more important.
but i must give you credits even on my core 2 duo 3Ghrz truecrypt “was”slower but now … i dunno they made a lot ofimprovements
Saturday March 14, 2009 at 2:11 pm
Far as I know Luks is directly used as a kernel-module,
whereas TrueCrypt isn’t. This may be a major reason for the speed difference, since, as far as I know, the special assembly implementation is mostly the same in TrueCrypt and Luks. (Since both are OpenSource and same subject it sounds pretty logical )
This is basically what Sicarius said, TrueCrypt is a FUSE File System Under Userspace module. Truecrypt is slow for the same reason that ntfs-3g is slow. (Actually ntfs-3g isn’t that bad, but a filesystem shouldn’t take up 20-30% of your CPU when ext4 takes <1%). Essentially it is slow because it has to constantly switch between kernel space and user space when writing/reading from the disk because the actual write system call is a kernel mode call which must then make a userspace call to FUSE which must then make a kernel call to the disk controller. (If you know anything about threads, than you will know that userspace threads are much faster (sometimes up to 40x) than kernel threads because a full context switch is a very expensive operation).
Monday December 14, 2009 at 1:43 am
I can confirm the performance results. I have two external 3.5-inch Seagate drives: one is ntfs over truecrypt, the other is ext4 over luks. The last one is nearly four times faster!
Sunday December 20, 2009 at 1:48 pm
time dd if=/dev/zero of=/media/truecrypt1/testfile bs=1M count=700
700+0 Datensätze ein
700+0 Datensätze aus
734003200 Bytes (734 MB) kopiert, 9,29997 s, 78,9 MB/s
real 0m9.363s
user 0m0.000s
sys 0m2.344s
Without further information, I would guess they default to using different encryption schemes and/or key sizes.
Friday October 26, 2007 at 6:26 pm