Truecrypt versus LUKS Speed Test

15 Replies to “Truecrypt versus LUKS Speed Test”

• Without further information, I would guess they default to using different encryption schemes and/or key sizes.

• 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…

• 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.

• Thanks for the hint on LUKS, I didn’t know that before.

• 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.

• 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

• 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.

• ben: Uh, sorry. I thought you would compare LUKS with TrueCrypt. Must have been too fast reading…

• 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 😉

• Nice, still would love to see how it compares to loop-AES…

• 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

• 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).

• 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!

• 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

This site uses Akismet to reduce spam. Learn how your comment data is processed.