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:
- 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”.
iPhone-Ticker.de
NetbookNews.de