Re: Bei Installation verschlüsseln (Auch Swap und Boot)
Verfasst: 23.03.2021 19:02:50
Hm kommt da irgendwann mal was, nachdem ich sudo CP /Dev/Zero /Dev/sda eingegeben habe ?
die deutschsprachige Supportwebseite rund um das Debian-Projekt
https://debianforum.de/forum/
Das funktioniert problemlos. Nach der Entschlüsselung der VG erkennt init/systemd, dass im Swap ein Hibernation Image liegt, und lädt dieses in den Hauptspeicher.JTH hat geschrieben:23.03.2021 11:11:48Anmerkung an der Stelle immer: Wenn man den Ruhezustand aka Hibernation aka S4 aka Suspend-to-Disk aka sowieso benutzen möchte, braucht man zwingend eine Swap-Partition. (Aber ich hab keine Ahnung, ob sich das überhaupt mit Verschlüsselung verträgt.)
Gibt's auch irgendwas grafisches ? Der will nicht, es kommt ewig nichts, dann kommt Error und was mit keinen Speicher vorhanden. (cp: write error: No space left on device)wanne hat geschrieben:23.03.2021 18:50:47Ja solltest™ du. Ich weiß aber nicht wie man raus bekommt, ob es geklappt hat... Der Befehl ist stumm wie ein Fisch...LinuxNewcomer hat geschrieben:23.03.2021 18:14:54Wenn das klappt, wäre das die sichere Methode ? Somit erwischt er auch die versteckten ?Wie gesagt. Da schreibst du ja nur auf die sichtbaren. Üblicherweise fällt da so jeder 20 nicht drunter.Mit dd klappt das nicht ?Das übliche blabla, warum der Befehl ineffizient ist.dd if=/dev/urandom of=/dev/sdX bs=1M
urandom ist viel langsamer als openssl macht aber für den Zweck das gleiche:Gerade für ne SSD sind zufallszahlen sicher nicht besser als Nullen und cp oder cat sind viel Nutzerfreundlcihere Programme wie dd.Code: Alles auswählen
openssl enc -aes-128-ofb -in /dev/zero -k $(head -c 32 /dev/urandom | base64 ) -out /dev/sdX
Die sind viel schneller und viel intuitiver aber genau so sicher:Code: Alles auswählen
cp /dev/zero /dev/sdX
Aber wie gesagt willst du eh nicht machen. Trim ist worst case noch schneller und genau so gut und im best case (er versteht --secure) besser.Code: Alles auswählen
cat /dev/zero > /dev/sdX
Ja bei dd man muss schon wissen was man tut.
Äh ja das ist die Idee so lange nullen rein zu schreiben, bis kein Speicher mehr vorhanden ist...dann kommt Error und was mit keinen Speicher vorhanden.
progress oder pv können dir den Fortschritt anzeigen:Der will nicht, es kommt ewig nichts,
Code: Alles auswählen
pv /dev/zero > /dev/sdx
Code: Alles auswählen
cp /dev/zero /dev/sdx &
progress -m -p $!
Die SSD ist so schnell wie sie ist. Das wird nicht schneller von einer schnelleren cpu, (Esseiden du nutzt /dev/urandom, was deutlich langsamer als die SSD ist. Aber das gibt es unter Windows eh nicht.)Der ist Recht potent, i9 10900k 32ram und sie dort einmal lösche .
Wenn man z.B. eine 14TB Festplatte auf die Art mit Zufallszahlen überschreieben will, kann das eine halbe Ewigkeit dauern. Selbst, wenn /dev/urandom schnell genug Zahlen liefert, bremst die Festplatte. Ich rechne als Daumenregel bei Festplatte mit durchschnittlich 100MByte/s, bei 14TB würde es also 140000 Sekunden dauern, bis die Beschrieben ist, also rund 1.5 Tage. Wie gesagt, alles Pi mal Daumen, aber selbst bei einer doppelt so schnellen Festplatte würde es noch 18 Stunden dauern.LinuxNewcomer hat geschrieben:24.03.2021 06:39:23Hätte gedacht dauert länger. Lese hier immer von Stunden oder gar Tagen.
Nein. Einfach weil /dev/zero oder /dev/urandom unendlich groß sind. Und entsprechend auf keine noch so große Platte passen werden. Deswegen der Fehler, wenn die Platte voll ist. Da geben dir die tools aber fast exakt die Selbe Fehlermeldung:LinuxNewcomer hat geschrieben:24.03.2021 06:39:23Write error nicht genug freier Speicher. So das ist jetzt aber lückenhaft ? Weil die SSD versteckt und nach schiebt ?
Code: Alles auswählen
cat: write error: No space left on device
dd: error writing '/dev/sdx': No space left on device
cp: error writing '/dev/sdx': No space left on device
pv: write failed: No space left on device
Wie schon angemerkt rotierende Festplatten sind durch die Airodynamik in ihrer Rotationsgeschwindigkeit begrenzt üblicherweise 5400-7200rpm. Und da zum überschreiben jeder Ring mit Daten ein mal abgefahren werden muss... Ergibt sich da ne ziemlich feste Lesegeschwindigkeit auf die Plattengröße die mit der in der Wurzel zu nimmt. Für ne 2TiB Platte bei 5400rpm bist du da bei gut 5h für 4TiB sinds ~8h und bei 14TiB wärst du bei ~15h. Aber SSDs sind schneller und vor allem viel kleiner.Hätte gedacht dauert länger. Lese hier immer von Stunden oder gar Tagen.
14min wären 300MB/s oder die Geschwindigkeit von SATA2. Würde mal tippen, dass die über genau das angeschlossen ist...Aber villt bei einer 250gb SSD doch Recht schnell. So 15min schätze ich.
Die zufallszahlen werden tatsächlich über Verschlüsselung erzeugt. Unter anderem deswegen ist die urandom-Methode so langsam. Openssl nutzt hardwarebeschleunigung und AES. Das dürfte schneller als die Festplatte sein. Nullen erzeguen sowieso.Das mit der PC Leistung, hatte ich glaube mit dem Verschlüsseln verwechselt, da das ja durch die CPU berechnet wird.
Naja, Heise hatte das mal mit 250GB SSDs getestet und kam im schlechtesten Fall auf 1000 Zyklen:wanne hat geschrieben:24.03.2021 13:53:40Btw. Pass ein bisschen beim Sielen auf: SSDs nutzen sich beim Schreiben ab. Bei "normaler" Nutzung ist das eher irrelevant. Aber du schreibst hier jedes mal 250GiB. Du kannst das Spiel üblicherweise so 500mal spielen.
Eine Samsung hat 9.1PByte geschafft, also über 35000 Zyklen.Zwar bildeten die beiden Exemplare von Crucials BX200 die Schlusslichter, aber selbst sie erreichten 187 respektive 280 TByte
Ich habe einfach mal die Herstellerangaben genommen. Dass die im Normalfall um ne Größenordnung nicht stimmen weiß ich von unseren Scratch-Dateisystemen. Du hast also vom Prinzip her vollständig recht. Aber ich hatte tatsächlich auch schon welche, die früher aufgegeben haben. (Und dass dann auch ohne Kommentar. Überschreiben funktionierte ohne Fehler einfach nicht mehr.) Insbesondere bei den kleinen. 12 Platten sind halt einfach keine Basis. Ich nehme an, dass die Hersteller deswegen so vorsichtig sind.Naja, Heise hatte das mal mit 250GB SSDs getestet und kam im schlechtesten Fall auf 1000 Zyklen:
Schreiben Sie Parted Magic auf einen USB-Stick, das erledigt zum Beispiel das Tool Rufus. Booten Sie dann Ihr System vom Stick und klicken Sie in Parted Magic unter "System Tools" auf "Erase Disk". Das Tool bietet Ihnen einige Optionen an, wählen Sie ganz unten "Internal Secure Erase command" aus.
Die meisten Otto-Normalanwender zucken halt panikartig zusammen, wenn man sagt, daß man durch das Füllen der SSD mit Zufallszahlen, einen kompletten Schreibzyklus von der Lebenserwaruntg abziehen muß. Man sollte das schon ein wenig im Verhältnis zur normalen Nutzung sehen.wanne hat geschrieben:24.03.2021 14:41:36Aber ich hatte tatsächlich auch schon welche, die früher aufgegeben haben.
Ja. Das ruft intern das von mir anfangs empfohlene hdparm auf. Leider gibt es da ein paar Stolpersteine, weshalb ich das ungerne empfehle. Aber wenns funktioniert ist das perfekt.Schreiben Sie Parted Magic auf einen USB-Stick, das erledigt zum Beispiel das Tool Rufus. Booten Sie dann Ihr System vom Stick und klicken Sie in Parted Magic unter "System Tools" auf "Erase Disk". Das Tool bietet Ihnen einige Optionen an, wählen Sie ganz unten "Internal Secure Erase command" aus.
Jaja. Ein mal ist total harmlos. Aber wenn man jetzt fett Benchmarks mit zig durchläufen welches die schnellste Variante ist startet wirds irgend wann problematisch.Und wenn man davon ein einmaliges Beschreiben mit Zufallszahlen abzieht, würde es immer noch für weitere 215 Jahre reichen.
Das ist aber auch das andere Extrem.Die 120GB SSD in meinem Heimserver, die nur das System und mein Postfach enthält, hat in den letzten 7 Jahren 1TB Lifetime Writes gehabt.
Also die Anleitung mit hdparm hats schon in sich. Mit dem PW hin und her. Gnome Disks Utility meinst du ?jph hat geschrieben:24.03.2021 18:31:01Habe ich das richtig gelesen; für ein popliges ATA Secure Erase soll die Platte umgebaut werden? Das geht problemlos über die Shell (https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase) oder grafisch in der GNOME-Laufwerksverwaltung.
Das Problem ist noch mehr aufgefallen. Deswegen macht man einfach von Anfang an Crypto drauf und dann kann man einfach den Schlüssel vergessen wenn man die Daten unzugänglich machen will. Wie Apple und google auf ihren Handys.Hätte nie gedacht das das so anstrengend ist eine SSD sauber zu löschen.
Ok, ein Mac ist dann in etwa dasselbe wie eine Signatur – eine Art mit dem privaten Schlüssel verschlüsselte Prüfsumme?wanne hat geschrieben:23.03.2021 17:58:08Ein MAC (Message Authetication Code) ist ein Anhängsel um zu erkennen ob etwas verädert wurde. Ich habe versucht das einzudeutschen... luks2 kann sowas in die Verschlüsslung integrieren.
[...]
Der Unterschied zwischen einem MAC und einer Signatur ist, dass es bei einem MAC ein symetrischer Schlüssel ist. (Zum überprüfen und erstellen wird der selbe Schlüssel, den den du mit deinem Festplattenpasswort bekommst, genutzt) während bei einer Signatur das Überprüfen auch ohne den privaten Schlüssel zu haben möglich ist. Letztere sind deswegen ungleich komplizierter.smutbert hat geschrieben:25.03.2021 11:45:47Ok, ein Mac ist dann in etwa dasselbe wie eine Signatur – eine Art mit dem privaten Schlüssel verschlüsselte Prüfsumme?
luks2 (das im Kernel eingebaut ist) tut das beim Lesen. Wenn du jetzt signiert deinen Kernel hast, dein EFI den Kernel überprüfen und der Kernel dann die MAC. Wenn du also deinem EFI-Hersteller glaubst, dass das nicht verändert werden kann...
Ich kam an die M2 SSD nicht ran, also hab ichs riskiert, die anderen abgesteckt. Aber vor dem löschen kam dann noch mal eine Abfrage, welche SSD. Wäre ja auch sinnlos ohne Abfrage. Etwas verwirrend der ganze Ablauf. Aber das war innerhalb von ein paar Sekunden erledigt. Kann das sein ? Laut Beschreibung, ist wie Werks neu. Es könnten keine Daten mehr geholt werden und alles ist zurück gesetzt.wanne hat geschrieben:25.03.2021 11:24:36Wenn dein BIOS das kann würde ich einfach alle Platten ausbauen und das benutzen...