debianforum.de

Verfasst: **12.02.2020 21:45:52**

Ist so ein verschlüsselter Bereich mit ecryptfs/cryfs eigentlich beim Zugriff langsamer als ein kompletter Container mit dmcyrpt/LUKS? Nach meinem Gefühl braucht der Rechner ewig, um einen Cryfs Container zu mounten, bzw mit einem Dateimanager diesen Ordner zu öffnen. Wenn ich das für das komplette Home Verzeichnis mache, stelle ich mir das sehr langsam vor im Tagesbetrieb. Hat da jemand Erfahrung?

Verfasst: **13.02.2020 08:42:38**

....eigentlich beim Zugriff langsamer als ein kompletter Container mit dmcyrpt/LUKS?

Soweit ich weiss, hat man mit luks so gut wie kaum Performanceverluste. Beim normalen arbeiten bemerke ich das jedenfalls nicht. Das liegt wohl daran, dass ein luks-device gar nicht entschlüsselt wird, sondern nur die einzelnen schreib- und lesevorgänge, was wiederum direkt im Kernel stattfindet. Das ist der markante Unterschied zu anderen crypt-systemen, die alle als zusätzliche Prozesse im userspace laufen, luks resp. dm-crypt ist kernel. Ich hoffe jemand korrigiert mich, wenn ich jetzt hier quatsch erzähle.

Verfasst: **13.02.2020 09:31:17**

TomL hat geschrieben:
13.02.2020 08:42:38
Das liegt wohl daran, dass ein luks-device gar nicht entschlüsselt wird, sondern nur die einzelnen schreib- und lesevorgänge, was wiederum direkt im Kernel stattfindet.

Daß nur das ver/entschlüsselt wird, das gerade im Zugriff ist, ist keine Besonderheit von LUKS. Und selbstverständlich benötigt jede Verschlüsselung Rechenkapazität, die den Rechner ausbremst. Aber, heutige Rechner haben in der Regel mehr CPU-Kerne als gerade benötigt werden, so daß die Rechenlast durch Verschlüsselung auf einem anderen Kern läuft als die Anwendungsprogramme und so die Verschlüsselung weitgehend unauffällig bleibt.

Verfasst: **13.02.2020 12:00:30**

stimmt. Ich denke da auch weniger an CPU-Last sondern eher an I/O-Last. Der Laptop hier hat zwar eine SSD. Aber auch dort dauert es mehrere Sekunden bis der Dateimanager ein Verzeichnis mit ~50 Einträgen bei mir aufgebaut hat (viele Unterverzeichnisse mit insgesamt ca 1 GB an Dateien). "Mehrere Sekunden" wäre okay für mich, aber natürlich nur, wenn das auch bei ~500GB so bleibt und dann nicht hochskaliert. Hat jemand Erfahrung damit, wie die Einlesezeit eines cryfs Mounts im Dateimanager sich mit der Größe verändert? Das sehe ich als größtes praktisches Problem.

Verfasst: **13.02.2020 12:13:30**

Ich merke keinen großen Unterschied mit einer mit Luks verschlüsselte LVM.

Code: Alles auswählen

cryptsetup benchmark
# Die Tests sind nur annähernd genau, da sie nicht auf den Datenträger zugreifen.
PBKDF2-sha1      1598439 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha256    2088796 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-sha512    1521880 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-ripemd160  849737 Iterationen pro Sekunde für 256-Bit-Schlüssel
PBKDF2-whirlpool  654541 Iterationen pro Sekunde für 256-Bit-Schlüssel
argon2i       7 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
argon2id      7 Iterationen, 1048576 Speicher, 4 parallele Threads (CPUs) für 256-Bit-Schlüssel (Zieldauer 2000 Millisekunden)
#   Algorithmus | Schlüssel | Verschlüsselung | Entschlüsselung
        aes-cbc        128b      1141,9 MiB/s      3435,1 MiB/s
    serpent-cbc        128b        87,8 MiB/s       723,9 MiB/s
    twofish-cbc        128b       202,6 MiB/s       385,4 MiB/s
        aes-cbc        256b       869,6 MiB/s      2780,2 MiB/s
    serpent-cbc        256b        96,0 MiB/s       723,6 MiB/s
    twofish-cbc        256b       212,9 MiB/s       385,7 MiB/s
        aes-xts        256b      2170,4 MiB/s      2146,9 MiB/s
    serpent-xts        256b       695,4 MiB/s       683,0 MiB/s
    twofish-xts        256b       383,0 MiB/s       383,8 MiB/s
        aes-xts        512b      1987,2 MiB/s      1960,6 MiB/s
    serpent-xts        512b       694,9 MiB/s       680,7 MiB/s
    twofish-xts        512b       382,6 MiB/s       384,1 MiB/s

Verfasst: **13.02.2020 12:22:18**

Wiko hat geschrieben:
13.02.2020 12:00:30
Ich denke da auch weniger an CPU-Last sondern eher an I/O-Last.

I/O-Last verschlüsselt ist identisch mit I/O-Last unverschlüsselt. Es müssen ja in beiden Fällen exakt gleich viele Bytes gelesen werden.

Der Laptop hier hat zwar eine SSD. Aber auch dort dauert es mehrere Sekunden bis der Dateimanager ein Verzeichnis mit ~50 Einträgen bei mir aufgebaut hat (viele Unterverzeichnisse mit insgesamt ca 1 GB an Dateien).

Der Dateimanager liest normalerweise nur das Verzeichnis und baut die Liste in der Anzeige entsprechend auf. Das Auslesen des Verzeichnisses ist eigentlich rasend schnell, tausend Dateien entsprechend nur etwa 100-300kByte lesen. Die Dateigrößen selbst spielen gar keine Rolle.

Was da dauert, ist ggfls. das Anzeigen des passenden Symbols für den Dateityp und das Ableiten des Dateityps. "Dumme" Dateimanager leiten den Dateityp nur von der Dateiendung ab und das kostet praaktisch gar nichts. Schlauere Dateimanager lesen von jeder Datei den Dateikopf (also das erste kByte) und leiten daraus den Dateityp ab. In diesem Fall dauert der Listenaufbau merklich länger ist aber auch von der Dateigröße völlig unabhängig, weil es genauso lange dauert, die ersten 1024 Bytes eine 20kByte-Datei zu lesen wie von einer 100GByte-Datei, egal ob verschlüsselt oder nicht. Die Dauer des Listenaufbaus ist also nur abhängig von der Anzahl der Dateien aber nicht von der Größe der einzelnen Dateien.

Verfasst: **13.02.2020 17:14:43**

TomL hat geschrieben:
13.02.2020 08:42:38
Soweit ich weiss, hat man mit luks so gut wie kaum Performanceverluste. Beim normalen arbeiten bemerke ich das jedenfalls nicht. Das liegt wohl daran, dass ein luks-device gar nicht entschlüsselt wird, sondern nur die einzelnen schreib- und lesevorgänge, was wiederum direkt im Kernel stattfindet. Das ist der markante Unterschied zu anderen crypt-systemen, die alle als zusätzliche Prozesse im userspace laufen, luks resp. dm-crypt ist kernel. Ich hoffe jemand korrigiert mich, wenn ich jetzt hier quatsch erzähle.

Wichtig ist hier auch ob der Prozessor AES-NI [1] hat. Ohne diese merkt man einen deutlichen Unterschied.

[1] https://de.wikipedia.org/wiki/AES_(Befe ... weiterung)

Verfasst: **13.02.2020 17:24:06**

Ehrlich gesagt, habe ich bei einem alten Intel Atom 4 Kern CPU(2930) ohne AES-Ni auch keinen großen Unterschied bemerkt. SSD rein und alles lief dennoch flott. Dazu habe ich aber keine Daten, den Nettop gibt es nicht mehr. Aber das war auch nur für den Desktop-PC, das kann ja je nach Nutzung aber auch anders aussehen.

Verfasst: **13.02.2020 23:57:23**

MSfree hat geschrieben:
13.02.2020 12:22:18

Wiko hat geschrieben:
13.02.2020 12:00:30
Ich denke da auch weniger an CPU-Last sondern eher an I/O-Last.
I/O-Last verschlüsselt ist identisch mit I/O-Last unverschlüsselt. Es müssen ja in beiden Fällen exakt gleich viele Bytes gelesen werden.

stimmt auch wieder

Die I/O-Last sollte also keinen Unterschied machen und die CPU-Last ist scheinbar kein großes Problem. Die Verzögerung durch Dateityperkennung oder Vorschaubilder kann ich nicht nachvollziehen. Das dürfte dann ja im cryfs Mount auch nicht langsamer sein als im unverschlüsselten Bereich.
Einen Grund für den langsameren Verzeichnisaufbau innerhalb des cryfs Mounts habe ich noch nicht entdeckt. Trotzdem ist es so. Ich kann ja mitanschauen, wie der Rechner langsam das Fenster aufbaut (ca 0,2-0,3 Sekunden pro Zeile).

Ist am Ende für mich jetzt aber egal: Heute habe ich die SSD platt gemacht und das System neu mit dmcrypt/luks aufgesetzt. Läuft und ich sehe keine Verzögerung dabei.

Verfasst: **14.02.2020 14:14:35**

So prinzipiell. Für welche die das Später lesen und etwas fitter sind:
Es gibt die Möglichkeit nachträglich luks zu verschlüsseln.
Live-Cd booten

Backup! (Strom weg führt zu vollständigem Datenverlust.)
root Dateisystem verkleinern (~500MiB)
root Partition verkleinern. (Etwas weniger als die Verkleinerung des Dateisystems )
/boot Partiton in freiem Platz anlegen
/boot auf die neue Partition verschieben
fstab anlegen
cryptsetup-reencrypt (Die verschlüsselten Daten werden 592 Byte größer sein. Deswegen sollte dein Dateisystem kleiner wie die Partition sein. Siehe Punkt 3)
chroot
update intiramfs
update-grub

Mir war klar, dass dieses vorgehen für Wiko eher ungeeignet ist. Ein fortgeschrittener User kann das aber machen.

Die I/O-Last sollte also keinen Unterschied machen und die CPU-Last ist scheinbar kein großes Problem. Die Verzögerung durch Dateityperkennung oder Vorschaubilder kann ich nicht nachvollziehen.

Du musst ein bisschen aufpassen. Wie gesagt: Die Rechenleistung ist für moderne CPUs eher lächerlich. So viel wird nicht gelesen, dass das die Performance merkbar beeinträchtigt. Das Problem ist eher der Zusätzliche Verwaltungsaufwand. Gerade bei encfs: Da gehst du Dateibrowser (Userpace) -> Kernel -> Encfs (Userspace) -> Dateisystem (Kernel) -> Block Deviece (Kernel) -> Platte (Hardware). Wenn man das für eine größere Menge Dateien macht und dann eventuell nicht mal parallel wird das langsam.
Mit LUKS hast du Dateibrowser (userspace) -> Dateisystem (Kernel) -> dm-crypt (kernel) -> Platte (Hardware) . Was genau gleich lang ist wie z.B. LVM. Dateibrowser (userspace) -> Dateisystem (Kernel) -> dm (kernel) -> Platte (Hardware). Da wird man schon einen Performance unterschied merken.
Des weiteren mag ich encfs nicht weil es intern deutlich komplexer ist. – Und entsprechend anfälliger für Fehler. (Eventuell sogar sicherheitsrelevante.)

Verfasst: **14.02.2020 21:14:00**

wanne hat geschrieben:
14.02.2020 14:14:35
Mir war klar, dass dieses vorgehen für Wiko eher ungeeignet ist. Ein fortgeschrittener User kann das aber machen.

Mit meinen 15 Jahren Debian Erfahrung fühle ich mich schon etwas fortgeschritten

Auch wenn hier vielleicht noch etwas erfahrenere User schreiben. In der Tat hatte ich letztes Jahr mit einem ähnlichen Vorgehen die Größen der logischen Partitionen innerhalb eines LUKS Containers mit LVM angepasst. Allerdings wusste ich nicht, dass man einen LUKS Container auch nachträglich komplett "erkonvertieren" kann. Der Tipp hätte mir ein paar Stunden Arbeit erspart. Und selbst wenn ich die Partition zerstört hätte: Neu Aufsetzen hätte ich ja immer noch können.

Das hat mich jetzt geärgert (dass ich nicht noch ein wenig gewartet habe UND dass der Tipp für mich ungeignet gewesen wäre).

Verfasst: **15.02.2020 02:18:00**

Mit meinen 15 Jahren Debian Erfahrung fühle ich mich schon etwas fortgeschritten

OOps. Dann sorry, für die Fehleinschätzung.

Irgend wie hat sich das beim ersten mal lesen für mich ziemlich naiv angehört. Jetzt gerade nochmal gelesen und ich kann dass da nicht mehr raus lesen...

Tut mir echt leid.

Allerdings wusste ich nicht, dass man einen LUKS Container auch nachträglich komplett "erkonvertieren" kann.

Das ist auch nicht so vorgesehen gewesen und ist ganz neu in Cryptsetup. Lässt sich aber relativ locker Scripten. Ich habe das hier mal im Forum geschrieben.
Du öffnest halt das verschlüsselte Devive und liest dann vom plain-device (sdxX) und schreibst in das verschlüsselte (mapper/disk) Wichtig ist halt, dass du immer zuerst die Blöcke ließt, bevor du sie schreibst.

Verfasst: **25.02.2020 19:02:46**

Ist es bspw. möglich ein encrypted Setup zu installieren, ganz normal mit Debian, bspw. auf der Zielplatte, größe 1TB, und dann die fstab zu übernehmen, und die Daten vom unverschlüsselten System umzuziehen?

Verfasst: **25.02.2020 19:04:52**

Ja. Das ist vermutlich der einfachere weg.

Verfasst: **26.02.2020 20:19:47**

wanne hat geschrieben:
25.02.2020 19:04:52
Ja. Das ist vermutlich der einfachere weg.

Danke dir, momentan mache ich das so:
Habe meine Platte auf eine weitere geclont, und habe die geklonte und die Zielplatte auf meinem PC eingesetzt.
Habe nun mit VirtualBox für die geklonte Platte raw disk access bereitgestellt, und für die Zielplatte auch, und beide auf einer VM eingehangen, nun mache ich die Debian installation, und nachher ziehe ich die Daten rüber.
Vielleicht mache ich zu meinem Vorgehen mal einen kurzen Guide. Mit 2 neu aufgesetzten Debians hat es zumindest reibungslos geklappt.

Zum kopieren, ist da

Code: Alles auswählen

 rsync -arvp --progress

die beste Option?

Verfasst: **27.02.2020 15:37:26**

die beste Option?

Ich würde die deutlich schnelleren Dateisystemeigenen Tools nehmen.
Also e2image -ra, xfs_copy, btrfs send/recive... Schneller und man vergisst nichts.
Sonst ein paar sachen zu rsync:
-v verlangsamt den Kopiervorgang deutlich.
-a enthält schon -r und -p. Die sind also unnötig. Schaden aber auch nicht.
ACLs und Extended Atributes fehlen. (Wirst dua aber normal nicht brauchen)
-H für Hardlinks
Du willst /proc und sowas nicht mitkopieren -x hilft da außer dem besser zu merken wenn alle Attribute groß und klein sind. (Braucht dann aber ein Aufruf pro Dateisystem.)
-h macht schöneren Output.
-S spart platz
--preallocate: Schadet nie. Nützt wenn noch andere Dateien gleichzeitig geschrieben werden sind. Sollte IMHO default sein.
Mein default Kommando ist dann das:

Code: Alles auswählen

rsync -aAhHxX --sparse --preallocate --progress

Verfasst: **29.02.2020 17:11:41**

Zur Ausgangsfrage:
Ich bestätige die Aussage von TomL:

Soweit ich weiss, hat man mit luks so gut wie kaum Performanceverluste.

Ist die Festplatte ist mit Luks verschlüsselt, so arbeitet sie nach dem Entschlüsseln imho wie jede andere Festplatte auch, also ohne einen Performanceverlust.
Ich arbeite mit Debian-Stable-GNOME3 und habe meine beiden Festplatten (SSD mit Betriebssystem/HDD mit Daten) bereits bei der Installation mit Luks verschlüsselt.
Zusammen mit einem Bios-Passwort ist das ein Desaster für Einbrecher und Diebe...

Verfasst: **04.03.2020 22:21:23**

Prima, habe das ganze nun nach etlichen Versuchen am laufen.
Mal die

Code: Alles auswählen

 /etc/crypttab

vergessen, mal die grub.cfg überschrieben etc.
Ende vom Lied ist: Kernel geupgradet auf die gleiche Version wie beim Quellsystem, crypttab, fstab gesichert, und dann root Partition ersetzt, nachher wieder neue fstab und crypttab rein, fertig. Läuft sofort und prima.

debianforum.de

Luks-Performance

Luks-Performance

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Nachträglich /home-Verzeichnis verschlüsseln

Re: Luks-Performance

Re: Luks-Performance

Re: Luks-Performance

Re: Luks-Performance

Re: Luks-Performance

Re: Luks-Performance

Re: Luks-Performance