Friday October 26, 2007 by Jason ‘vanRijn’ Kasper | 15 Comments
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?
http://movingparts.net/2007/10/26/truecrypt-versus-luks-speed-test/
anonymous
Friday October 26, 2007 at 6:26 pm
Without further information, I would guess they default to using different encryption schemes and/or key sizes.
ben
Friday October 26, 2007 at 6:58 pm
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…
Andreas
Friday October 26, 2007 at 9:31 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.
Sebastian
Friday October 26, 2007 at 10:50 pm
Thanks for the hint on LUKS, I didn’t know that before.
Pau Garcia i Quiles
Saturday October 27, 2007 at 4:29 am
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.
frank
Saturday October 27, 2007 at 6:05 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
ben
Saturday October 27, 2007 at 7:05 am
frank: 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.
Frank
Saturday October 27, 2007 at 7:31 am
ben: Uh, sorry. I thought you would compare LUKS with TrueCrypt. Must have been too fast reading…
ben
Saturday October 27, 2007 at 8:44 am
Here 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 😉
Frank
Saturday October 27, 2007 at 9:20 am
Nice, still would love to see how it compares to loop-AES…
bosco
Saturday March 14, 2009 at 2:11 pm
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
Sicarius
Monday June 29, 2009 at 4:25 am
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 😉 )
Brandon
Monday December 14, 2009 at 1:43 am
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).
Seventeener
Sunday December 20, 2009 at 1:48 pm
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!
mrm00
Thursday January 14, 2010 at 3:28 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
[dm-crypt] LUKS & TrueCrypt – Speed Test
Jorge Fábregas jorge.fabregas at gmail.com
Thu Jul 28 01:18:24 CEST 2011
Hello everyone,
Inspired by this old blog post:
http://movingparts.net/2007/10/26/truecrypt-versus-luks-speed-test/
…I decided to perform some tests on my Fedora 14 box. This is not a
pro benchmark so be warned 🙂
Common Facts for both tests:
– source & destination filesystems were ext4
– destination is an external USB drive
– source data size is 143GB (a folder with lots of files & directories,
small & large files, regular data…)
– rsync was used to perform the actual copy
– I’m using an “encrypted partition ” (against an encrypted file)
– I did a test first with TrueCrypt and then with LUKS
– Between the above tests, I shut down the machine (to flush filesystem
cache).
– my system kernel: 2.6.35.13-92.fc14.i686
### TrueCrypt Results ####
I used AES-256 (XTS operation mode), hash algorithm: ripemd-160 and the
package was realcrypt-7.0a-1.fc14.i686
Output of time command after rsync finished:
real 105m22.211s
user 28m10.471s
sys 41m35.319s
### DM-Crypt LUKS Results ###
I used the defaults: AES-256 (CBC), sha1 for header hashing and the
package cryptsetup-luks-1.1.3-1.fc14.i686
Output of time command after rsync finished:
real 108m55.291s
user 28m6.534s
sys 42m53.400s
As you can see, there’s almost a 4 minute difference. I was expecting
LUKS to be faster (as dm-crypt is a kernel module) and TrueCrypt runs
mainly in user space isn’t it? Do you think the cipher operation modes
(XTS vs CBC) played a role in this difference? Have any of you performed
a similar test?
Regards,
Jorge
http://www.saout.de/pipermail/dm-crypt/2011-July/001838.html
Arno Wagner arno at wagner.name
Thu Jul 28 07:11:17 CEST 2011
There is an old gemran egineering saying:
“wer mist mist mist”
(along the lines of “Those who measure measure crap”)
I think it applies here.
Real-time is tricky. It does not reflect effort invested. If you
look at the sys itime, you see that the crypto-effort is only about
90 seconds more. Even that is pretty much below the measurement
error. Very likely the differences are due to storage differences
and do not show crypto-speed differences.
I suggest you run both tests at least 3 times and make sure
your storage is significantly faster than the crypto, e.g.
by doing this between RAM disks or SSD storage. Also a complex
disk access patterhn like rsync is not suitable as it may
have complex interactions with caching and buffering.
Arno
—
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP — Email: arno at wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
Jorge Fábregas jorge.fabregas at gmail.com
Fri Jul 29 01:58:58 CEST 2011
Hi everyone,
I performed the tests again (twice for each test) but this time I
formatted the LUKS partition using:
cryptsetup luksFormat -c aes-xts-plain -s 256 -h ripemd160 /dev/sdd1
…so that I was more _similar_ to the TrueCrypt setup. Also, between
each test I run:
echo 3 > /proc/sys/vm/drop_caches
Here are the new results for the same payload (143 GB of data):
### TRUECRYPT ####
1st round:
real 105m39.547s
user 28m17.667s
sys 42m25.300s
2nd round:
real 105m40.271s
user 28m21.893s
sys 42m19.672s
### LUKS ###
1st round:
real 104m33.901s
user 27m41.362s
sys 41m0.339s
2nd round:
real 104m44.913s
user 27m42.364s
sys 40m57.655s
Now as you may see, LUKS is roughly around 1 minute ahead (sytem-time)
compared to TrueCrypt. It appears the change in cipher operation mode
definitely affected the results (thing I should have done on the first
place).
Cheers and thank your for the feedback!
Jorge