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