Linux: Großer Geschwindigkeitsvergleich EncFS/eCryptfs/TrueCrypt/Luks

Bild der Verschlüsselungen

Neulich wollte ich es endlich mal wissen, wie groß sind denn die Performanceunterschiede zwischen EncFS, eCryptfs, Truecrypt und Luks/Cryptsetup?

Daher hab ich hier mal versucht, einen möglichst praxisnahen Performancevergleich zu machen:

Das wichtigste am Anfang:

  • OS: Ubuntu 10.10 x64 2.6.35-28-generic
  • Hardware: AMD Phenim II X4 965 Black Edition (4 Kerne, Standardtakt), 8 GB DDR3 RAM.
  • Alle verschlüsselten Ordner/Container lagen auf einer Vertex 2 SSD(32nm), auf der auch Ubuntu 10.10 lag.
  • Passphrase war übrigens überall gleich und immer “abcdefg”
  • Verschlüsselung war überall (so gut es eben ging gleiche Bedingungen zu schaffen) AES-128

Folgendermaßen bin ich vorgegangen:

  • Raumlaufwerk erzeugt mit sudo mount -t tmpfs none /pfad/zum/einhängepunkt (siehe hier)
  • Gemessen wurde mit vorangestelltem time (Nautilus: Stoppuhr). Die Angaben sind immer entsprechend der Ausgabe von time, also sprich Realzeit/User CPU-Zeit/System CPU-Zeit untereinander. (Ausnahme: Zusatzrunde 1 &2)
    Beispiel: 

    Truecrypt
    1. Runde real
    user
    system
  • Es wurden Durchgänge mit cp und rsync und am Schluss Nautilus gemacht -> Damit die Variable “es liegt am Kopieprogramm” ausgeschlossen wird. Ab Testreihe 2 kein rsync mehr!
  • Testreihe 1: Es wurden je 2 Schreibvorgänge (cp/rsnyc) mit dem immer gleichen Testfile gemacht in beide Richtungen (crypted -> Ram und Ram -> crypted, also 16 Vorgänge).
  • Ab Testreihe 2: Es wurden je 1 Schreibvorgänge mit den immer gleichen Testfiles gemacht in beide Richtungen (crypted -> Ram und Ram -> crypted, also 8 Vorgänge).
  • Reihenfolge innerhalb einer Testreihe: CP -> LUKS,EcryptFS,Truecrypt,EncFS danach Rsync -> LUKS,EcryptFS,Truecrypt,EncFS
  • Alle 4 Container/Ordner sind immer gemountet während des ganzen Vorgangs. Es wurde nebenher nichts anderes am PC gemacht!
  • Es wurden 3 verschiedene Testreihen mit verschiedenen Dateien und eine Zusatzrunde mit Nautilus (mit etwas anderem Ablauf s.u.) gemacht.

Die Prozessorauslastung wollte ich auch messen, es war allerdings schlicht zu kompliziert, da der Prozessor ja hoch und runter taktet und z.B. bei LUKS es abwechselnd immer eine hohe Auslastung und dann wieder gar keine Auslastung gab und bei Ecryptfs wiederum konstante Auslastung eines Kerns. Daher hab ich den Teil weg gelassen.

Falls ich Worte durcheinander werfe,  ich benutze folgende Worte jeweils synonym:

Lesen = von dem jeweiligen verschlüsselten Medium lesen und auf das Ramlaufwerk kopieren = Ram -> Crypted

Schreiben = vom Ramlaufwerk auf das jeweilige verschlüsselte Medium kopieren = Crypted -> Ram

Konfiguration der einzelnen Verschlüsselungen:

  • LUKS/Cryptsetup:
    • 8 GB großes Container File
    • Erstellung:
      dd if=/dev/zero of=container_file bs=1M count=8000 
      sudo losetup -f 
      sudo losetup /dev/loop0 container_file 
      sudo cryptsetup -c aes-xts-plain -y -s 256 luksFormat /dev/loop0
    • Darauf dann ein ext4 Filesystem erstellt
    • Cryptsetup Version 1.1.2
    • Genaueres Anleitung siehe hier.
    • AES-XTS-Plain 256 =  AES128, siehe hier.
  • EcryptFS:
    • Ordner “Test” erstellt und mit eCryptfs verschlüsselt
    • mkdir Testsudo
      mount -t ecryptfs ./Test ./Test
    • Cipher = aes
    • Blocksize = 16 (=AES 128)
    • Enable plaintext passthrough = y
    • Enable filename encryption = y
    • FNEK wurde der vorgeschlagene genommen
    • Version 83-0ubuntu3
    • Siehe hier und hier.
  • Truecrypt(TC):
    • Container -> container_file2.tc
    • Verschlüsselungsalgorithmus -> AES
    • Hash Algorithmus -> RIPEMD-160
    • Don’t use keyfiles (standardmäßig nicht angehakt)
    • Größe des Containers 8 GB
    • “i will store files larger than 4 GB on the volume”
    • Linux Ext4
    • “I will mount the volume only on Linux” = TC nutzt die Kernel Crypto Mudole
    • Version 7.0a
  • EncFS:
    • Ordner “Test2″ und “.Test2″, wobei in letzterem die verschlüsselten Dateien liegen sollen.
    • encfs ~/.Test2 ~/Test2
    • -> Experten Modus
    • -> AES 128
    • Dateisystem Blockgröße -> 1024 (Standardvorgabe)
    • Verschlüsselungsalgo der Dateinamen -> Block
    • Enable filename initialization vector chaining -> y (Standardvorgabe) (Sollte hier keine Performanceunterschiede machen, Macht sich bemerkbar, wenn man einen Ordner mit vielen Dateien darin umbennent)
    • Enable per-file initialization vectors? -> y (Standardvorgabe)
    • Enable filename to IV header chaining? -> n (Standardvorgabe)
    • Enable block authentication code headers -> n (Standardvorgabe)
    • Enable file-hole pass-through? -> y (Standardvorgabe)
    • Version 1.6
    • Siehe hier und hier (Gute Erklärungen der einzelnen Encfs optionen!).

Die 3 Testreihen:

Testreihe 1:  4 GB Große Datei aus zufälligen Zahlen

Zu kopierende Datei wurde aus zufälligen Zahlen erzeugt und war 4 GB groß.

dd if=/dev/urandom of=TestFile bs=1G count=4

Zuerst der “Vergleichsbenchmark” ohne Verschlüsselung:
Kopieren der 4 GB großen Testdatei vom Ramlaufwerk auf die (unverschlüsselte) SSD mit Hilfe von cp benötigte:

real 0m56.887s
user 0m0.080s
sys 0m9.840s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKS eCryptfs Truecrypt EncFS
1. Durchgang: cp 1m10.839s
0m0.040s
0m7.310s
0m59.902s
0m0.010s
0m45.470s
1m16.273s
0m0.020s
0m6.890s
2m31.021s
0m0.120s
0m22.900s
2. Durchgang: rsync 1m11.369s
0m34.630s
0m19.790s
1m57.060s
0m51.650s
1m27.880s
1m13.218s
0m32.380s
0m18.940s
3m17.897s
1m19.130s
0m48.200s


 

 

 

 

Wie man sieht, schlagen sie sich eigentlich alle gut bis auf EncFS. eCryptfs ist  - unerwarteterweise – knapper Sieger mit 10 s Vorsprung. Allerdings hat eCryptfs auch am meisten System-CPU Zeit benutzt – ob die anderen besser skalieren oder ob es daran liegt, das LUKS/TC Kernelmodule fürs Ver-/Entschlüsseln nutzen, weiß ich nicht.Sobald rsync ins Spiel kommt, sind LUKS/Truecrypt auf dem Siegertreppchen, eCryptfs nur noch Mittelfeld. Klar abgeschlagen ist EncFS.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKS eCryptfs Truecrypt EncFS
1. Durchgang: cp 0m32.972s
0m0.080s
0m13.420s
0m33.364s
0m0.020s
0m27.440s
0m35.624s
0m0.050s
0m13.530s
0m32.959s
0m0.110s
0m12.690s
2. Durchgang: rsync 1m38.643s
1m11.780s
0m38.020s
1m22.271s
0m48.010s
1m1.190s
1m37.834s
1m8.650s
0m37.230s
1m42.439s
1m17.120s
0m38.030s

 

 

 

 

 

Bei cp kaum ein Unterschied, bis auf hörere System CPU Zeit bei eCryptfs, bei rsync hingegen ist plötzlich eCryptfs der klare Gewinner, EncFS der klare Verlierer.

Für alle weiteren Testreihen hab ich nur noch cp genommen, kein rsync mehr!

Testreihe 2:  1584 Bilder

Ordner mit 1584 Bildern, insgesamt 842 MB. Bilder sind wild gemischt, große,kleine,mittlere alles dabei. Rest wie vorhin.

Zuerst wieder der “Vergleichsbenchmark” ohne Verschlüsselung:

real 0m1.882s
user 0m0.030s
sys 0m0.810s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKS eCryptfs Truecrypt EncFS
1. Durchgang cp 0m5.687s
0m0.020s
0m1.060s
0m8.255s
0m0.010s
0m8.170s
0m5.895s
0m0.030s
0m1.040s
0m30.084s
0m0.070s
0m4.350s


 

 

Interessant, Luks/TC liegen ganz klar in Führung, EncFS weit abgeschlagen.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKS eCryptfs Truecrypt EncFS
1. Durchgang cp 0m0.656s
0m0.030s
0m0.620s
0m0.742s
0m0.030s
0m0.690s
0m0.656s
0m0.030s
0m0.620s
0m5.993s
0m0.070s
0m1.810s

 

 

 

Beim Lesen umgekehrtes Bild: EncFS in Führung, eCryptFS letzter, LUKS/TC im Mittelfeld.

Testreihe 3:  5000 Dateien

Dieses Mal gibts 5000 Dateien à 512 KB (insg. ~2.4 GB) mit zufälligem Inhalt und zufälligem Dateinamen

while /bin/true; do dd if=/dev/urandom of=$( cat /dev/urandom | od -x | tr -d ' ' | head -n 1) bs=1K count=512; done

Rest wie vorhin.

Zuerst wieder der “Vergleichsbenchmark” ohne Verschlüsselung:

real 0m30.532s
user 0m0.100s
sys 0m5.440s

Schreibvorgänge vom Ramlaufwerk in die verschlüsselten Ordner/Container

LUKS eCryptfs Truecrypt EncFS
1. Durchgang cp 0m42.149s
0m0.110s
0m4.140s
0m36.254s
0m0.110s
0m29.310s
0m45.088s
0m0.110s
0m4.270s
1m24.687s
0m0.230s
0m14.200s


 

 

Bekanntes Bild: eCryptFS gewinnt, LUKS/TC im Mittelgeld, EncFS abgeschlagen.

Schreibvorgänge von den verschlüsselten Ordnern/Containern ins Ramlaufwerk

LUKS eCryptfs Truecrypt EncFS
1. Durchgang cp
0m43.435s
0m0.220s
0m8.520s
0m32.257s
0m0.160s
0m24.220s
0m44.917s
0m0.280s
0m8.370s
0m32.346s
0m0.290s
0m8.170s

 

 

 

Beim Lesen liegen dieses Mal die dateibasierten Verschlüsselungen beide vorne, LUKS/TC 10 Sekunden dahinter.

Zusatzrunde 1:

Kopieren der 5000 Dateien aus Testreihe 3 mit Nautilus von LUKS/eCryptfs ins Ramlaufwerk.

Ergebnis: Beide gleichauf mit ~ 32 Sekunden. Unterschiede innerhalb meiner Messtoleranz. (Stoppuhr..)

Zusatzrunde 2:

Kopieren der 5000 Dateien aus Testreihe 3 mit Nautilus von LUKS/eCryptfs auf Festplatte (NTFS FORMATIERT!).

Ergebnis: eCryptfs ~ 1:46, LUKS ~ 1:33 -> LUKS 10 Sekunden schneller.

Zugegebenermaßen waren Zusatzrunde #1 und #2 nicht sonderlich genau und daher wenig aussagekräftig.

Fazit:

Nochmal alle Ergebnisse als Tabelle, jeweils Zeilenweise der Sieger/die Sieger markiert. Wenn 2 gute Ergebnisse nahe aneinander liegen, hab ich beide markiert. Markierungen nur nach Real-Zeit! System-CPU Zeit unbeachtet.

LUKS eCryptfs Truecrypt EncFS
Messreihe 1
Schreiben Ram -> Crypted
1. Durchgang cp
1m10.839s
0m0.040s
0m7.310s
0m59.902s
0m0.010s
0m45.470s
1m16.273s
0m0.020s
0m6.890s
2m31.021s
0m0.120s
0m22.900s
Messreihe 1
Schreiben Ram -> Crypted
2. Durchgang rsync
1m11.369s
0m34.630s
0m19.790s
1m57.060s
0m51.650s
1m27.880s
1m13.218s
0m32.380s
0m18.940s
3m17.897s
1m19.130s
0m48.200s
Messreihe 1
Lesen Crypted -> Ram
1. Durchgang: cp
0m32.972s
0m0.080s
0m13.420s
0m33.364s
0m0.020s
0m27.440s
0m35.624s
0m0.050s
0m13.530s
0m32.959s
0m0.110s
0m12.690s
Messreihe 1
Lesen Crypted -> Ram
2. Durchgang: rsync
1m38.643s
1m11.780s
0m38.020s
1m22.271s
0m48.010s
1m1.190s
1m37.834s
1m8.650s
0m37.230s
1m42.439s
1m17.120s
0m38.030s
Messreihe 2
Schreiben Ram -> Crypted
1. Durchgang cp
0m5.687s
0m0.020s
0m1.060s
0m8.255s
0m0.010s
0m8.170s
0m5.895s
0m0.030s
0m1.040s
0m30.084s
0m0.070s
0m4.350s
Messreihe 2
Lesen Crypted -> Ram
1.Durchgang cp
0m0.656s
0m0.030s
0m0.620s
0m0.742s
0m0.030s
0m0.690s
0m0.656s
0m0.030s
0m0.620s
0m5.993s
0m0.070s
0m1.810s
Messreihe 3
Schreiben Ram -> Crypted
1.Durchgang cp
0m42.149s
0m0.110s
0m4.140s
0m36.254s
0m0.110s
0m29.310s
0m45.088s
0m0.110s
0m4.270s
1m24.687s
0m0.230s
0m14.200s
Messreihe 3
Lesen Crypted -> Ram
1.Durchgang cp

0m43.435s
0m0.220s
0m8.520s
0m32.257s
0m0.160s
0m24.220s
0m44.917s
0m0.280s
0m8.370s
0m32.346s
0m0.290s
0m8.170s
Zusatzrunde 1
~ 0m32s ~ 0m32s - -
Zusatzrunde 2
~ 1m33s ~ 1m46s - -

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Schlussendlich steht es gleichstand zwischen LUKS und eCryptfs.  Allerdings finde ich, zeigen LUKS und Truecrypt eine wesentlich konstantere Performance ohne große Ausreißer und bei wesentlich weniger System CPU Zeit. Da beide die gleichen Kernelmodule benutzen, ist die Performance fast immer gleich bis auf kleine Unterschiede, welche im Alltag keine Rolle spielen sollten.

Soll es ein dateibasiertes Verschlüsselungssystem sein, so muss man klar zu eCryptfs raten und von EncFS eher Abstand nehmen wegen der Performanceprobleme, welche wohl FUSE geschuldet sind. Das ist sehr schade, da EncFS eine unheimlich einfache Bedienung hat und ein absolutes Alleinstellungsmerkmal: Es kann den Ordner nach x Minuten Inaktivität automatisch Aushängen.

Beim Backup ist die Frage schon nicht mehr so leicht zu beantworten: Ich finde, EncFS ist hier der Sieger. Man kann einfach den Ordner kopieren und muss sich um nichts sorgen. Für eCryptfs spricht das prinzipiell auch, allerdings muss man hier auch dran denken die entspr. Schlüssel zu sichern und das “Restore”-Prozedere ist nicht sehr schön, siehe hier. Bei LUKS/TC bleiben einem schlussendlich 2 Varianten: 1) Container/Abbild des Laufwerkes ganz kopieren oder 2) Auf beiden Seiten verschlüsselte Medien nehmen und dazwischen kopieren.  Ich selber nutze Variante 2), da es mit Rsync weit besser klappt. Theoretisch kopiert Rsync bei Variante 1) auch nur die Veränderungen, praktisch klappt das bei 500 GB Containern nicht.

Ich persönlich wurde bei größeren Partitionen/Containern eher zu LUKS/TC raten, einfach weil die Performance konstanter ist. Für das Homeverzeichnis des Laptops hingegen ist eCryptfs beispielsweise sehr gut geeignet. Das kommt auch daher, dass eCryptfs vorallem bei SSDs besser dasteht, da im Gegensatz zu LUKS/TC hier ATA TRIM (discard) funktionieren sollte – Ubuntu bietet das von Haus aus fürs Homeverzeichnis an.

Im Archwiki findet sich aktuell eine Warnung im eCryptfs Artikel, dass eCryptfs Bugs enthält, welche zum Dateiverlust führen können und ausserdem das ganze System verlangsamen. Nachvollziehen kann ich es zwar nicht, man sollte es aber vllt. bei seiner Wahl in Betracht ziehen. (siehe auch hier)

Ausblick:

In diesem Vergleich ist das letzte Wort definitiv noch nicht gesprochen, denn mit Ubuntu 11.04 und co. wird der Kernel 2.6.38 Einzug halten und damit kommen einige Veränderungen (z.B. Verbesserungen an VFS). Ausserdem wird Dmcrypt eine bessere Unterstützung für Multicore Prozessoren bekommen, was LUKS und TC mit Sicherheit gerade recht kommt.(siehe hier)

Wenn ich Zeit habe, werde ich nochmal dann noch einmal “nachmessen”.



Comments (7)

  1. 10:37, May 9, 2011Rene Mayrhofer  / Reply

    Ich habe ebenfalls einen Vergleich der Verschlüsselungsverfahren vorgenommen, und zwar speziell mit einer SSD. Interessanterweise (und für mich unerwartet) ist eCryptfs hier merklich langsamer mit Kernel 2.6.38 als dm-crypt: http://www.mayrhofer.eu.org/ssd-linux-benchmark. Daher verwende ich jetzt dm-crypt (mit btrfs als innerem Root-FS) für beste Performance.

    • 16:25, May 14, 2011Andreas  / Reply

      Ich werde meinen Test auch bald unter 2.6.38 wiederholen und wie schon im Ausblick vermutet, düfte alles was auf dmcrypt basiert das rennen machen, da es bessere Multicore Unterstützung hat seit 2.6.38 ;)

  2. 14:13, July 19, 2011Rookee  / Reply

    Danke für den informativen Test! In Zeile 3 hast Du LUKS statt EncFS grün markiert. Ich hab’s in meiner alternativen Visualisierung mal korrigiert: http://imageshack.us/photo/my-images/192/unbenanntmrm.png/. Dort ist außerdem der langsamste Wert in rot markiert. Was sofort ins Auge fällt: EncFS ist entweder ganz vorn mit dabei oder am langsamsten. Noch nutze ich EncFS, aber ich denke, jetzt werde ich mal eCryptFS testen!

  3. 16:01, July 19, 2011Andreas  / Reply

    @Rookee
    Danke für den Hinweis und das Lob, tatsächlich wollte ich da beide Zellen markieren, nur bei der zweiten hat WordPress irgendwie etwas ganz seltsames draus gemacht .. jetzt passt es. ;)

  4. 16:42, July 27, 2011Philipp  / Reply

    Danke für diesen tollen & informativen Test, sowie auf den Hinweis dass TrueCrypt das gleiche Kernelmodul nutzt! Somit ist meine Wahl auf TrueCrypt gefallen (bin ein Cross-Plattform-User). :)

  5. 22:07, November 14, 2011Gunnar Thielebein  / Reply

    Hallo,
    vielleicht ist es schon spät aber beim Test “Messreihe 2
    Lesen Crypted -> Ram 1.Durchgang cp” ist doch Encfs der klare Verlierer…

  6. 15:40, March 27, 2013Henning  / Reply

    Hey, danke für den Test, genau das was ich gesucht habe
    (habe grade luks und hab mich gefragt, wie viel schneller meine SSD eig. ohne wäre).

    Allerdings hast du glaube ich was ganz wichtiges übersehen (oder zumindest nicht erwähnt): Caching. Sprich: Es gibt ja disk caches die Linux im RAM automatisch anlegt. U.u. misst du dann nur die Zeit bis deine Daten im Cache sind (und nicht wirklich auf der SSD).
    Das lässt dann zum einen die SSD raus aber u.U. uach die verschlüsselung (weiss nicht genau wie sich die einzelnne Ansätze da verhalten).

    Noch viel schlimmer: Dadurch kann ein Experiment das nächste beeinflussen: Wenn du die daten wieder in die ramdisk zurückkopierst, könnte es sein, dass du aus dem cache liest.
    wodurch die rück-kopier experimente schneller sind als sie eig sein sollten.

    IIRC gabs irgendwo in /proc oder /sys ne stelle wo man caches ausschalten kann, aber genau weiss ich das nicht mehr, sorry.
    Wäre jedenfalls sehr interessiert, falls du nochmal eine Testreihe machen solltest! Thanks for sharing!

Leave a Reply

Allowed Tags - You may use these HTML tags and attributes in your comment.

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Pingbacks (0)

› No pingbacks yet.