[gelöst] Fragen zu dd/LVM/LUKS

[Tintom]

Macht sich eine Verlangsamung durch die Verschlüsselung bei einem T60 oder T400 bemerkbar?

Es ist langsamer, aber im alltäglichen Arbeiten bemerkt man davon nichts. T400 mit 2,4 Ghz und verschlüsseltem /home:
$ head -c 2GiB /dev/zero |pv > /tmp/testdatei.dat
2GB 0:00:34 [59.3MB/s]
$ head -c 2GiB /dev/zero |pv > /home/testdatei.dat
2GB 0:00:45 [ 45MB/s]

[Patsche]

Vielen Dank für eure Hilfe. Ich werde es jetzt also getrennt verschlüsseln. Mit der 2 Platte werde ich das wahrscheinlich wirklich so machen, wie niemand es vorgeschlagen hat. Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.
Ich danke für eure Aufmerksamkeit. Sollte ich nochmal fragen haben, dann melde ich mich hier wieder. Das Thema ist für mich vorerst gelöst. Die Platte wird gerade mit den voreingestellten werden des jessie-daily Installers überschrieben. Ich weiß nicht genau, welche Werte er genommen hat, da ich die geführte Installation benutzt habe. Er braucht jedoch ca. 5 Stunden, wenn ich das hochrechne (3Min/1%). Also: Danke.

[Patsche]

Noch eine Frage fällt mir nun ein. Erhöht es eigentlich die Sicherheit, wenn ich innerhalb des der verschlüsselten LVM mit LUKS nochmal Dateien extra verschlüssele? Beispielsweise mit Truecrypt?

[Cae]

Noch eine Frage fällt mir nun ein. Erhöht es eigentlich die Sicherheit, wenn ich innerhalb des der verschlüsselten LVM mit LUKS nochmal Dateien extra verschlüssele?

Das haengt davon ab, wo der Key liegt. Z.B. kann es sinnvoll sein, bestimmte schuetzenswerte Daten, die man selten braucht, nur bei Bedarf zu entschluesseln und sonst in einem eigenen Container zu halten. Wenn du aber den Key dazu daneben auf die (per dm_crypt oder sonstwie behandelte) Platte legst, sehe ich keinen Mehrwert darin. Ggf. laesst sich der Extra-Container schneller "loswerden", aber wenn das noetig wird, will man vielleicht auch direkt das LUKS drumrum wegschmeissen.

Gruss Cae

[wanne]

Vorher möchte man natürlich die Festplatte mit Zufallszahlen beschreiben. Wie lange dauert so etwas für gewöhnlich? Wie ich gelesen habe kommt es natürlich "bs-Wert" und den "count-Wert" an, den ich dd mitliefere. Was empfehlt ihr?

Nimm einfach cat das setzt die blockgröße automatisch ist wesentlich pervormanter (dank asynchroner I/O). Und auf keinen Fall /dev/urandom. Das ist sticke lahm.
Als entweder einfach in das verschlüsselte device schreiben:

Code: Alles auswählen

cat /dev/zero > /dev/mapper/encrypted_device

oder einfach zufällig aes-verschlüsseltes zeug:

Code: Alles auswählen

openssl aes-128-cbc -in /dev/zero -kfile /dev/urandom > /dev/sdx

Das ist etwa 10 mal schneller als die dd Variante mit /dev/urandom

Ich habe hier eine externe Festplatte, welche im NTFS-Format formiert wurde. Ist es möglich LUKS mit dem NTFS-Dateisystem zu nutzen?

Du kannst da rein setzen was du willst. Leider gibt es keine Windows Programme mehr, die LUKS öffnen können. (FreeOTFE hat das früher können.) Somit finde ich das ziemlich sinnlos.

Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.

Der von cryptsetup empfohle Weg und auch absolut der robusteste und Angenehmste. Weiß nicht, warum der Debianinstaller das anders macht.

der braucht jedoch ca. 5 Stunden

Klingt als ob der mit /dev/urandom überschreibt.

Möglicherweise gibt’s da sogar native Methoden für – müsste sich jemand zu äußern, der sich damit auskennt.

Ja. Aber die sind inkompatibel zwischen Systemd-cryptsetup und cryptsetup.

Kann man die Verschlüsselungsart im Installer festlegen? Also beispielsweise "cbc-essiv:sha256" oder "xts". Oder gibt der Installer das vor?

Beim Installer kann man zwar wählen aber nur zwischen ein paar wenigen. Der Kernel im Installer ist (warum auch immer) um die performantesten Methoden beschnitten. Ich habe mein System deswegen aes-128-essiv:sha256 aufgesetzt. Und es dann per LiveCD cat in eine serpent-ctr partition kopiert. (Der kernel den der Installer dann installiert ist nämlich zu mehr oder weniger allem in der Lage.)

nd eventuell noch zur Geschwindigkeit.

Ich werde nacher (Spätestens 19:00Uhr) noch ein benchmark veröffentlichen.

Macht sich eine Verlangsamung durch die Verschlüsselung bei einem T60 oder T400 bemerkbar?

Bei normalen Fesplatten kannst du bei weitem nicht so schnell lesen, dass du deine CPU ernsthaft belasten kannst. Selbst beim Messen bekommt man da probleme Unterschiede nachzuwißen. (Wenn du gerade mit fullspeed ließt brauchst du typischerweise deine CPU eh nicht. Da kann die auch ein bisschen crypto machen. Man merkt also lediglich ein kleinen Anstieg bei der CPU auslastung aber keine verlangsamung.)
Mit SSDs sieht das anders aus: Mein T400 hat keine Hardwarebschleunigung für AES und ich habe eine SAMSUNG 840 SSD nachgerüstet. Da komme ich nur noch auf 2/3 der Geschwindigkeit. Weswegen ich mich dazu entschlossen habe /usr nicht zu verschlüsseln. Da habe ich das nur gemerkt, als ich mit Gigabit torrents geleecht habe.Was defakto ein mal im Jahr vorkommt.

[gehrke]

Ein Key-File, welches auf dem verschlüsselten System hinterlegt ist. So muss man ja dennoch nur 1 Passwort im Kopf behalten.

Der von cryptsetup empfohle Weg und auch absolut der robusteste und Angenehmste. Weiß nicht, warum der Debianinstaller das anders macht.

Ich vermute deshalb, weil der zweite Schlüssel dann im wesentlichen ungeschützt auf der Platte liegt. Ja, er ist zwar geschützt, wenn das System offline (nicht gestartet) ist. Aber wenn der umliegende Container einmal entschlüsselt ist, liegt der zweite Schlüssel transparent vor. Einziger Schutz sind dann noch die Benutzerrechte, was IMHO etwas dünn ist.

[wanne]

Acho: und wenn es um das Loswerden von Alten Daten geht, gib't das:

Code: Alles auswählen

hdparm --user-master u --security-erase NULL /dev/sdx

Dass nullt die Platte aus. (Und nach möglcihkeit so, dass auch Forensiker nicht mehr dran kommen.)

Falls das BIOS das sperrt kann man einfach kurz den Strom anziehen. Funktioniert auch bei IDE-Platten. (Obwohl das eigentlcih nur bei SATA so vorgesehehen ist. )