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