Friday October 26, 2007 by Jason ‘vanRijn’ Kasper | 15 Comments<\/p>\n
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\u2019s the results:<\/p>\n
Truecrypt test:
\n time (for f in $(seq 1 10); do; cp bigfile truecrypt-mnt\/bigfile-$f; done;)
\n 0.22s user 26.30s system 15% cpu 2:47.06 total<\/p>\n
LUKS test:
\n time (for f in $(seq 1 10); do; cp bigfile luks-mnt\/bigfile-$f; done;)
\n 0.20s user 8.40s system 15% cpu 55.169 total<\/p>\n
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?
\nhttp:\/\/movingparts.net\/2007\/10\/26\/truecrypt-versus-luks-speed-test\/
\n<\/p>\n
anonymous
\nFriday October 26, 2007 at 6:26 pm\t<\/p>\n
Without further information, I would guess they default to using different encryption schemes and\/or key sizes.
\nben
\nFriday October 26, 2007 at 6:58 pm\t<\/p>\n
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.<\/p>\n
CPing a 700MB file from an encrypted LUKS-ext3-partition to \/dev\/null takes 40 seconds (thats 17.5 MB\/s).<\/p>\n
DDing 719MB of \/dev\/zero onto the LUKS partition takes 35 seconds, that makes almost 21MB\/s.<\/p>\n
Not exactly the values you\u2019d hope for after installing a new 500GB SATA drive ;( I\u2019d really like to know about your ciphers, keysizes and system specs for comparison\u2026
\nAndreas
\nFriday October 26, 2007 at 9:31 pm\t<\/p>\n
ben: if you had an idea how many steps any secure encryption algorithm requires you\u2019d 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\u2019ve never tried profiling the kernel but it is possible AFAIK.
\nSebastian
\nFriday October 26, 2007 at 10:50 pm\t<\/p>\n
Thanks for the hint on LUKS, I didn\u2019t know that before.
\nPau Garcia i Quiles
\nSaturday October 27, 2007 at 4:29 am\t<\/p>\n
Did you run the LUKS test right after the TrueCrypt test? If so, the speed gain may very well be due to caching of \u2018bigfile\u2019.<\/p>\n
The test should be done in the very same conditions: hard disks already working and \u2018bigfile\u2019 cached or not cached for both algorithms. I\u2019d suggest retrying using this methodology:
\n1. Cold start your computer, TrueCrypt test. This is the \u201ccold test time\u201d.
\n2. TrueCrypt test again. This is the \u201ccached test time\u201d, as \u2018bigfile\u2019 is probably cached wholly or in part.<\/p>\n
Shutdown your computer and repeat for LUKS. Then compare the \u201ccold test times\u201d for LUKS and TrueCrypt and the \u201ccached test time\u201d for LUKS and TrueCrypt.<\/p>\n
Probably LUKS would still be faster than TrueCrypt, but this way we will be sure.
\nfrank
\nSaturday October 27, 2007 at 6:05 am\t<\/p>\n
ben: you compare reading\/decoding with writing\/encoding. Thats not fair\u2026<\/p>\n
I tried following with loop-AES on a Pentium III-M 1.2GHz
\ntime dd if=\/dev\/zero of=\/tmp\/testfile bs=1M count=700<\/p>\n
Without encryption:
\n24,3748 seconds, 30,1 MB\/s
\n0,00s user 4,15s system 16% cpu 24,503 total<\/p>\n
With AES-256:
\n41,2084 seconds, 17,8 MB\/s
\n0,00s user 12,30s system 29% cpu 41,213 total<\/p>\n
I don\u2019t have TrueCrypt or LUKS to compare with, sorry
\nben
\nSaturday October 27, 2007 at 7:05 am\t<\/p>\n
frank: Huh? I just listed the performance of both processes. I don\u2019t want to compare encoding with decoding, I want to compare to other machines.<\/p>\n
In essence, I\u2019d really like to know what an upgrade to e.g. a Core2Duo would give me. And whether the en\/decryption would use both CPUs.
\nFrank
\nSaturday October 27, 2007 at 7:31 am\t<\/p>\n
ben: Uh, sorry. I thought you would compare LUKS with TrueCrypt. Must have been too fast reading\u2026
\nben
\nSaturday October 27, 2007 at 8:44 am\t<\/p>\n
Here it comes:
\nIntel(R) Core(TM)2 CPU 6600 @ 2.40GHz<\/p>\n
cryptsetup -c aes-cbc-essiv:sha256 -y -s 256 luksFormat \/dev\/sda3
\ncryptsetup luksOpen \/dev\/sda3 crypt
\nmkfs.ext3 -m 0 -j -L test \/dev\/mapper\/crypt
\nmount \/dev\/mapper\/crypt \/mnt\/temp1\/<\/p>\n
time dd if=\/dev\/zero of=\/mnt\/temp1\/file.zero bs=1M count=700 takes 10.7 seconds
\ntime cp \/mnt\/temp1\/file.zero \/dev\/null takes 10.3 seconds<\/p>\n
During these ten seconds, both CPUs are saturated. Nice \ud83d\ude09
\nFrank
\nSaturday October 27, 2007 at 9:20 am\t<\/p>\n
Nice, still would love to see how it compares to loop-AES\u2026
\nbosco
\nSaturday March 14, 2009 at 2:11 pm\t<\/p>\n
this might be old just as tipp th mode cbc is not secure anymore (cryptsetup -c aes-cbc-essiv:sha25)
\ntruecrypt uses xts the mode wich is adviced only the newest kernel supports it now.<\/p>\n
but at least lrw mode is needed to havea secure entcryption
\nin case of big HDDs modes a far more important.<\/p>\n
but i must give you credits even on my core 2 duo 3Ghrz truecrypt \u201cwas\u201dslower but now \u2026 i dunno they made a lot ofimprovements
\nSicarius
\nMonday June 29, 2009 at 4:25 am\t<\/p>\n
Far as I know Luks is directly used as a kernel-module,
\nwhereas TrueCrypt isn\u2019t. 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 \ud83d\ude09 )
\nBrandon
\nMonday December 14, 2009 at 1:43 am\t<\/p>\n
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\u2019t that bad, but a filesystem shouldn\u2019t 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).\nSeventeener\nSunday December 20, 2009 at 1:48 pm\t\n\nI 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!\nmrm00\nThursday January 14, 2010 at 3:28 pm\t\n\ntime dd if=\/dev\/zero of=\/media\/truecrypt1\/testfile bs=1M count=700\n700+0 Datens\u00e4tze ein\n700+0 Datens\u00e4tze aus\n734003200 Bytes (734 MB) kopiert, 9,29997 s, 78,9 MB\/s\n\nreal 0m9.363s\nuser 0m0.000s\nsys 0m2.344s\n Hello everyone,<\/p>\n Inspired by this old blog post:<\/p>\n http:\/\/movingparts.net\/2007\/10\/26\/truecrypt-versus-luks-speed-test\/<\/p>\n …I decided to perform some tests on my Fedora 14 box. This is not a Common Facts for both tests:<\/p>\n – source & destination filesystems were ext4 ### TrueCrypt Results #### Output of time command after rsync finished:<\/p>\n real\t105m22.211s ### DM-Crypt LUKS Results ### Output of time command after rsync finished:<\/p>\n real\t108m55.291s As you can see, there’s almost a 4 minute difference. I was expecting Regards, There is an old gemran egineering saying:<\/p>\n “wer mist mist mist” <\/p>\n (along the lines of “Those who measure measure crap”) Real-time is tricky. It does not reflect effort invested. If you I suggest you run both tests at least 3 times and make sure Arno Hi everyone,<\/p>\n I performed the tests again (twice for each test) but this time I cryptsetup luksFormat -c aes-xts-plain -s 256 -h ripemd160 \/dev\/sdd1<\/p>\n …so that I was more _similar_ to the TrueCrypt setup. Also, between echo 3 > \/proc\/sys\/vm\/drop_caches<\/p>\n Here are the new results for the same payload (143 GB of data):<\/p>\n ### TRUECRYPT ####<\/p>\n 1st round: 2nd round: ### LUKS ###<\/p>\n 1st round: 2nd round: Now as you may see, LUKS is roughly around 1 minute ahead (sytem-time) Cheers and thank your for the feedback!
\n[dm-crypt] LUKS & TrueCrypt – Speed Test<\/strong>
\nJorge F\u00e1bregas jorge.fabregas at gmail.com
\nThu Jul 28 01:18:24 CEST 2011<\/p>\n
\npro benchmark so be warned \ud83d\ude42<\/p>\n
\n– destination is an external USB drive
\n– source data size is 143GB (a folder with lots of files & directories,
\nsmall & large files, regular data…)
\n– rsync was used to perform the actual copy
\n– I’m using an “encrypted partition ” (against an encrypted file)
\n– I did a test first with TrueCrypt and then with LUKS
\n– Between the above tests, I shut down the machine (to flush filesystem
\ncache).
\n– my system kernel: 2.6.35.13-92.fc14.i686<\/p>\n
\nI used AES-256 (XTS operation mode), hash algorithm: ripemd-160 and the
\npackage was realcrypt-7.0a-1.fc14.i686<\/p>\n
\nuser\t28m10.471s
\nsys\t41m35.319s<\/p>\n
\nI used the defaults: AES-256 (CBC), sha1 for header hashing and the
\npackage cryptsetup-luks-1.1.3-1.fc14.i686<\/p>\n
\nuser\t28m6.534s
\nsys\t42m53.400s<\/p>\n
\nLUKS to be faster (as dm-crypt is a kernel module) and TrueCrypt runs
\nmainly in user space isn’t it? Do you think the cipher operation modes
\n(XTS vs CBC) played a role in this difference? Have any of you performed
\na similar test?<\/p>\n
\nJorge
\nhttp:\/\/www.saout.de\/pipermail\/dm-crypt\/2011-July\/001838.html
\n
\nArno Wagner arno at wagner.name
\nThu Jul 28 07:11:17 CEST 2011<\/p>\n
\nI think it applies here.<\/p>\n
\nlook at the sys itime, you see that the crypto-effort is only about
\n90 seconds more. Even that is pretty much below the measurement
\nerror. Very likely the differences are due to storage differences
\nand do not show crypto-speed differences.<\/p>\n
\nyour storage is significantly faster than the crypto, e.g.
\nby doing this between RAM disks or SSD storage. Also a complex
\ndisk access patterhn like rsync is not suitable as it may
\nhave complex interactions with caching and buffering.<\/p>\n
\n—
\nArno Wagner, Dr. sc. techn., Dipl. Inform., CISSP — Email: arno at wagner.name
\nGnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
\n
\nJorge F\u00e1bregas jorge.fabregas at gmail.com
\nFri Jul 29 01:58:58 CEST 2011<\/p>\n
\nformatted the LUKS partition using:<\/p>\n
\neach test I run:<\/p>\n
\nreal\t105m39.547s
\nuser\t28m17.667s
\nsys\t42m25.300s<\/p>\n
\nreal\t105m40.271s
\nuser\t28m21.893s
\nsys\t42m19.672s<\/p>\n
\nreal\t104m33.901s
\nuser\t27m41.362s
\nsys\t41m0.339s<\/p>\n
\nreal\t104m44.913s
\nuser\t27m42.364s
\nsys\t40m57.655s<\/p>\n
\ncompared to TrueCrypt. It appears the change in cipher operation mode
\ndefinitely affected the results (thing I should have done on the first
\nplace).<\/p>\n
\nJorge<\/p>\n