Inst mit encrypted partition. Overwrite with random data?

[mclien]

Ich installiere gerade ein Notebook. Das ist ein Leasingrückläufer mit neuer Platte (war eine fat32 Part mit nem DOS (freedos nehme ich an).
Jetzt setze ich das Ding natürlich gleich mit encrypteten Partitionen auf. Allerdings will der Installer dann in einem Schritt die Partitionen mit Random Daten überschreiben. Da das schon bei den 40GB Partitionen recht "länglich" dauert frage ich mich gerade, ob das bei einer neuen Platte überhaupt Not tut? Ist das nicht nur bei gebrauchten Platten sinnvoll, sprich kann ich mir die Zeit auch sparen und ohne Random Data auf der 1 TB Partition weitermachen?
Oder habe ich etwas essentielles bei verschlüsselten Partitionen verpasst?

[wanne]

Bei veschlüsselten neuen Platten sieht man trotzdem noch realativ gut die Dateigrößen, weil die unlesbaren Dateien zwischen den Nullen aus der Fabrik stehen. Klingt harmlos, aber defakto kann man aus den Dateigrößen im normalfall zimmlich gut schließen welche datei das ist. Such einfach mal nach der Datei mit der Größe 2838176 ich wette es gibt genau eine nämlich deinen Kernel.
Allerdigs ist das nutzen von /dev/urandom total übertrieben. Wenn du zum verschlüsseln AES nimmst, kannst du auch für die random-data AES nehmen. (Geht um längen schneller.)
Siehe hier: viewtopic.php?f=15&t=147943

[mclien]

Ah, das geht aber nicht wenn man es während der Installation macht (zumindest nicht, wenn man schon angefangen hat die kleineren Part. zu bearbeiten, wie ich gerade..)

[schorsch_76]

Wenn du dir beim Installieren diese Zeit sparen willst, installiere mit cypt aber ohne zu initialisieren mir urandom.
Wenn das System läuft, lass eine Datei aus /dev/null volllaufen, das schreibt dann auf die ganze Platte "Müll". Diese Datei löscht du dann wieder. Im Fall von LVM auf crypt das gleiche entsprechend anpassen.

[wanne]

Wenn das System läuft, lass eine Datei aus /dev/null volllaufen, das schreibt dann auf die ganze Platte "Müll".

Nicht ganz optimal, weil man die interessantesten Teile nicht erwischt (inodetable). Bei der Granulierung von 16Byte-Blöcken sieht man da aber nicht mehr so viel. Habe ich aber auch schon gemacht. Die Geschwindigkeit ist im übigen ziemlich exakt gleich wie die von openssl. (Hier auf meinem AMD Athlon64 X2.)

[Cae]

Such einfach mal nach der Datei mit der Größe 2838176 ich wette es gibt genau eine nämlich deinen Kernel.

Und wer gerade find -size bemueht: find(1) hat da eine bescheuerte Standardeinstellung von 512-Byte-Bloecken als Einheit; man muss explizit mit c am Ende angeben, dass man Bytes haben will:

Code: Alles auswählen

#                               --v
$ 2>/dev/null find / -size 2838176c
/boot/vmlinuz-3.2.0-4-amd64
$ 

Gruss Cae

[wanne]

[Und wer gerade find -size bemueht: find(1) hat da eine bescheuerte Standardeinstellung von 512-Byte-Bloecken als Einheit; man muss explizit mit c am Ende angeben, dass man Bytes haben will:

Code: Alles auswählen

#                               --v
$ 2>/dev/null find / -size 2838176c
/boot/vmlinuz-3.2.0-4-amd64
$ 

Wobei man ehrlicherweise sagen muss, dass man auf ner LUKS-Verschlüsselten Partition auch nur auf 512-Byte genaue ergebnisse bekommt, was die erkennung deutlich erschwert.